Slik designer du eskaleringen fra stemmeagent til menneske

1. Bestem hva som skal utløse en eskalering

Det er tre kategorier, og de bør settes opp hver for seg.

Kunden ber om det. Den enkleste og den viktigste. Den bør virke på første forsøk, uansett hvordan kunden formulerer seg, og uten at agenten først prøver å løse saken en gang til.

Agenten har ikke lov til å gjøre det som må gjøres. Ikke «forstår ikke», men «har ikke tilgang»: kreditering over et visst beløp, endring av en sak som er under behandling, alt som krever en fullmakt agenten ikke har. Disse er kjent på forhånd og lar seg liste opp.

Signaler i samtalen. Tredje kontakt om samme sak på kort tid. Andre forsøk på samme steg. Ord som klage, advokat, avslutte abonnementet. I helsetjenesten er kategorien enda mer konkret: en akuttsamtale til en tannklinikk skal ha tre utfall, og ingen av dem er en bookingdialog.

Legg merke til at alle tre er hendelser og formuleringer, ikke tolkninger av humør. Det er en viktig forskjell nå som systemer som utleder følelser fra stemmen er høyrisikosystemer. Du trenger dem heller ikke: en kunde som ringer for tredje gang er et sterkere signal enn en tonefallsscore, og et du kan forklare i ettertid.

2. Bestem hva som skjer når det ikke er noen der

Dette er punktet som oftest mangler, og det som oftest skaper klagen.

Utenfor åpningstiden, i kø, eller når ingen er logget på – hva skjer da? Det forutsetter at agenten i det hele tatt vet at dere har stengt, men anta for et øyeblikk at den gjør det. Det verste svaret er en overføring til en telefon som ringer uten at noen tar den. Kunden har da brukt tre minutter på å komme fram til et menneske som ikke finnes. I enkelte bransjer er ikke det et servicespørsmål, men et skadespørsmål – i boligforvaltning kan samtalen klokka halv tre om natta være en kjeller som fylles med vann.

Brukbare alternativer finnes: tilbakeringing på et tidspunkt kunden velger, en beskjed med saksnummer og et lovet tidsrom, eller at agenten gjør ferdig det den kan og sier tydelig hva som gjenstår. Velg ett av dem, og sørg for at agenten vet hvilket som gjelder akkurat nå. Ligger telefonien i Teams, er endepunktet allerede valgt i en nedtrekksmeny – og det er nettopp derfor det er så lett å hoppe over hvem som faktisk tar samtalen.

3. Bestem hva agenten sier i det den gir fra seg samtalen

Én setning, og den bør inneholde tre ting: at det skjer, hvem det går til, og hvor lang tid det tar.

«Jeg setter deg over til en kollega på kundeservice, det tar under et minutt» er nok. «Vent litt» er det ikke. Og ikke lov en ventetid systemet ikke kan holde: en agent som sier under et minutt og bruker sju, er verre enn en som ikke sa noe.

Dette henger sammen med åpningen. En agent som opplyser at den er KI og samtidig tilbyr veien ut allerede i åpningsreplikken, gjør opplysningen ufarlig. Uten veien ut er åpenheten bare en advarsel.

4. Bestem hva mennesket får med seg

Her avgjøres det om eskaleringen føltes som hjelp.

En kunde som må gjenta hele historien til mennesket, konkluderer med at agenten var bortkastet tid – uansett hvor godt den fungerte de første to minuttene. Det er den vanligste enkeltårsaken til at et ellers velfungerende oppsett får dårlig omtale internt, og det er langt fra et særtilfelle: nesten halvparten av selskapene sender ingenting videre fra agenten til mennesket som overtar.

Minimum som bør ligge klart før mennesket svarer: hvem som ringer, hva saken gjelder med kundens egne ord, hva agenten allerede har gjort eller slått opp, og hvorfor den satte over. Fire linjer. Er de ikke der, er ikke eskaleringen bygget ferdig.

5. Bestem hvem som eier saken hvis samtalen faller

Overføringer brytes. Kunder legger på i kø. Forbindelser faller ut.

Spørsmålet er hva som skjer da: ligger det igjen en sak noen faktisk ser, eller forsvinner henvendelsen? Er svaret det siste, lekker eskaleringsveien – og lekkasjen er usynlig, fordi samtalen teknisk sett ble besvart og telles som det.

6. Bestem hvem som kan endre reglene, og hvor fort

Eskaleringsreglene er det du kommer til å justere mest de første månedene. En terskel står for lavt. En sakstype burde gått rett til et menneske. En annen burde ikke gått dit i det hele tatt.

Krever hver slik endring en sak hos leverandøren og to ukers ventetid, blir den ikke gjort. Avklar det før dere setter i drift, ikke etter.

Prøv det på tre samtaler før dere åpner

Ikke på samtalen som går som den skal. På disse tre:

En kunde som ber om et menneske i første setning, før agenten har rukket å spørre om noe.

En kunde som ringer om noe agenten ikke har tilgang til å gjøre, klokken 21 på en fredag.

En kunde som blir satt over, der forbindelsen brytes i det mennesket svarer.

Går de tre bra, går det meste bra.

Eskalering er ikke en feiltilstand

Det er lett å behandle eskaleringer som noe som skal ned. Men en lav eskaleringsandel kan like gjerne bety at veien ut er tungvint som at agenten er god, og de to ser identiske ut i en månedsrapport. Det er det samme problemet som med automatiseringsgraden: tallet teller samtaler som ikke ble satt over, ikke saker som ble løst.

Målet er ikke færrest mulig eskaleringer. Det er at de som skjer, skjer på riktig tidspunkt og med nok kontekst til at mennesket kan gjøre noe med saken. Det er også det beste svaret på innvendingen om at kundene heller vil snakke med et menneske.

Threll.ai bygger stemmeagenter på norsk, svensk og dansk. Den delen kundene husker, er sjelden det agenten svarte. Det er hva som skjedde da den ikke kunne svare.