Varför de flesta företagschattbottar gör besvikelse — och vad du bör bygga i stället

Ett företag köper en chattbot. Den läggs upp på webbplatsen, eller in i den interna supportportalen. I två veckor provar folk den. Vid tredje månaden har användningen kollapsat till en handfull nyfikna medarbetare och den enstaka kund som inte hittar telefonnumret.

Det här händer tillräckligt ofta för att orsaken ska vara värd att sätta ord på. Det är inte modellen. De modeller som finns i dag är långt bättre än de lösningar som byggs på dem. Felet ligger i sakens form.

En chattbot svarar; ett företag avslutar

Frågar man vad chattbotten är till för får man oftast: "den svarar på frågor om våra produkter" eller "den hjälper medarbetare att hitta riktlinjer." Det låter användbart. Men det är det inte, riktigt.

Ingen har som jobb att ta emot ett svar. Någon har som jobb att göra en återbetalning, godkänna en inköpsorder, boka om en installation, bekräfta ett garantiärende eller få ett avtal till juridik. Ett svar är mitten av den uppgiften. Ett system som stannar vid svaret lämnar tillbaka arbetet till den person som försökte lämna ifrån sig det.

Så samtalet går till så här: kunden frågar om sin försenade order, botten förklarar leveransvillkoren, och kunden ber om en människa — för villkoren var aldrig poängen. Botten gjorde det den byggdes för att göra och misslyckades ändå.

De tre sätten de går sönder på

De flesta nedslående lösningar delar några drag.

• Ingen åtkomst till levande system. Botten tränades på dokument. Kundens fråga handlar om deras order, deras faktura, deras konto. En bot utan insyn i ordersystemet kan bara tala i allmänna ordalag, och allmänna ordalag var precis vad FAQ-sidan redan gav.
• Ingen förmåga att agera. Även när den vet svaret kan den inte utföra saken. Varje samtal slutar med en överlämning, så den lägger till ett steg i stället för att ta bort ett.
• Ingen definition av "klart". Ingen kom i förväg överens om hur ett bra utfall ser ut, så ingen kan säga om det fungerar. Användningssiffrorna går upp, volymen i kundtjänst går inte ner, och projektet slutar tyst att diskuteras.

Under alla tre ligger ett enda beslut: projektet definierades som en kanal — en ny plats att prata med företaget på — i stället för som kapacitet, ett sätt att slutföra mer arbete med samma personer.

Bygg något som slutför uppgifter i stället

Alternativet är inte mer sofistikerat. Det är smalare och djupare.

Välj en uppgift med hög volym. Inte ett ämne, en uppgift — "boka om en leverans", inte "logistikfrågor". Något som händer hundratals gånger i månaden och följer en känd väg.

Ge systemet de två saker det behöver för att faktiskt slutföra den uppgiften: läsåtkomst till systemen som håller sanningen, och skrivåtkomst till den eller de handlingar uppgiften kräver. Om den kan slå upp leveransen, erbjuda verkliga tider och ändra bokningen har den ersatt ett telefonsamtal. Om den bara kan beskriva ombokningsvillkoren har den inte ersatt någonting.

Bestäm sedan vad den gör när den inte kan slutföra. Det här är delen de flesta projekt hoppar över, och den gör mer för förtroendet än hur mycket modelltrimning som helst. Definiera under vilka förhållanden den stannar och lämnar över till en människa — låg säkerhet, ett ovanligt kontotillstånd, allt som rör pengar över ett tröskelvärde — och se till att överlämningen bär med sig hela sammanhanget så att kunden inte behöver upprepa sig. Ett system som slutför 60 % av ärendena rent och eskalerar resten med en prydlig sammanfattning slår ett som försöker med 100 % och får en femtedel fel.

Kom till sist överens om siffran innan ni bygger. Andel ombokningsförfrågningar som slutförs utan människa. Genomsnittlig handläggningstid för dem som eskaleras. Andel återkommande kontakter inom 48 timmar. En eller två siffror, mätta mot månaden före lansering. Om de inte rör sig har ni lärt er något billigt och tidigt.

Vad detta ändrar i planen

Att avgränsa på det här sättet gör projektet mindre och integrationsarbetet större, vilket är obekvämt för den som köpte en chattbot och väntade sig två veckors konfigurationsövning. Samtalslagret är den enkla delen nu. Arbetet ligger i behörigheter, systemåtkomst, spårbarhet och eskaleringsvägen — det oglamorösa rörmokeriet som avgör om saken kan bära någon vikt.

Det är också därför smalt slår brett. En uppgift som görs fullt ut förtjänar rätten att lägga till den andra. Ett system som täcker fyrtio ämnen ytligt förtjänar ingenting, eftersom det inte finns ett enda arbetsmoment någon kan peka på och säga: det där tog oss fyra minuter förut, och nu gör det inte det.

Vi bygger den andra sorten. Den första sorten är lättare att lansera och mycket svårare att behålla.