Så designar du eskaleringen från röstagent till människa

1. Bestäm vad som ska utlösa en eskalering

Det finns tre kategorier, och de bör ställas in var för sig.

Kunden ber om det. Den enklaste och den viktigaste. Den bör fungera vid första försöket, oavsett hur kunden uttrycker sig, och utan att agenten först försöker lösa ärendet en gång till.

Agenten får inte göra det som behöver göras. Inte »förstår inte«, utan »har inte behörighet«: kreditering över ett visst belopp, ändring av ett ärende som redan hanteras, allt som kräver en fullmakt agenten inte har. De är kända i förväg och går att lista.

Signaler i samtalet. Tredje kontakten om samma ärende på kort tid. Andra försöket på samma steg. Ord som klagomål, advokat, säga upp abonnemanget. Inom vården är kategorin ännu mer konkret: ett akutsamtal till en tandklinik ska ha tre utfall, och inget av dem är en bokningsdialog.

Lägg märke till att alla tre är händelser och formuleringar, inte tolkningar av humör. Den skillnaden betyder något nu när system som härleder känslor ur rösten är högrisksystem. Ni behöver dem inte heller: en kund som ringer för tredje gången är en starkare signal än ett tonfallsvärde – och en ni kan förklara i efterhand.

2. Bestäm vad som händer när ingen finns där

Det här är punkten som oftast saknas, och den som oftast utlöser klagomålet.

Utanför öppettiderna, i kö, eller när ingen är inloggad – vad händer då? Det sämsta svaret är en koppling till en telefon som ringer utan att någon svarar. Kunden har då lagt tre minuter på att ta sig fram till en människa som inte finns. I vissa branscher är det inte en servicefråga utan en skadefråga – i fastighetsförvaltning kan samtalet halv tre på natten vara en källare som fylls med vatten.

Det finns användbara alternativ: en återuppringning vid en tid kunden själv väljer, ett meddelande med ärendenummer och ett utlovat tidsspann, eller att agenten gör klart det den kan och tydligt säger vad som återstår. Välj ett av dem, och se till att agenten vet vilket som gäller just nu. Ligger telefonin i Teams är slutpunkten redan vald i en rullgardinsmeny – och det är just därför det är så lätt att hoppa över vem som faktiskt tar samtalet.

3. Bestäm vad agenten säger i det ögonblick den lämnar över samtalet

En mening, och den bör innehålla tre saker: att det sker, vem det går till, och hur lång tid det tar.

»Jag kopplar dig till en kollega på kundtjänst, det tar under en minut« räcker. »Ett ögonblick« gör det inte. Och lova inte en väntetid systemet inte kan hålla: en agent som säger under en minut och tar sju är sämre än en som inte sa något.

Det hänger ihop med öppningen. En agent som upplyser om att den är AI och samtidigt erbjuder vägen ut redan i öppningsrepliken gör upplysningen ofarlig. Utan vägen ut är öppenheten bara en varning.

4. Bestäm vad människan får med sig

Det är här det avgörs om eskaleringen kändes som hjälp.

En kund som måste upprepa hela historien för människan drar slutsatsen att agenten var bortkastad tid – hur bra den än fungerade de första två minuterna. Det är den vanligaste enskilda orsaken till att en i övrigt välfungerande uppsättning får dåligt rykte internt, och det är långt ifrån ett undantagsfall: nästan hälften av bolagen skickar ingenting vidare från agenten till människan som tar över.

Det minimum som bör ligga klart innan människan svarar: vem som ringer, vad ärendet gäller med kundens egna ord, vad agenten redan har gjort eller slagit upp, och varför den kopplade över. Fyra rader. Finns de inte där är eskaleringen inte färdigbyggd.

5. Bestäm vem som äger ärendet om samtalet bryts

Kopplingar bryts. Kunder lägger på i kön. Förbindelser faller.

Frågan är vad som händer då: ligger det kvar ett ärende som någon faktiskt ser, eller försvinner ärendet? Är svaret det senare läcker eskaleringsvägen – och läckan är osynlig, eftersom samtalet tekniskt sett besvarades och räknas som det.

6. Bestäm vem som kan ändra reglerna, och hur snabbt

Eskaleringsreglerna är det ni kommer att justera mest de första månaderna. En tröskel ligger för lågt. En ärendetyp borde ha gått direkt till en människa. En annan borde inte ha gått dit alls.

Kräver varje sådan ändring ett ärende hos leverantören och två veckors väntan blir den inte gjord. Red ut det innan ni går i drift, inte efteråt.

Testa det på tre samtal innan ni öppnar

Inte på det samtal som går som det ska. På de här tre:

En kund som ber om en människa i första meningen, innan agenten hunnit fråga om något.

En kund som ringer om något agenten inte har behörighet att göra, klockan 21 en fredagskväll.

En kund som kopplas över, där förbindelsen bryts precis när människan svarar.

Går de tre bra går det mesta bra.

Eskalering är inte ett feltillstånd

Det är lätt att behandla eskaleringar som något som ska ned. Men en låg eskaleringsandel kan lika gärna betyda att vägen ut är besvärlig som att agenten är bra – och de två ser identiska ut i en månadsrapport. Det är samma problem som med automatiseringsgraden: talet räknar samtal som inte kopplades över, inte ärenden som löstes.

Målet är inte så få eskaleringar som möjligt. Det är att de som sker, sker vid rätt tidpunkt och med tillräcklig kontext för att människan ska kunna göra något åt ärendet. Det är också det bästa svaret på invändningen att kunderna hellre vill tala med en människa.

Threll.ai bygger röstagenter på svenska, norska och danska. Den del kunderna minns är sällan vad agenten svarade. Det är vad som hände när den inte kunde svara.