Sådan implementerer du en AI-chatbot i kundeservice (uden at den bliver pinlig)

Tre faldgruber i en kundeservice-bot

En chatbot kan give et flydende svar og alligevel skabe ekstra arbejde. En vigtig faldgrube er at lade modellen svare om virksomheden uden et aktuelt grundlag. Returpolitik, levering og produktinformation kan ændre sig; et plausibelt svar fra modellens træning er ikke nok.

En anden faldgrube er et uklart scope. Hvis botten både skal forklare produkter, ændre ordrer og behandle reklamationer fra første dag, bliver det svært at forstå fejlene. Afgræns både hvad den kan svare på, og hvilke handlinger den har tilladelse til.

Den tredje faldgrube er målingen. Antal chats viser aktivitet. En løst sag kræver, at kunden fik korrekt hjælp. Kontrollér også, om kunden vender tilbage, om et menneske må rette svaret, og om overdragelsen fungerer.

Den rigtige tilgang — én use case ad gangen

Vælg startopgaven ud fra jeres egne henvendelser. Ordrestatus og returspørgsmål er mulige kandidater, men der er ingen grund til at antage, at de fylder mest i alle virksomheder. Se på hyppighed, datatilgængelighed og konsekvensen af et forkert svar.

Definér på forhånd, hvad der tæller som godkendt kvalitet. En simpel statusforespørgsel og en sag om kompensation behøver ikke have samme grænser. Test også manglende ordre-ID, modstridende oplysninger og spørgsmål, botten skal afvise eller overdrage.

Gør overdragelsen praktisk: hvem modtager sagen, hvilke nødvendige oplysninger følger med, og hvad får kunden at vide? Botten må ikke påstå, at en medarbejder er kontaktet, før systemet har bekræftet det.

Teknisk arkitektur

Et brugbart udgangspunkt er fem lag. Først vælges en model efter test af dansk, svartid, værktøjer og pris på den konkrete opgave. Et familienavn alene afgør ikke kvaliteten.

Dernæst tilføres virksomhedens godkendte viden. RAG kan hente relevante uddrag fra FAQ og politikker. Søgeteknikken kan bruge vektorer, søgeord eller en kombination. Kilderne skal have version og ansvarlig redaktør.

Tredje lag er opslag i systemer, eksempelvis ordrestatus. Applikationen validerer brugerens adgang og argumenterne, før et foreslået værktøjskald udføres. Start gerne med læseadgang.

Fjerde lag er instruktioner om tone, kildebrug og eskalation. De understøtter adfærden, men erstatter ikke adgangskontrol i kode.

Femte lag er evaluering og nødvendige logs. Registrér resultater og fejltyper med et klart formål, begrænset adgang og slettepolitik. Der er ingen universel pris pr. samtale eller garanteret svartid.

GDPR og dansk juridisk virkelighed

Hvis botten behandler personoplysninger, skal der være et lovligt grundlag og passende beskyttelse. Send kun de oplysninger, der er nødvendige. Et ordrenummer kan også være personhenførbart; det er ikke automatisk anonymt, fordi kundens navn mangler.

Hashing af en email er ikke i sig selv anonymisering. Hvis der fortsat er mulighed for identifikation, skal det vurderes i den konkrete sammenhæng. Ved behandling på jeres vegne kan pseudonymiserede oplysninger fortsat være personoplysninger, selv om leverandøren ikke har nøglen.

Afklar rollefordelingen og databehandleraftalen, hvor leverandøren handler på jeres vegne. Undersøg også underleverandører, lagring, supportadgang og eventuelle tredjelandsoverførsler. En EU-region alene garanterer ikke GDPR-overholdelse. Oplys tydeligt, at kunden bruger en AI-assistent, og gør relevant privatlivsinformation tilgængelig.

Implementering med kvalitetsporte

Start med scope, data og ansvar. Saml de godkendte kilder og beskriv succeskriterierne sammen med supportteamet. Afklar databehandlingen før brug af rigtige kundesager i test.

Byg derefter en afgrænset prototype. Test almindelige og vanskelige spørgsmål, manglende data og forsøg på at få adgang til en anden kundes sag. Antal testeksempler skal passe til variationen og risikoen.

En begrænset pilot kan åbnes, når kriterierne er opfyldt. Gennemgå fejl og genhenvendelser, før eksponeringen udvides. Bevar en hurtig måde at slå botten fra og en tilgængelig overdragelse. Varigheden afhænger af kilder, integrationer og godkendelser; faserne er ikke et løfte om et bestemt antal uger.

Hvad det koster

Budgettet bør skelne mellem etablering, variabel drift og intern vedligeholdelse. Etablering omfatter datagennemgang, integration, test, brugerflade og opsætning af kontrol.

Mål model- og værktøjsforbrug på repræsentative samtaler. Medregn flere beskeder, søgninger, genforsøg og eskalationer. Brug den aktuelle prisliste for den valgte version, og beregn en pris pr. korrekt løst sag frem for at genbruge et generelt ørebeløb.

Database, hosting og overvågning har også kapacitets- og driftsomkostninger. En udvidelse som pgvector kan undgå et separat databaseprodukt, men gør ikke lager, beregning og vedligehold gratis. Afsæt ansvarlig tid til at gennemgå fejl og opdatere kilder. Omfanget bør måles under piloten.