Eget ärendehanteringssystem med AI-stöd

När en kund skickar in en fråga via ett supportformulär skapas ett ärende i vårt eget system. Ett svarsutkast ligger redan där när jag öppnar ärendet, skrivet i vår ton och grundat i hur vi svarat på liknande frågor förut. Jag läser, justerar och skickar. Svarar kunden på mejlet hamnar svaret i samma tråd, i stället för att försvinna i en inkorg.

Systemet är egenutvecklat, så vi kan lägga till funktioner och forma det helt efter vår verksamhet. Interna ärenden skickar vi in via en koppling till Slack.

Tidigare var det rörigare. Frågor kom in via formulär, vi svarade med mejl, men i samma sekund som kunden svarade hoppade samtalet över till en inkorg. Ärendet i systemet såg dött ut medan dialogen fortsatte någon annanstans. För ärenden med några vändor fram och tillbaka var det lätt att tappa tråden, och risken att svara samma sak två gånger var påtaglig.

Vad vi ville uppnå

Målet var att hålla hela kundsamtalet på ett ställe, från första frågan till sista svaret. Dels för överblicken, men också för att slippa känslan av att en kund glider mellan stolarna. Vi ville kunna hantera ärenden från flera olika appar på samma ställe i kronologisk ordning, och generera svar anpassade efter produkten ärendet berör. För extra trygghet bad vi även AI att läsa inkommande ärenden och klassificera hur brådskande de är, så att vi snabbt kan ta tag i det akuta.

Att få ett färdigt svarsutkast i vår egen ton sparar mycket tid och gör att vi snabbt kan beta av frågor och ge återkoppling.

Vi ville även hantera interna frågor i samma system. Kundärenden som tyder på tekniska problem kan snabbt eskaleras och skickas vidare till utvecklaren. Vi behövde också ett ställe att samla idéer för framtida produkter och funktioner, i stället för att hantera dem i separata dokument.

Problemen som behövde lösas

Det svåraste var att fånga kundens svar tillbaka in i ärendet. En fråga kom in och vi kunde svara, men så fort kunden svarade på mejlet låg fortsättningen bara i en inkorg, frånkopplad från ärendet. För att stänga den luckan behövde systemet kunna ta emot och läsa inkommande mejl, inte bara skicka dem. Lösningen blev att ta emot svaren på en egen subdomän, så att den vanliga mejlleveransen lämnas orörd, och att lägga en signerad kod i svarsadressen som pekar varje svar tillbaka till rätt ärende.

En annan sak var överblicken. Systemet fungerade men var tråkigt och rörigt att navigera. Vi lät Claude Design göra om gränssnittet, så att ärendelistan och trådarna blev lätta att skanna och beta av.

Vad vi byggde

Ärenden kommer in från flera håll. Kundformulär, interna idéer och buggar från både rapporter och felrapporteringsverktyg. Allt hamnar i samma lista, sorterat med det senaste överst. Det innebär en stor skillnad att slippa leta i olika inkorgar. När jag svarat på ett ärende öppnas nästa nya automatiskt, vilket gör att det går snabbt att beta av inkommande ärenden.

Svarsutkastet skapas så fort ett ärende kommer in, och samtidigt bedömer AI:n hur brådskande det är så att vi snabbt kan fånga upp det akuta. När kunden sedan svarar på mejlet tar en tjänst emot det, matchar den signerade koden mot rätt ärende, hämtar texten och lägger den i tråden som ett kundsvar. Ärendet flyttas tillbaka till Nytt så det dyker upp överst igen, och ett färskt utkast skrivs som den här gången väger in hela konversationen, inte bara den första frågan.

Utkastet vilar på en liten kunskapsbank med produktfakta och på hur vi undertecknar och länkar till de riktiga villkoren. AI:n använder det som underlag och anpassar efter den aktuella frågan, så att svaret får en personlig ton i stället för ett standardsvar.

Inkommande buggar hanteras i en egen lista. När ett ärende visar sig vara ett tekniskt fel går det vidare som en bugg med en länk tillbaka till kundärendet, så att kunddialogen kan fortsätta medan problemet hanteras av utvecklaren. Där läser AI:n den faktiska app-koden, spårar trolig orsak och lämnar ett förslag på åtgärd i buggens egen logg. Den skriver aldrig i koden själv. Den lämnar ett underlag som någon med ansvar för appen tar ställning till.

Resultat och lärdomar

Första gången en kund svarade kom själva texten in tom. Webhooken berättade att ett mejl tagits emot, men brödtexten gick inte att läsa. Felet visade sig vara en behörighetsnivå på API-nyckeln. Den fick skicka mejl men inte läsa inkommande. För att slippa gissa nästa gång lät vi systemet skriva det faktiska felet rakt in i ärendet, så att orsaken blev läsbar i stället för gömd bakom ett allmänt felmeddelande. Det var en liten ändring som gjorde att nästa fel kunde diagnostiseras på sekunder.

En annan vända handlade om tålamod. En DKIM-signatur tog fjorton minuter att slå igenom hos den ena domänleverantören medan den andra var klar på några sekunder. Inget var fel, det var bara att vänta och låta bli att börja peta i något som redan låg rätt.

Det var även viktigt att värdera hur affärskritiska olika funktioner är. Appen och databasen är affärskritiska, och det är inte jag som utvecklar dem. Där läser AI:n och föreslår hur inkommande fel kan hanteras, men ändrar aldrig något. Supportsystemet runt omkring är mindre känsligt, och där bygger vi vidare tillsammans i dialog. Att hålla isär de två zonerna gör att jag vågar släppa fram automatiken där den hör hemma och hålla den i strikt koppel där den inte gör det.

Det är inte bara värdefullt att AI:n skriver ett snyggt svar. Minst lika viktigt är att varje svar jag skriver för hand blir material som systemet återanvänder. Andra gången en liknande fråga kommer in är utkastet redan mer eller mindre färdigt att skicka. Arbetet jag lägger ner i dag gör mig snabbare i morgon, i stället för att försvinna i en skickat-mapp.

Designen spelar också roll, och Claude Design gjorde det mycket trevligare att arbeta i. Tydligheten i ikoner och färger minskar risken för fel eller att vi tappar bort något. En lärdom var hur enkelt det gick att justera själva logiken med en prompt för att göra systemet mer lättarbetat, till exempel att jag direkt hoppar in i nästa ärende efter att ett svar skickats.

Hur vi går vidare

Nästa steg är felrapporterna. Flocken-appen skickar redan sina krascher till felrapporteringsverktyget Sentry. Det återstår att låta dem flöda in i samma lista och få en första genomgång av AI:n innan utvecklaren kopplas in. Tanken är att en krasch ska komma in med en trolig orsak och ett förslag redan formulerat, så att den som ska åtgärda börjar en bit in i problemet.

Kunskapsbanken ska växa med de faktiska villkoren och de vanligaste frågorna, så att utkasten blir träffsäkrare ju fler ärenden vi hanterar. När AI:n kategoriserar ärenden och vi ser att svarsförslagen håller, kan vi på sikt låta den svara direkt på enklare, återkommande frågor, så att kunden slipper vänta på vår granskning. Det är ett avgränsat undantag för frågor där förslagen bevisat sig, inte en generell avveckling av granskningen.

Supportsystemet är en del av ett större sätt att driva bolaget, där samma mönster återkommer. AI:n läser, föreslår och tar fram underlag, och en människa fattar beslutet. Det mönstret går att flytta till fler delar av verksamheten när nya behov dyker upp.

Verktyg i den här processen