I mina projekt ser jag gång på gång hur förväntningarna på röstbotar har ökat. Många organisationer går in i det med förväntningen att bygga en fullfjädrad AI-stödd tjänst inom några veckor. Verkligheten ser annorlunda ut. Röstbotar kan göra mycket idag, men de behöver en solid grund, tydliga mål och organisationer som är villiga att investera lite mer energi i början.
I mitt webinar (endast på tyska) som en del av den 16:e kundservicveckan presenterade jag två projekt som mycket väl visar vad som är möjligt och vilka fallgropar man måste vara medveten om. Båda användningsfallen kommer från den offentliga sektorn och båda hade samma mål: att avlasta servicecentret och automatisera standardförfrågningar. Trots detta blev projekten mycket olika.
En röstbot som första kontaktpunkt: Vad fungerar bra och vad fungerar inte?
I det första projektet var utmaningen ett mycket högt samtalsvolym. Personalen blev ständigt avbruten samtidigt som de hjälpte medborgarna på plats. Målet var att minska arbetsbelastningen med minst 50 %.
Myndigheten beslutade därför att vidarebefordra alla offentliga samtal till en röstbot. Endast när boten inte kunde lösa förfrågan kunde den som ringde lämna en återuppringningsbegäran. Dessa återuppringningsbegäranden skickas som ett e-postmeddelande med en sammanfattning och en detaljerad transkription till myndighetens personals e-postadress så att de kan hantera dem när tiden tillåter.
Tillvägagångssättet lät enkelt till en början. Idén var att ta de befintliga FAQ-texterna från webbplatsen och använda dem för att bygga en bot. Vi började därför med en klassisk NLU-bot (Natural Language Understanding). Kunden ville inte riskera några hallucinationer och insisterade på en strikt definierad kundresa.
Men det var just här vi insåg hur utmanande ämnet egentligen är. Webbplatsinnehåll skrivs inte för röstbotar. Det växer ofta med tiden, med överlappande eller oprecist innehåll. En bot behöver dock tydlig, entydig och välstrukturerad information. Dialogerna kändes stela och skulle inte ha tillfredsställt de som ringde.
Övergången till en LLM-bot (Large Language Model, LLM) var den verkliga vändpunkten. Entusiasmen var stor: mänskliga dialoger, empati, olika formuleringar. Botten sa ”Åh, det låter underbart” eller ”Jag är ledsen att höra det”. Botten kunde svara på samma fråga på olika sätt och reagerade mer mänskligt utan att avvika från de fastställda riktlinjerna.
Mätbara resultat
Resultatet var tydligt mätbart. Endast cirka 20 % av de ursprungliga samtalen slutade med återuppringningsförfrågningar till personalen. De flesta fallen löstes smidigt av boten. En mycket trevlig bieffekt: upprepade samtal försvann eftersom boten inte har någon ”upptagen”-signal. Anställda har nu mycket mer tid för medborgarna på plats. Detta var precis den lättnad som kunden hade hoppats på.
Boten lägger på för 15 % av samtalen, oftast efter framgångsrika konversationer. Mellan 30 och 40 % av samtalen lägger på själva. Här var vi tvungna att titta på transkriptionerna för att bedöma om detta var bra eller dåligt.
Vad vi lärde oss av detta projekt
Personalresurser
Du kan uppnå snabba vinster, men inget voicebot-projekt fungerar utan aktivt engagemang från kunden. Detta inkluderar att underhålla kunskapsbasen, skapa en ordlista, testa, sammanställa ett lexikon med korrekt uttal för text-till-tal och revidera innehållet. Förutom en ämnesexpert bör det finnas teknisk support som sköter API:erna och har kunskap om skriptning i JavaScript eller XML. Testresurser krävs också. För ett projekt av denna storlek behöver du minst två dedikerade kontakter på kundsidan, helst tre.
LLM-kunskap
En annan viktig punkt är LLM:s inbyggda allmänkunskap. En modell har alltid sin egen bakgrundskunskap. Den måste aktivt begränsas så att den håller sig inom det tillhandahållna innehållet. Detta fungerar bra, men inte till hundra procent. Du måste testa, korrigera och justera när det behövs.
Naturlighet
När en medborgare ställer en fråga, ”tänker” boten – tal till text, text i LLM, text till tal. Dessa pauser måste fyllas. Tangentljud, små tecken på tvekan, variationer i volym. Variationer i bakgrundsljud bidrar till att dialogen känns naturlig.
Barge-in
De flesta botleverantörer har nu också möjlighet att göra så kallade barge-in, det vill säga avbryta dialogen. Botten måste acceptera att den kommer att avbrytas. Om den som ringer redan har fått den information de behöver ska de till exempel inte behöva vänta på resten av botens förskrivna utdata. Nackdelen är att bakgrundsljud också kan tolkas som ett avbrott, till exempel på en tågperrong. Känslighetsinställningar kan lösa detta.
Ett andra exempel: När vidarekoppling ingår i processen
Det andra projektet handlade också om vanliga frågor, men kraven var annorlunda. Botten skulle svara på frågor och avlasta servicecentret – målet var också 50 %. Under öppettiderna behövde dock samtalen vid behov vidarebefordras till backend- eller kontaktcenterpersonal. Det fanns ingen återuppringningsfunktion. Dessutom måste det befintliga Avaya-systemet integreras med avseende på vidarebefordran från botten till medarbetaren.
Teknisk integration
Teknisk integration var en viktig aspekt. Samtalet kommer in till callcentret, vidarebefordras till röstboten och ska vid behov återföras till en anställd. Routingidentifieraren måste tillhandahållas och återspeglas – via användar-till-användar-information eller SIP-header-manipulation. Detta säkerställer att samtalet visas korrekt i den historiska rapporteringen.
Vi har också integrerat Parloas samtalsdatatjänst. Samtalsöversikten visas i Avayas frontend innan medarbetaren tar emot samtalet. På så sätt kan agenterna se i förväg vad samtalet handlar om.
Resultat
Återigen hade vi samma mönster i början: kunden ville importera webbplatsens FAQ. Och återigen fungerade det inte. Innehållet måste revideras manuellt.
En vidarebefordringsgrad på 50 % uppnåddes – en delvis framgång. Idealt sett skulle vidarebefordran inte behövas, men de övriga 50 % automatiserades framgångsrikt.
Det var en 10 % avbrottsfrekvens hos boten – en framgång efter granskning av transkriptionerna. 40 % avbrottsfrekvens hos kunden – detta måste undersökas närmare. Är det en framgång eller inte? Transkriptionerna måste kontrolleras igen och konversationerna granskas. Ett alternativ är att genomföra en nöjdhetsundersökning i slutet av konversationen i boten.
Lärdomar från det andra projektet
Tid som krävs
Projektet pågick i tre månader. Det fungerade bra. Design, konfiguration och tekniska tester från vår sida tog cirka 20 mandagar.
Personalresurser
Vi hade för få kundresurser här. Detta ledde till extra arbete för oss som inte var planerat.
Opt-in
En viktig punkt för båda bots. Medborgaren måste samtycka till inspelningen. Botten spelar alltid in allt – fullständiga transkriptioner är alltid tillgängliga, oavsett om de raderas efter 7 eller 30 dagar.
Opt-in måste begäras. Medborgarna bör också ha möjlighet att säga: ”Nej, jag vill inte fortsätta här.” Eller så kan de fortsätta – och, som vi såg i det första fallet – begära att bli uppringda och endast lämna minimala uppgifter om sig själva.
Här kan det vara lämpligt att börja med NLU, dvs. den strukturerade metoden, och sedan fortsätta med LLM-Agentic-metoden för att säkerställa att opt-in hanteras korrekt. Med en fullständig LLM-start kan detta steg oavsiktligt förbigås.
Vad vi har lärt oss av båda projekten
Röstbotar är kraftfulla idag. Men de är inte plug-and-play-produkter. För att lyckas måste du ta tre saker på allvar.
Först: innehåll. En bot är bara så bra som den kunskapsbas du ger den. Texter från webbplatser kan nästan aldrig användas som de är. De måste revideras och struktureras.
För det andra: resurser. Utan experter på kundsidan som testar, korrigerar och underhåller innehållet kommer projektet att bli långsamt och svårt.
För det tredje: förväntningshantering. Det finns nästan alltid en fas där kvaliteten ännu inte är tillräcklig. Om du fortsätter att förbättra dig ökar kvaliteten snabbt. I båda projekten uppnådde vi höga framgångssiffror och nöjda kunder.
Slutsats
Röstbotar är en stor lättnad när de är korrekt konfigurerade. Tekniken är mogen, men kräver noggrann implementering. Om innehåll, testning och samarbete hanteras på rätt sätt når man en punkt där de flesta förfrågningar automatiseras och teamen får mer tid för ärenden som verkligen kräver mänsklig uppmärksamhet.
