Kundeservice & Support

Use-casen dækker sprogmodeller der indgår i selve supportflowet: læser en indkommende henvendelse, forstår hvad kunden vil, finder relevant information og formulerer et svar. Det kan ske fuldautomatisk over for kunden, eller som forslag en supportmedarbejder godkender inden afsendelse.

Grænsen mod klassisk chatbot-automatisering ligger i, at reglerne ikke er skrevet på forhånd. En beslutningstræ-bot følger definerede stier, mens en model fortolker fritekst og kan svare på formuleringer ingen har forudset. Det gør dækningen bredere og opførslen mindre forudsigelig.

Opad grænser use-casen til generelle AI-agenter der udfører handlinger i systemer. Så snart modellen selv annullerer ordrer, udsteder kreditnotaer eller ændrer abonnementer, flytter tyngdepunktet fra sprog til handling. Nedad grænser den til ren dokumentsøgning, hvor modellen kun finder frem til en artikel og ikke formulerer et svar.

Et typisk opsæt starter med klassifikation. En lille og billig model som GPT-5 nano eller Claude Haiku 4.5 afgør emne, sprog, hastegrad og om henvendelsen overhovedet skal behandles automatisk. Klassifikationen bestemmer resten af flowet og bør derfor evalueres for sig.

Dernæst hentes kontekst. Det sker som regel med RAG mod videnbase, hjælpeartikler og tidligere løste tickets, kombineret med opslag i CRM efter kundens ordrer, abonnement og historik. Kvaliteten af svaret afhænger mere af dette trin end af modelvalget. En stærk model med forkert kontekst producerer et velformuleret forkert svar.

Selve svaret genereres af en større model som GPT-5.6 Sol eller Claude Sonnet 5, med en systemprompt der fastlægger tone, sprog, hvad der må loves, og hvad der aldrig må siges. Til sidst ligger et kontrollag: tjek af om svaret har dækning i den hentede kontekst, om det indeholder personoplysninger det ikke burde, og om det skal videre til et menneske.

Den hyppigste fejl er hallucination om politikker. Modellen kender generelle mønstre for returret og refusion fra træningsdata og udfylder huller når videnbasen er tavs. Resultatet er et svar der lyder autoritativt og forpligter virksomheden til noget den ikke har lovet. Modvægten er at instruere modellen i eksplicit at sige at den ikke ved det, og at måle hvor ofte den gør det.

En anden fejl er skjult forældelse. Videnbasen bliver opdateret i ét system, mens indekset til RAG bliver bygget sjældnere. Kunder får så svar der var korrekte for tre måneder siden, og fejlen er svær at opdage fordi svarene fortsat ser rigtige ud.

Eskalering fejler typisk begge veje. Systemet eskalerer for lidt, fordi modellen forsøger at være hjælpsom i stedet for at give op, eller for meget, så supportteamet drukner i sager automatikken kunne have klaret. Begge dele kræver måling på faktisk løsningsgrad, ikke på hvor mange samtaler der blev afsluttet uden menneske.

Endelig undervurderes lange samtaler. Når en tråd vokser, fylder tidligere beskeder context window, og modellen begynder at vægte sine egne tidligere svar højere end kildematerialet. Fejl bliver dermed forstærket i stedet for korrigeret.

Deflection rate alene er et misvisende tal. En henvendelse der lukkes automatisk og genåbnes to dage senere tæller som succes i statistikken og som fiasko for kunden. Mål i stedet på om problemet blev løst i første forsøg, og hold det op mod tilfredshed for de samme sager.

Det er også værd at afklare tidligt, hvem der ejer et forkert svar. Når modellen lover en refusion virksomheden ikke giver, er spørgsmålet ikke teknisk men organisatorisk. Klare regler for hvilke løfter automatikken må afgive, og hvem der rydder op, afgør hvor meget ansvar systemet realistisk kan få.