De ce majoritatea chatbot-urilor corporative dezamăgesc - și ce să construiești în schimb
Majoritatea chatbot-urilor interne eșuează deoarece răspund la întrebări în loc să finalizeze sarcini. Iată ce ar trebui să construiți în locul lor.
O companie cumpără un chatbot
O companie achiziționează un chatbot care este integrat pe site-ul web sau în portalul intern de asistență. Pentru două săptămâni, oamenii îl testează. Până la sfârșitul lunii a treia, utilizarea acestuia se reduce la o mână de angajați curioși și clienți ocazionali care nu găsesc numărul de telefon.
Acest lucru se întâmplă destul de des încât merită să identificăm cauza. Nu este vorba despre model; modelele disponibile în prezent sunt mult mai bune decât cele implementate pe baza acestora. Eșecul constă în forma pe care o are chatbot-ul.
Un chatbot răspunde, o afacere închide
Dacă întrebi un chatbot pentru ce este, de obicei vei primi răspunsuri precum: "răspunde la întrebări despre produsele noastre" sau "ajută angajații să găsească politici." Sună util, dar nu este.
Niciun loc de muncă nu implică primirea unui răspuns. Cineva are sarcina de a emite o rambursare, de a aproba o comandă, de a reprograma o instalare, de a confirma o cerere de garanție sau de a obține un contract pentru servicii juridice. Un răspuns este doar mijlocul acestui proces. Un sistem care se oprește la răspunsul dat retrage sarcina de la persoana care încerca să o transmită mai departe.
Așadar, interacțiunea decurge astfel: clientul întreabă despre o comandă întârziată, chatbot-ul explică politica de transport, iar clientul cere un om - pentru că politica nu a fost niciodată scopul. Chatbot-ul a făcut ceea ce a fost construit să facă și totuși a eșuat.
Cele trei moduri în care acestea se rup
Cele mai dezamăgitoare implementări împărtășesc câteva trăsături:
- Fără acces la sisteme live. Chatbot-ul a fost antrenat pe documente. Întrebarea clientului se referă la comanda lor, factura lor, contul lor. Un chatbot care nu are acces la sistemul de comenzi poate vorbi doar în generalități, iar acestea sunt ceea ce pagina de întrebări frecvente (FAQ) a făcut deja.
- Fără abilitatea de a acționa. Chiar și atunci când știe răspunsul, nu poate face acțiunea. Fiecare conversație se încheie cu o transmitere mai departe, adăugând astfel un pas în loc să elimine unul.
- Fără o definiție a finalizării. Nimeni nu a convenit în avans ce reprezintă un rezultat bun, așa că nimeni nu poate spune dacă funcționează sau nu. Numerele de utilizare cresc, volumul centrului de contact nu scade și discuțiile despre proiect încetează pur și simplu.
În spatele tuturor acestor trei se află o decizie: proiectul a fost definit ca un canal - un nou loc pentru a vorbi cu compania - în loc de capacitate, o modalitate de a finaliza mai mult muncă cu aceleași persoane.
Construiți un completator de sarcini
Alternativa nu este mai sofisticată; este mai restrânsă și mai profundă.
Alegeți o sarcină cu volum mare. Nu un subiect, ci o sarcină - "reschedarea unei livrări", nu "întrebări logistice". Ceva care se întâmplă de sute de ori pe lună și urmează o cale cunoscută.
Oferiți sistemului cele două lucruri de care are nevoie pentru a finaliza efectiv acea sarcină: acces citire la sistemele care dețin adevărul și acces scriere la una sau două acțiuni necesare sarcinii. Dacă poate verifica livrarea, oferi sloturi reale și schimba programarea, a înlocuit un apel telefonic. Dacă poate doar descrie politica de reschedulare, nu a realizat nimic.
Apoi decideți ce face atunci când nu poate finaliza. Această parte este omisă de cele mai multe proiecte, dar face mai mult pentru încredere decât orice cantitate de ajustare a modelului. Definiți condițiile în care se oprește și transmite către un om - o încredere scăzută, o stare neobișnuită a contului, orice implică bani peste un prag - și asigurați-vă că transmiterea include întregul context pentru ca clientul să nu fie nevoit să se repete. Un sistem care finalizează curat 60% din cazuri și escaladează restul cu un rezumat coerent bate unul care încearcă 100% și greșește o cincime din ele.
În cele din urmă, stabiliți un număr înainte de a construi. Ce procentaj de solicitări de reschedulare sunt finalizate fără intervenția unui om? Care este timpul mediu de gestionare pe cele care escaladează? Care este rata de contact repetat în 48 de ore? Unu sau două numere, măsurate față de luna precedentă lansării. Dacă acestea nu se îmbunătățesc, ați învățat ceva ieftin și devreme.
Ce schimbă acest lucru despre plan
Definirea proiectului în acest fel îl face mai mic și integrarea mai mare, ceea ce este inconfortabil pentru oricine a cumpărat un chatbot așteptând o configurare de două săptămâni. Nivelul conversației este acum partea ușoară. Munca reală se află în permisiuni, acces la sisteme, urmărirea auditului și calea de escaladare - plumbul neîngrijit care decide dacă acest lucru poate suporta orice greutate.
Aceasta este și motivul pentru care restrâns învinge largul. Un sarcină finalizată complet câștigă dreptul de a adăuga a doua. Un sistem care acoperă patruzeci de subiecte superficial nu merită nimic, deoarece nu există o singură sarcină pe care cineva o poate identifica și spune: "aceasta folosea să ne ia patru minute, iar acum nu mai durează deloc."
Noi construim al doilea tip. Primul tip este mai ușor de lansat, dar mult mai greu de menținut.