Derfor skuffer de fleste bedriftschatbotene — og hva du bør bygge i stedet

En bedrift kjøper en chatbot. Den legges ut på nettsiden, eller inn i den interne hjelpeportalen. I to uker prøver folk den. Innen tredje måned har bruken falt til en håndfull nysgjerrige ansatte og den sjeldne kunden som ikke finner telefonnummeret.

Dette skjer ofte nok til at det er verdt å sette navn på årsaken. Det er ikke modellen. Modellene som finnes i dag er langt bedre enn løsningene som bygges på dem. Feilen ligger i formen på tingen.

En chatbot svarer; en virksomhet fullfører

Spør du hva chatboten er til for, får du gjerne: «den svarer på spørsmål om produktene våre» eller «den hjelper ansatte med å finne retningslinjer». Det høres nyttig ut. Men det er det ikke helt.

Ingen har som jobb å motta et svar. Noen har som jobb å utbetale en refusjon, godkjenne en innkjøpsordre, flytte en installasjon, bekrefte et garantikrav eller sende en kontrakt til juridisk. Et svar er midtpartiet av den oppgaven. Et system som stopper ved svaret, gir arbeidet tilbake til personen som prøvde å bli kvitt det.

Så samtalen går slik: kunden spør om den forsinkede bestillingen sin, boten forklarer fraktvilkårene, og kunden ber om et menneske — fordi vilkårene aldri var poenget. Boten gjorde det den var bygget for, og mislyktes likevel.

De tre måtene de bryter sammen på

De fleste skuffende løsningene deler noen få trekk.

• Ingen tilgang til levende systemer. Boten ble trent på dokumenter. Kundens spørsmål handler om sin bestilling, sin faktura, sin konto. En bot uten innsyn i ordresystemet kan bare snakke i generelle vendinger, og generelle vendinger var akkurat det FAQ-siden allerede leverte.
• Ingen evne til å handle. Selv når den vet svaret, kan den ikke gjøre tingen. Hver samtale ender i en overlevering, så den legger til et steg i stedet for å fjerne ett.
• Ingen definisjon av «ferdig». Ingen ble på forhånd enige om hvordan et godt utfall ser ut, så ingen kan si om det virker. Bruksstatistikken går opp, volumet i kundesenteret går ikke ned, og prosjektet slutter stille å bli nevnt.

Under alle tre ligger én beslutning: prosjektet ble definert som en kanal — et nytt sted å snakke med bedriften — i stedet for som kapasitet, en måte å fullføre mer arbeid med de samme folkene.

Bygg noe som fullfører oppgaver i stedet

Alternativet er ikke mer avansert. Det er smalere og dypere.

Velg én oppgave med høyt volum. Ikke et tema, en oppgave — «flytte en levering», ikke «logistikkspørsmål». Noe som skjer hundrevis av ganger i måneden og følger en kjennbar sti.

Gi systemet de to tingene det trenger for faktisk å fullføre oppgaven: lesetilgang til systemene som holder sannheten, og skrivetilgang til de én eller to handlingene oppgaven krever. Hvis den kan slå opp leveringen, tilby reelle tidspunkter og endre bestillingen, har den erstattet en telefonsamtale. Hvis den bare kan beskrive reglene for omberamming, har den ikke erstattet noe.

Bestem så hva den gjør når den ikke får fullført. Dette er delen de fleste prosjekter hopper over, og den gjør mer for tilliten enn all verdens modelljustering. Definer betingelsene for når den stopper og sender saken videre til et menneske — lav sikkerhet, en uvanlig kontotilstand, alt som involverer beløp over en grense — og sørg for at overleveringen bærer med seg hele konteksten, slik at kunden slipper å gjenta seg selv. Et system som fullfører 60 % av sakene rent og eskalerer resten med et ryddig sammendrag, slår ett som forsøker seg på 100 % og tar feil på en femtedel.

Til slutt: bli enige om tallet før dere bygger. Andel forespørsler om ny leveringstid som fullføres uten et menneske. Gjennomsnittlig behandlingstid på dem som eskaleres. Andel som tar kontakt på nytt innen 48 timer. Ett eller to tall, målt mot måneden før lansering. Beveger de seg ikke, har dere lært noe billig og tidlig.

Hva dette endrer ved planen

Å avgrense på denne måten gjør prosjektet mindre og integrasjonsarbeidet større, noe som er ubehagelig for enhver som kjøpte en chatbot og ventet seg en to ukers konfigurasjonsøvelse. Samtalelaget er den enkle delen nå. Arbeidet ligger i rettigheter, systemtilgang, sporbarhet og eskaleringsveien — det uglamorøse rørleggerarbeidet som avgjør om tingen kan bære noen vekt i det hele tatt.

Det er også derfor smalt slår bredt. Én oppgave gjort fullstendig gir retten til å legge til den andre. Et system som dekker førti temaer overflatisk, gir ingenting, for det finnes ingen enkelt jobb noen kan peke på og si: dette pleide å ta oss fire minutter, og nå gjør det ikke det.

Vi bygger den andre typen. Den første er lettere å lansere og mye vanskeligere å beholde.