Chatbots & Kundeservice

Use-casen dækker systemer, hvor en sprogmodel svarer direkte på henvendelser fra kunder eller brugere. Det spænder fra en widget, der besvarer spørgsmål om fragt og returret, til en assistent, der slår op i ordrehistorik og gennemfører enkle ændringer. Fællestrækket er, at modellen kommunikerer med en ekstern part i realtid.

Grænsen mod nabo-use-cases går to steder. Interne videnassistenter, hvor medarbejdere søger i dokumentation, ligner teknisk det samme, men har helt andre krav til tone, ansvar og fejlmargin. Agenter, der selvstændigt udfører længere handlingskæder på tværs af systemer, hører til under automatisering, selvom en kundeservicebot kan låne enkelte værktøjskald derfra.

En ren FAQ-bot uden retrieval hører også med her, men den løser en anden opgave end en assistent med adgang til kundedata. Forskellen i implementeringsarbejde mellem de to er stor, og det er grunden til at sværhedsgraden strækker sig fra begynder til avanceret.

En typisk opsætning består af fire lag. Først en kanal, altså chatwidget, e-mail eller beskedplatform, som leverer brugerens tekst og en samtalehistorik. Derefter et orkestreringslag, der afgør hvad der skal ske: skal spørgsmålet besvares fra videnbasen, kræver det opslag i et backendsystem, eller skal det videre til et menneske.

Tredje lag er kontekstopbygning. Her hentes relevante tekststykker fra dokumentation via RAG, og relevante kundedata hentes fra CRM eller ordresystem. Det samles med en systemprompt, der definerer tone, afgrænsning og regler for hvad botten ikke må udtale sig om. Fjerde lag er selve modelkaldet og efterbehandlingen, hvor svaret logges og eventuelt filtreres.

Kvaliteten afgøres primært i tredje lag. En Claude Sonnet 5 med dårligt retrieval svarer værre end en Claude Haiku 4.5 med præcist retrieval. Modelvalget påvirker mest formuleringsevne, instruktionsfølgning og hvor godt lange samtaler holdes sammen. GPT-5 nano og Claude Haiku 4.5 bruges ofte til klassifikation og rutinesvar, mens tungere modeller som Gemini 3.1 Pro reserveres til henvendelser med meget kontekst.

Den hyppigste fejl er ikke hallucination i klassisk forstand, men forældet indhold. Videnbasen indeholder en priside eller en returpolitik fra sidste år, og modellen gengiver den loyalt og overbevisende. Fejlen ligger i indholdsdriften, ikke i modellen, og den opdages typisk først når en kunde klager.

Dernæst kommer eskalering, der taber konteksten. Botten sender samtalen videre til en agent, men agenten får kun de sidste par beskeder og må starte forfra. Kunden har så brugt fem minutter på en dialog uden værdi, og den samlede oplevelse bliver dårligere end uden bot.

Et tredje problem er, at bots svarer på ting de burde afvise. Kunder stiller spørgsmål om reklamationsret, kompensation og bindende tilsagn, og en model uden klare afgrænsninger giver et venligt svar, som virksomheden kan blive holdt op på. Prompt injection via kundens egen tekst forstærker risikoen, når botten har adgang til værktøjer.

Endelig undervurderes evaluering. Uden et testsæt af rigtige historiske henvendelser med kendte korrekte svar kan du ikke afgøre, om en ændring i prompt eller model gør systemet bedre eller værre.

Gevinsten måles sjældent i sparede kroner per svar, men i hvor stor en andel af henvendelserne der lukkes uden menneskelig indblanding. Den andel afhænger mere af henvendelsesmixet end af teknikken. Har du mange enslydende spørgsmål om leveringstid og ordrestatus, er potentialet stort. Er hovedparten komplekse sager med skøn og undtagelser, er det begrænset.

Driftsomkostningen fordeler sig anderledes end mange forventer. Modelkald udgør ofte en mindre del end vedligeholdelse af videnbasen, integrationer og løbende kvalitetskontrol. Regn med at indholdsarbejdet fortsætter så længe botten er i drift.