Derfor skuffer de fleste virksomhedschatbots — og hvad du bør bygge i stedet

En virksomhed køber en chatbot. Den kommer på hjemmesiden eller ind i den interne supportportal. I to uger prøver folk den. I tredje måned er brugen faldet til en håndfuld nysgerrige medarbejdere og en enkelt kunde i ny og næ, som ikke kan finde telefonnummeret.

Det sker ofte nok til, at årsagen er værd at sætte ord på. Det er ikke modellen. De modeller, der findes i dag, er langt bedre end de løsninger, der bygges på dem. Fejlen ligger i selve løsningens form.

En chatbot svarer; en virksomhed lukker sagen

Spørger man, hvad chatbotten er til for, får man som regel: "den svarer på spørgsmål om vores produkter" eller "den hjælper medarbejdere med at finde politikker". Det lyder nyttigt. Det er det ikke helt.

Ingens job går ud på at modtage et svar. Nogens job går ud på at udstede en refusion, godkende en indkøbsordre, flytte en installation, bekræfte et garantikrav eller få en kontrakt videre til juridisk afdeling. Et svar er midten af den opgave. Et system, der stopper ved svaret, giver arbejdet tilbage til den person, der forsøgte at lægge det fra sig.

Så forløbet bliver: kunden spørger til sin forsinkede ordre, botten forklarer leveringspolitikken, og kunden beder om at tale med et menneske — for politikken var aldrig pointen. Botten gjorde præcis det, den var bygget til, og fejlede alligevel.

De tre måder, de går galt på

De fleste skuffende løsninger deler nogle få træk.

• Ingen adgang til de levende systemer. Botten er trænet på dokumenter. Kundens spørgsmål handler om deres ordre, deres faktura, deres konto. En bot uden indblik i ordresystemet kan kun tale i generelle vendinger, og generelle vendinger fik man allerede på FAQ-siden.
• Ingen mulighed for at handle. Selv når den kender svaret, kan den ikke udføre handlingen. Hver samtale ender med en overdragelse, så den tilføjer et trin i stedet for at fjerne et.
• Ingen definition af "færdig". Ingen blev på forhånd enige om, hvordan et godt udfald ser ud, så ingen kan sige, om det virker. Brugstallene stiger, mængden af henvendelser i kundeservice falder ikke, og projektet holder stille og roligt op med at blive nævnt.

Under alle tre ligger én beslutning: projektet blev afgrænset som en kanal — et nyt sted at tale med virksomheden — i stedet for som kapacitet, altså en måde at få mere arbejde færdigt med de samme mennesker.

Byg i stedet noget, der gør opgaven færdig

Alternativet er ikke mere avanceret. Det er smallere og dybere.

Vælg én opgave med stort volumen. Ikke et emne, men en opgave — "flyt en levering", ikke "spørgsmål om logistik". Noget, der sker hundredvis af gange om måneden og følger et forløb, man kan kortlægge.

Giv systemet de to ting, det har brug for for rent faktisk at gøre opgaven færdig: læseadgang til de systemer, der rummer sandheden, og skriveadgang til de en eller to handlinger, opgaven kræver. Hvis den kan slå leveringen op, tilbyde reelle tider og ændre bookingen, har den erstattet et telefonopkald. Hvis den kun kan beskrive reglerne for ombooking, har den ikke erstattet noget.

Beslut derefter, hvad den gør, når den ikke kan gøre opgaven færdig. Det er den del, de fleste projekter springer over, og den gør mere for tilliden end nogen mængde modeljustering. Definér de betingelser, hvor den standser og giver videre til et menneske — lav sikkerhed, en usædvanlig kontostatus, alt der involverer beløb over en grænse — og sørg for, at overdragelsen bærer hele konteksten med sig, så kunden ikke skal gentage sig selv. Et system, der afslutter 60 % af sagerne rent og eskalerer resten med et ordentligt resumé, slår et, der forsøger sig med 100 % og tager fejl i en femtedel af dem.

Bliv til sidst enige om tallet, før I bygger. Andel af ombookinger gennemført uden et menneske. Gennemsnitlig behandlingstid på dem, der eskaleres. Andel af gentagne henvendelser inden for 48 timer. Ét eller to tal, målt mod måneden før lanceringen. Hvis de ikke rykker sig, har I lært noget billigt og tidligt.

Hvad det ændrer ved planen

Denne afgrænsning gør projektet mindre og integrationsarbejdet større, hvilket er ubekvemt for enhver, der købte en chatbot i forventning om en to ugers konfigurationsøvelse. Samtalelaget er den nemme del nu. Arbejdet ligger i rettigheder, systemadgang, revisionsspor og eskaleringsvejen — det ucharmerende rørarbejde, der afgør, om løsningen kan bære nogen vægt.

Det er også derfor, smalt slår bredt. Én opgave, der er løst helt igennem, giver retten til at tilføje den næste. Et system, der dækker fyrre emner overfladisk, giver ingen ting, for der er ikke ét stykke arbejde, nogen kan pege på og sige: det plejede at tage os fire minutter, og det gør det ikke længere.

Vi bygger den anden slags. Den første er lettere at lancere og langt sværere at beholde.