Bliv en del af mit community / gratis nyhedsbrev — tilmeld dig her
Hvad spørger kunderne om? Lad AI læse mønstrene i supporten
Af Greg Nowak. Senest opdateret 2026-09-04.
Supportsystemet fortæller mere end, hvilke sager teamet har lukket. Det viser også, hvor kunderne går i stå, hvad de misforstår, og hvilke dele af produktet eller driften der bliver ved med at skabe ekstra arbejde.
De mønstre er bare svære at få øje på. En supportchef husker naturligt de mest besværlige sager, men kan sjældent se, om et problem er vokset fra fem til 25 henvendelser, eller om den samme fejl bliver beskrevet på ti forskellige måder.
Her kan AI være nyttig uden at svare en eneste kunde. Når afsluttede tickets klassificeres efter emne, sandsynlig årsag og løsningsstatus, får virksomheden et mere sammenhængende billede af, hvad kunderne faktisk spørger om – og hvad der bør gøres ved det.
Begynd med den beslutning, analysen skal understøtte
“Lad os analysere alle vores tickets” er ikke et mål, der kan styre en løsning. Begynd i stedet med en konkret beslutning, som nogen i virksomheden har ansvar for.
Skal en mulig produktfejl prioriteres? Bør en vejledning skrives om? Eller mangler supportteamet en fælles procedure? Når spørgsmålet er klart, kan man definere de kategorier, analysen skal levere.
En enkel klassifikation kan bestå af fire felter:
- Emne: Hvad handler henvendelsen om?
- Årsag: Skyldes problemet eksempelvis en produktfejl, manglende information eller en proces, kunden har misforstået?
- Løsningsstatus: Blev sagen løst, omgået, sendt videre eller lukket uden en tydelig løsning?
- Usikkerhed: Er oplysningerne gode nok til en klassifikation, eller bør sagen vurderes manuelt?
Usikkerhedsfeltet er ikke en teknisk detalje. En løsning bliver mindre troværdig, hvis den presses til at afgive et sikkert svar på et mangelfuldt grundlag. “Kan ikke afgøres” er ofte det mest brugbare svar.
Ticketdataene findes allerede i HubSpot og Zendesk
HubSpots Tickets API 2026-03 kan hente tickets enkeltvis, som lister eller i batches. Integrationen kan vælge bestemte egenskaber, hente historiske egenskabsværdier og få ID’er på tilknyttede objekter. Analysen kan dermed begrænses til relevante ticketfelter, samtidig med at hvert resultat bevarer en reference til den oprindelige sag.
API’et kan også forbinde tickets med blandt andet kontakter og virksomheder. Det er en mulighed, ikke en opfordring til at sende alle tilgængelige oplysninger videre til en AI-model. En fornuftig implementering udvælger kun de felter, der er nødvendige for det aftalte formål.
Skal analysen følge nye eller ændrede sager, kan HubSpots Webhooks API 2026-03 give besked om oprettede tickets, ændringer i udvalgte egenskaber og ændrede relationer. Webhooken fungerer som et signal om, at en sag skal hentes eller lægges i kø. Integrationen behøver derfor ikke hele tiden at spørge HubSpot, om noget har ændret sig.
Integrationsformen skal dog afklares først. HubSpots guide beskriver de nævnte abonnementsendpoints for ældre offentlige apps og henviser projektbaserede apps til en særskilt konfiguration. Den konkrete HubSpot-opsætning afgør derfor, hvordan løsningen bør bygges.
I Zendesk kan Incremental Exports hente de tickets, der er ændret siden sidste kørsel. Zendesk anbefaler cursorbaseret eksport, fordi den giver en mere ensartet ydelse og responsstørrelse. Cursoren gemmes efter hver kørsel og bruges ved den næste, så hele historikken ikke skal eksporteres igen.
Kommentarerne kræver et ekstra tjek. I Zendesks hændelseseksport følger selve kommentarteksten kun med, når den relevante comment_events-sideload anvendes. Ellers får integrationen blot oplyst, at kommentaren findes, og om den er offentlig. Det er værd at kontrollere datagrundlaget, før man begynder at diskutere kvaliteten af AI-resultaterne.
| Arbejdstrin | Det kan automatiseres | Det kræver faglig kontrol | Forretningsresultat |
|---|---|---|---|
| Udvælgelse | Hent nye eller afsluttede tickets siden sidste kørsel | Godkend periode, køer og felter | Et afgrænset datagrundlag |
| Klargøring | Fjern unødvendige identifikatorer og normalisér teksten | Kontrollér eksempler med følsomt indhold | Relevant input til analysen |
| Klassifikation | Tildel emne, årsag, status og usikkerhed | Gennemgå en stikprøve | Sammenlignelige kategorier |
| Opfølgning | Optæl gentagelser og ændringer over tid | Undersøg markante udsving | Prioriterede signaler |
| Handling | Opdatér dashboard og links til kildesager | Placér ansvar og beslut næste skridt | En konkret produkt-, proces- eller dokumentationsopgave |
En stabil taksonomi slår en flot demonstration
Den første version bør have få kategorier med klare beskrivelser. Ændres de hver uge, kan udviklingen ikke sammenlignes over tid. Er de for brede, forsvinder de forskelle, som nogen faktisk kan handle på.
“Loginproblem” kan for eksempel være for upræcist. Produkt- og supportteamet har sandsynligvis brug for at skelne mellem glemt adgangskode, manglende invitation og en teknisk fejl, fordi de tre problemer har forskellige ejere og løsninger.
En prøveperiode med afsluttede tickets er et godt sted at begynde. Lad derefter en fagperson klassificere en stikprøve manuelt. Uenighederne er nyttige: De viser, om instruktionen er uklar, kategorierne overlapper, eller ticketen ganske enkelt ikke indeholder svaret.
Kontrollen bør gentages med jævne mellemrum. Produktet ændrer sig. Kunderne bruger nye ord, og supportteamets praksis flytter sig også.
Et ugentligt dashboard bør derfor vise mere end de største kategorier. Medtag udviklingen fra tidligere perioder, andelen af usikre klassifikationer, omkostningen ved kørslen og links til konkrete kildesager. Så kan et usædvanligt udsving undersøges, før det bliver behandlet som et sikkert faktum.
Batchbehandling passer ofte bedre end realtid
En ticketanalyse behøver sjældent levere et svar på få sekunder. OpenAI Batch API er beregnet til større samlinger af API-kald, som behandles asynkront. Batchobjektet registrerer blandt andet behandlingsvindue, status, gennemførte og fejlede kald samt tokenforbrug.
Det passer godt til en natlig eller ugentlig kørsel, hvor nye tickets samles og analyseres på én gang. Ifølge den godkendte API-beskrivelse kan behandlingen ske inden for 24 timer og til en lavere pris end tilsvarende synkron behandling.
Pris pr. ticket fortæller dog ikke hele historien. Virksomheden bør også måle, hvor meget tid der går til stikprøvekontrol, vedligeholdelse af kategorier og opfølgning på resultaterne. Det er den samlede driftsomkostning, der afgør, om løsningen giver mening.
Pseudonymisering er kun en del af databeskyttelsen
Supporttickets kan indeholde navne, mailadresser, ordrenumre og følsomme oplysninger, som kunden selv har skrevet i et fritekstfelt. En fornuftig proces fjerner unødvendige identifikatorer, før teksten sendes til klassifikation, og begrænser outputtet til de oplysninger, dashboardet faktisk skal bruge.
Det afslutter ikke databeskyttelsesarbejdet. Behandlingsgrundlag, ansvar og information til de registrerede skal stadig vurderes. I Datatilsynets årsberetning 2025 beskrives tilsyn med organisationers brug af generativ AI. Her fremhæves blandt andet organisatoriske tiltag, tekniske risikobegrænsninger, en klar fordeling af roller og ansvar samt behovet for, at den registrerede ved, når personoplysninger bruges som input i en AI-løsning.
Databeskyttelsen bør derfor tegnes ind i løsningen fra begyndelsen. Dokumentér formålet, datavejen, de anvendte felter, leverandørrollerne, slettepraksis og den menneskelige kontrol, før analysen bliver en fast del af driften.
Hvornår skaber ticketanalysen reel værdi?
Dashboardet er først nyttigt, når hvert vigtigt mønster får en ejer. Flere sager om den samme funktion kan føre til en produktundersøgelse. Gentagne misforståelser kan udløse en ændring i hjælpeteksten. Mange midlertidige omgåelser uden en varig løsning kan pege på teknisk gæld.
For danske virksomheder, der vil afprøve arbejdsgangen, kan Greg hos nowa.dk hjælpe med at afgrænse en AI-automatisering omkring de eksisterende supportdata. En realistisk første leverance er en tilbagevendende rapport med en stabil taksonomi, stikprøvekontrol, synlige driftsomkostninger og adgang til kildesagerne – ikke en fuldautomatisk dom over kundernes problemer.
Vælg én supportkø, én periode og ét beslutningsbehov. Hvis analysen konsekvent hjælper produkt-, drifts- eller supportansvarlige med at finde og prioritere gentagne problemer, kan den udvides. Hvis ikke, har virksomheden fået svaret gennem en afgrænset investering og et gennemskueligt datagrundlag.
Relateret på GrN.dk
- Fra salgsmøde til CRM: Automatisér opfølgningen uden datarod
- Montørens talenote skal blive til en arbejdsordre – ikke rå lyd
- Har jeres AI-chatbot husket at sige, at den er en bot?
Brug for hjælp til den slags opgaver?
Tal med Greg om jeres ticketanalyse Kontakt Greg her.
Kilder
Sidst ændret
2026-09-04