Opbygning af en ChatGPT-drevet kundeservice

En ChatGPT-drevet kundeservice er en chatbot eller assistent, der bruger en sprogmodel til at forstå henvendelser, hente godkendt viden og foreslå eller udføre næste skridt. Den bør bygges som et kontrolleret serviceflow med datagrænser, menneskelig overdragelse og løbende kvalitetsmåling.

Hvad betyder en ChatGPT-drevet kundeservice?

En ChatGPT-drevet kundeservice bruger generativ AI til at læse kundens spørgsmål, finde den mest relevante kontekst og formulere et svar i et naturligt sprog. Løsningen kan ligge i en chat på websitet, i et billetsystem, i en app, i en intern agentassistent eller som et lag oven på eksisterende kundeservicesystemer.

Den afgørende forskel fra en klassisk regelbaseret chatbot er, at en sprogmodel kan håndtere flere formuleringer af samme problem, stille opklarende spørgsmål og samle oplysninger fra flere tekstkilder. Det gør den mere fleksibel, men også sværere at styre. Derfor bør den bygges med klare opgaver, godkendte datakilder, tekniske grænser og faste regler for overdragelse til mennesker.

I praksis bør du skelne mellem ChatGPT som brugerflade og OpenAI API eller andre model-API’er som teknisk byggeklods. En professionel kundeserviceintegration bør normalt ikke afhænge af, at medarbejdere kopierer kundedata ind i en almindelig samtaleflade. Den bør bygges som et system, hvor data, roller, adgang og logs kan styres.

Hvilke opgaver bør løsningen håndtere først?

Start med henvendelser, hvor svaret kan afgrænses tydeligt, og hvor risikoen ved et forkert svar er lav. Det kan være åbningstider, returfrister, status på en kendt proces, forklaring af produkter, vejledning i simple formularer eller sortering af sager efter emne. Den slags opgaver har ofte gentagne spørgsmål, faste svargrundlag og tydelige eskaleringspunkter.

Undgå at begynde med klager, opsigelser, følsomme personoplysninger, kreditvurderinger, helbredsoplysninger eller sager, hvor kunden har krav på en individuel vurdering. Her kan AI stadig bruges som støtte til medarbejdere, men automatiske kundesvar kræver mere kontrol, dokumentation og menneskelig gennemgang.

En nyttig første sortering er at dele kundeserviceopgaver i tre niveauer:

• Informationssvar, hvor modellen kun må hente og gengive godkendt viden.
• Proceshjælp, hvor modellen guider kunden gennem trin, men ikke ændrer noget i systemerne.
• Systemhandlinger, hvor modellen kan foreslå eller starte en handling, som applikationen kontrollerer.

Denne opdeling passer godt sammen med automatisering af kundehenvendelser med AI, fordi den gør det synligt, hvilke henvendelser der faktisk egner sig til automatisering, og hvilke der bør sendes videre.

Hvordan bygges vidensgrundlaget uden at gøre modellen til et frit opslagsværk?

En kundeserviceassistent bør ikke svare ud fra en løs blanding af modelviden, gamle dokumenter og medarbejdernes uformelle formuleringer. Den bør hente svar fra et afgrænset vidensgrundlag: produktsider, politikker, handelsbetingelser, supportartikler, interne procesbeskrivelser og godkendte standardsvar.

Teknisk kan dette bygges med retrieval-augmented generation, hvor kundens spørgsmål bruges til at finde relevante tekststykker i en søgbar vidensbase, før modellen skriver svaret. Fordelen er, at svaret kan forankres i aktuelle dokumenter i stedet for i modellens generelle træning.

Vidensgrundlaget bør have ejerskab. Hver tekstkilde skal have en ansvarlig afdeling, en opdateringsrytme og en udløbsdato, hvis indholdet ændrer sig ofte. Det gælder især priser, vilkår, leveringstider, tekniske begrænsninger og politikker for returnering eller reklamation. Hvis kilden er forældet, kan modellen lyde sikker og stadig give et forkert svar.

En praktisk regel er, at AI-løsningen kun må svare, når den kan finde en relevant kilde med tilstrækkelig styrke. Hvis den ikke finder et sikkert grundlag, skal den spørge om flere oplysninger, give et begrænset standardsvar eller sende sagen videre til en medarbejder.

Hvordan bør samtaleflowet se ud fra første spørgsmål til afslutning?

Et godt samtaleflow begynder med klassificering, ikke med et langt svar. Systemet skal først afgøre, hvad kunden forsøger at opnå: få information, ændre en ordre, rapportere en fejl, forstå en faktura, klage, opsige, booke service eller tale med en medarbejder. Derefter kan det vælge den rigtige vej.

Flowet bør normalt have fem trin. Først identificeres emne og risiko. Derefter indsamles kun de nødvendige oplysninger. Tredje trin er opslag i vidensgrundlag eller systemer. Fjerde trin er svar, forslag eller intern sagsnotits. Femte trin er afslutning, eskalering eller feedback.

Det gør løsningen mere stabil, fordi modellen ikke skal improvisere hele samtalen. Den arbejder inden for et designet forløb, hvor applikationen bestemmer, hvilke oplysninger der må indsamles, hvilke kilder der må bruges, og hvornår et svar er for usikkert.

Flowet bør også have en tydelig afslutning. Kunden skal vide, om sagen er løst, om der er oprettet en sag, om en medarbejder vender tilbage, eller om kunden selv skal gøre noget. Uklare afslutninger skaber flere henvendelser og gør det sværere at måle, om AI-løsningen faktisk hjælper.

Hvornår skal modellen bruge værktøjskald i stedet for almindeligt tekstsvar?

Et almindeligt tekstsvar er nok, når kunden spørger om noget, der står i vidensbasen. Værktøjskald er relevante, når systemet skal hente eller sende data i et andet system. Det kan være ordrestatus, leveringsspor, abonnementsstatus, lagerinformation, sagshistorik, oprettelse af ticket eller forslag til en refundering.

Ved værktøjskald bør modellen ikke have fri adgang til systemerne. Den bør kun kunne vælge mellem få, navngivne handlinger, som applikationen stiller til rådighed. Applikationen skal validere input, tjekke brugerens rettigheder, logge handlingen og beslutte, om handlingen kræver menneskelig godkendelse.

Denne niveaudeling gør det lettere at afgøre, hvor en løsning kan automatisere direkte, og hvor den bør fungere som medarbejderstøtte. Den passer også med bredere integrering af AI i eksisterende kundeservicesystemer, fordi systemadgang bliver en arkitekturbeslutning i stedet for en samtalebeslutning.

Hvordan begrænses adgang til kunde- og ordredata?

Kundedata bør kun sendes til modellen, når det er nødvendigt for den konkrete opgave. Hvis kunden spørger om en generel returregel, er der sjældent behov for navn, adresse eller ordrehistorik. Hvis kunden spørger om en specifik levering, kan systemet nøjes med ordrestatus, leveringsvindue og relevante undtagelser.

Dataminimering skal indbygges i integrationen. Det betyder, at applikationen udvælger felter, maskerer unødvendige oplysninger og holder følsomme data ude af modellen, hvor det er muligt. En sprogmodel skal ikke se hele kundens profil, hvis et begrænset opslag kan løse sagen.

OpenAI oplyser for API-platformen, at data sendt til API’en siden 1. marts 2023 ikke bruges til at træne eller forbedre modeller, medmindre kunden aktivt vælger at dele data. Samtidig kan misbrugsovervågningslogs som standard indeholde kundeindhold og blive opbevaret i op til 30 dage, med særlige muligheder og begrænsninger for reduceret retention. Det gør leverandørvilkår, databehandleraftaler, endpointvalg og logging til en del af den tekniske afklaring.

Hvis løsningen bruges i Danmark eller EU, bør kundevendte AI-svar også vurderes for gennemsigtighed. EU AI Act har en generel anvendelsesdato 2. august 2026 og indeholder en regel om, at personer som udgangspunkt skal informeres, når de interagerer direkte med et AI-system, medmindre det er indlysende i konteksten. Den konkrete vurdering afhænger af brugen, men kravet bør tænkes ind i brugerfladen tidligt.

Hvordan håndteres fejl, hallucinationer og usikre svar?

En sprogmodel kan formulere et overbevisende svar, selv når grundlaget er svagt. I kundeservice er det især risikabelt ved vilkår, priser, leverancer, tekniske fejl, rettigheder og klager. Derfor skal løsningen have en usikkerhedspolitik: hvad må modellen sige, når den ikke finder et sikkert svar?

Den mest robuste løsning er ikke at bede modellen om altid at svare. Den bør kunne vælge mellem svar, opklarende spørgsmål, begrænset standardsvar og eskalering. Hvis kundens problem ligger uden for vidensbasen, eller hvis kilderne modsiger hinanden, skal svaret være kort og forsigtigt, eller sagen skal sendes videre.

Fejlhåndtering bør testes med realistiske og vanskelige henvendelser. Det omfatter stavefejl, vrede kunder, ufuldstændige oplysninger, forsøg på at få modellen til at bryde reglerne, tvetydige produktnavne og spørgsmål, der blander flere sager. Testen bør gentages, når vidensbasen, modellen eller integrationslogikken ændres.

OWASP beskriver flere risikokategorier for LLM-applikationer, herunder manipulerede inputs, usikker outputhåndtering, følsom informationslækage og for stor autonomi. I kundeservice betyder det, at sikkerhed ikke kun handler om filterord. Det handler om adgangsgrænser, outputvalidering, overvågning og menneskelig kontrol ved risikofyldte handlinger.

Hvordan sikres menneskelig overdragelse?

Menneskelig overdragelse skal være en normal del af designet, ikke en nødknap. Kunden skal kunne komme videre, når sagen er kompleks, følelsesmæssigt belastet, juridisk følsom, teknisk uklar eller økonomisk betydningsfuld. Modellen bør også selv kunne vurdere, at en sag kræver overdragelse.

En god overdragelse indeholder mere end en besked om, at en medarbejder overtager. Systemet bør oprette et kort sagsresumé, liste de oplysninger kunden allerede har givet, markere usikkerheder og vise, hvilke kilder modellen brugte. Det sparer tid for medarbejderen og mindsker risikoen for, at kunden skal gentage hele forløbet.

Der bør være faste kriterier for overdragelse. Det kan være utilfredshed, ord som klage eller opsigelse, krav om kompensation, gentagne misforståelser, følsomme oplysninger, høj værdi, kendte fejlscenarier eller lav sikkerhed i det fundne svargrundlag. Kriterierne skal kunne ændres af kundeserviceledelsen uden at bygge hele løsningen om.

Menneskelig overdragelse hænger tæt sammen med AI-drevne chatbots og kundeoplevelser, fordi en hurtig chatbot ikke skaber værdi, hvis den fastholder kunden i et forkert spor.

Hvilke data- og sikkerhedskrav bør afklares før drift?

Før drift bør organisationen afklare, hvilke data AI-løsningen må se, hvor data behandles, hvor længe logs gemmes, hvem der kan læse samtalerne, og hvordan fejl rapporteres. Det er også nødvendigt at afklare, om løsningen må bruge kundens tidligere sager, og om der skal være særskilte regler for børn, medarbejderdata, helbredsoplysninger eller betalingsoplysninger.

Adgang til systemer bør følge princippet om mindst mulige rettigheder. Hvis assistenten kun skal se ordrestatus, skal den ikke kunne ændre leveringsadresse. Hvis den kun skal foreslå et svar, skal den ikke kunne sende svaret uden godkendelse. Hvis den kan oprette sager, bør den ikke kunne lukke dem automatisk i samme flow.

Der bør også være en plan for sikkerhedslogning. Loggen skal kunne vise, hvilken version af vidensgrundlaget der blev brugt, hvilke værktøjskald der blev udført, hvilke svar der blev sendt, og hvornår en medarbejder overtog. Det er nyttigt ved fejlretning, intern kontrol og kundeklager.

AI-sikkerhed i kundeservice er beslægtet med bredere sikkerhedsaspekter ved AI i kundeservice, men den praktiske kerne er enkel: modellen skal have mindre adgang end et menneske, medmindre der er en dokumenteret grund til mere.

Hvordan måles kvaliteten efter lancering?

Kvalitet bør ikke måles med automatiseringsgrad alene. En chatbot kan besvare mange henvendelser og stadig skabe dårlig kundeservice, hvis svarene er upræcise, for lange eller svære at handle på. Målingen bør kombinere effektivitet, korrekthed, sikkerhed og kundeoplevelse.

Relevante målepunkter er løsningsgrad uden overdragelse, andel sager sendt videre, svartid, kundetilfredshed, genåbnede sager, fejlklassificeringer, antal svar uden sikkert kildegrundlag og medarbejdernes tidsforbrug pr. overdraget sag. For systemhandlinger bør du også måle afviste handlinger, manuelle godkendelser og tilbageførte fejl.

Kvalitetsmåling kræver en manuel stikprøve. Udvælg løbende samtaler fra forskellige emner, risikoniveauer og kanaler. Tjek om svaret var korrekt, om kilden var relevant, om tonen var passende, om kunden fik næste skridt, og om systemet burde have eskaleret tidligere.

En moden løsning bruger målingen til at forbedre vidensbasen, ikke kun modellen. Mange fejl skyldes uklare interne artikler, modstridende regler, manglende produktsprog eller uens medarbejderpraksis. AI-løsningen kan derfor afsløre svagheder i kundeserviceprocessen, som også mennesker kæmper med.

Hvordan passer løsningen ind i eksisterende kundeservice?

En ChatGPT-drevet kundeservice bør ikke stå som en isoleret kanal ved siden af resten af organisationen. Den skal passe ind i køer, roller, svartider, vidensbase, CRM, ticketsystem, telefonnoter og rapportering. Ellers bliver den en ekstra indbakke, som medarbejderne skal rydde op efter.

Integration bør begynde med en kortlægning af henvendelsesveje. Hvor kommer kunderne fra? Hvilke emner fylder mest? Hvilke systemer bruger medarbejderne? Hvilke svar kræver login? Hvilke sager bliver ofte sendt mellem afdelinger? Svarene afgør, hvor AI-laget skal placeres.

For nogle organisationer er den bedste start en intern assistent, der foreslår svar til medarbejdere. For andre giver en kundevendt chatbot mening fra første fase. Forskellen afhænger af datakvalitet, risikoniveau, volumen og hvor ensartede processerne er.

Det er ofte en fejl at gøre AI-løsningen til et separat projekt uden kundeserviceejerskab. IT kan bygge integrationen, men kundeservice skal eje svargrundlag, eskaleringsregler, tone, undtagelser og målepunkter. Ellers bliver systemet teknisk fungerende, men operationelt svagt.

Hvilke typiske fejl gør projekter dyrere end nødvendigt?

Den første fejl er at automatisere for bredt. Hvis løsningen fra starten skal håndtere alle produkter, alle kanaler og alle kundetyper, bliver test, dataarbejde og risikostyring tungere end nødvendigt. Et mindre, tydeligt afgrænset område giver hurtigere læring.

Den anden fejl er at undervurdere vidensarbejdet. Mange organisationer opdager først under AI-projektet, at deres supportartikler er uens, forældede eller skrevet til medarbejdere, ikke kunder. Modellen kan ikke kompensere stabilt for et uklart svargrundlag.

Den tredje fejl er at give modellen handlinger for tidligt. Opslag og forslag er ofte nok i første fase. Direkte ændringer i kundedata, refunderinger eller annulleringer bør først indføres, når adgangsstyring, logging, test og menneskelig godkendelse er på plads.

Den fjerde fejl er at måle succes med antal automatiserede samtaler uden at undersøge kvaliteten. Hvis kunden vender tilbage, ringer ind eller klager bagefter, var sagen ikke løst. En god AI-løsning reducerer den samlede friktion, ikke kun antallet af beskeder i første kanal.

Hvordan kan en realistisk første version se ud?

En realistisk første version dækker et begrænset område, for eksempel leveringsspørgsmål eller produktvejledning for én produktgruppe. Den bruger en renset vidensbase, få faste værktøjskald, tydelige grænser for persondata og en enkel overdragelse til medarbejdere.

Første version kan bygges sådan: vælg fem til ti henvendelsestyper, skriv eller opdater de nødvendige supportartikler, definer hvilke oplysninger kunden skal give, beslut hvornår der skal eskaleres, og test med historiske samtaler uden at sende svar til rigtige kunder. Derefter kan løsningen åbnes gradvist for et mindre udsnit af trafikken.

En kontrolleret start gør det muligt at lære, hvilke spørgsmål modellen klarer godt, hvor vidensbasen mangler detaljer, og hvor medarbejdere stadig bør overtage. Det giver et mere solidt grundlag for at udvide til flere emner, kanaler eller handlinger.

Hvis løsningen senere skal kobles til lager, økonomi eller abonnementssystemer, bør hvert nyt værktøjskald behandles som en ny integration med egne rettigheder, testcases og stopregler. Det holder væksten styret, selv når assistenten bliver mere nyttig.

Hvilke kilder ligger til grund?

Artiklen bygger på OpenAI-dokumentation om function calling, file search og data controls i OpenAI API. Den bruger også OWASP’s Top 10 for Large Language Model Applications og EU’s forordning om kunstig intelligens, især gennemsigtighedsreglen i EU AI Act.