Succesvolle Chatbot-projecten vermijden deze fouten

Wat is een chatbot? Een chatbot is software die een menselijk gesprek kan voeren met een gebruiker. Een gebruiker kan tegen de chatbot spreken of hem een bericht sturen via een chatprogramma, en hij zal reageren door te spreken, iets te typen of iets grafisch te laten zien. De belangrijkste toepassing voor chatbots op dit moment is klantenservice, waar ze worden gebruikt om eenvoudige, repetitieve vragen te beantwoorden en complexere vragen door te sturen naar menselijke medewerkers.

Hoewel er nog een aantal problemen moeten worden opgelost voordat ze op grote schaal worden gebruikt voor het inschakelen van klanten (afgezien van Amazon Alexa die producten bestelt en een paar andere voorbeelden), wordt de conversatie-interface snel overgenomen voor klantenondersteuningsfuncties.

Vanuit zakelijk oogpunt moet een chatbotproject, net als elk ander project, worden beoordeeld op risico's en opbrengsten.

In dit artikel onderzoeken we de mogelijke uitdagingen bij de implementatie van chatbots en hoe we die kunnen vermijden.

Veel van de risico's die hier worden genoemd, kunnen worden vermeden, omdat veel van de problemen waarmee vroege gebruikers te maken kregen, nu bekend zijn.

Het is onvermijdelijk dat chatbots en voice snel op grote schaal zullen worden gebruikt voor klantenservice, omdat de ROI voor chatbots in veel gevallen meer dan 1.000% is, wat niet alleen te danken is aan kostenbesparingen, maar ook aan de grotere betrokkenheid en tevredenheid van klanten en de daaruit voortvloeiende omzetkansen.

De botplatforms die er zijn, zijn zo volwassen geworden dat dit nu laaghangend fruit is voor bedrijven. Niet alleen zal chatbots op grote schaal worden gebruikt voor klantenondersteuning, maar de use cases zullen zich snel uitbreiden naar customer enablement, dat uiteindelijk klantenondersteuning zal overheersen als de belangrijkste use case.

‍

De hype voorbij

Het is vaak moeilijk om een nieuwe technologie te evalueren omdat je weet dat een deel van de hype rond het product gewoon hype is. Technologiebedrijven doen allerlei gedurfde beloftes over wat er zal gebeuren als je hun technologie implementeert, maar je weet natuurlijk dat het niet zo eenvoudig is, dat niets gegarandeerd is en ze benadrukken zeker niet de nadelen. Hetzelfde geldt voor chatbots.

Chatbots hebben vele stadia van hype doorgemaakt. Veel van deze hype heeft te maken met overschatting van wat chatbots kan doen.

Het is waar dat er de afgelopen jaren een aantal echte doorbraken zijn geweest in chatbot-gerelateerde AI, dat deze doorbraken moeten worden begrepen om een goed beeld te krijgen van wat we kunnen verwachten van chatbots.

De belangrijkste doorbraken zijn te vinden in drie primaire technologieën: natuurlijke taalverwerking (NLP), spraakherkenning op schaal (voor spraakassistenten) en het genereren van natuurlijke taal.

NLP stelt een chatbot in staat om de gemeenschappelijke intentie te identificeren achter verschillende natuurlijke taalzinnen die dezelfde betekenis hebben. Bijvoorbeeld "boek een vlucht" of "ik wil naar Parijs vliegen" hebben dezelfde intentie als "boek een vlucht". Een softwareontwikkelaar kan coderen wat hij moet doen zodra die intentie is geïdentificeerd.

Spraakherkenning maakt gebruik van technologie die gesproken woorden vertaalt naar tekst. Hoewel spraakherkenning al heel lang bestaat, is het alleen dankzij de vooruitgang in de prestaties van computers en de mogelijkheid om werk te delegeren naar cloud dat deze systemen miljoenen woorden kunnen identificeren, aangezien de algoritmen zeer rekenintensief zijn.

Natuurlijke taal generatie neemt een set parameters en genereert een grammaticaal correcte zin in natuurlijke taal.

Al deze technologieën zijn tot op zekere hoogte vooruitgegaan dankzij de vrij recente vooruitgang in rekenkracht.

De extreme hype is dat chatbots binnenkort menselijke agenten volledig zal vervangen. De realiteit is dat chatbots extreem goed presteert binnen een beperkt domein waar de context beperkt is en het beste presteert bij het beantwoorden van eenmalige vragen zonder context.

Dat betekent niet dat de onderliggende technologie niet krachtig en nuttig is. Dat is het wel. Dat betekent niet dat chatbots geen enorme return on investment (ROI) kan genereren. Dat kunnen ze wel.

Het betekent wel dat de chatbotervaring moet worden gemaakt met de beperkingen in het achterhoofd.

‍

Veelgemaakte fouten van een chatbotproject

Verkeerde doelstelling

Er zijn veel manieren waarop het gekozen doel bij het implementeren van een chatbot verkeerd kan zijn. Er kunnen veel problemen zijn bij het bepalen van doelstellingen, zoals het oplossen van een probleem dat niet bestaat, d.w.z. een chatbot gebruiken om iets te doen wat beter gedaan kan worden door een grafische interface.

De grootste fout die je kunt maken is om de hype te geloven en te proberen een mensachtige chatbot te implementeren die bijna op menselijk niveau een gesprek aangaat met klanten. Veel bedrijven hebben dit geprobeerd en zijn er niet in geslaagd. Proberen een chatbot te bouwen buiten de dingen die hij echt goed doet is altijd een probleem.

De beste chatbotervaringen zijn een geleide gesprekservaring, geen open gesprekservaringen. De Botpress software definieert bijvoorbeeld een "happy path", een geleid pad waarop de software de gebruiker moet houden. Als de gebruiker van dit pad afwijkt, zal de software proberen hem terug te brengen naar het gelukkige pad of hem de kans geven een ander pad te kiezen, maar hij zal niet toestaan dat hij een zijweg inslaat.

Slecht ontwerp en ontwikkelingsproblemen

Een slecht ontworpen chatbot zorgt ervoor dat gebruikers hem gebruiken op een manier die niet de bedoeling was. Dit zorgt natuurlijk voor frustratie en heeft allerlei negatieve gevolgen.

Chatbots moeten conservatief worden ontworpen, de scope moet heel duidelijk worden gemaakt en het gesprek moet te vaak worden geëscaleerd naar een mens in plaats van niet vaak genoeg (of er moet een gelijkwaardige strategie worden gebruikt voor de use case in kwestie).

Het spreekt voor zich dat de ontwikkelaars die aan de bot werken competent moeten zijn en bekend met de best practices op dit gebied.

‍

Verkeerde technologische benadering

Chatbots zijn tegenwoordig een mix van NLP en beslisbomen. Met NLP kan de gebruiker open vragen stellen in een zeer beperkt domein en de beslisbomen leiden de gebruiker door een beslisboom (het gelukkige pad) om een probleem op te lossen of een taak te voltooien. Zoals hierboven vermeld met betrekking tot omwegen, is er beperkte ruimte voor de gebruiker om af te wijken van het gelukkige pad.

Het is een vergissing om te kiezen voor een black box-benadering van conversaties. Black box-oplossingen zijn datagedreven oplossingen waarbij de logica in essentie in de AI-algoritmen zit. Het probleem hiermee is dat niemand zeker weet wat de AI-oplossing zal doen, het is extreem moeilijk om te debuggen, het kan niet uitgebreid getest worden en nieuwe informatie kan het gedrag veranderen.

Zelfs Botpress maakt gebruik van een deel van deze technologie, maar beperkt het domein waarin deze "black box" AI kan werken tot het beperkte gebied rond het gelukkige pad. Daarom is het doel van de AI om de gebruiker altijd terug te brengen naar het gelukkige pad of hem de mogelijkheid te geven om over te stappen naar een nieuw pad. Dit is veel gemakkelijker te begrijpen en te debuggen.

Ik moet zeggen dat deze "black box" AI extreem goed werkt in domeinen die begrensd zijn en waar er een enorme hoeveelheid relevante gegevens zijn over de taak die moet worden uitgevoerd. Daarom kan AI zo goed spelletjes spelen. Het probleem met taal is dat het oneindige dimensies heeft omdat elke uitspraak verschillende dingen betekent, afhankelijk van de context, waaronder uitspraken die eerder zijn gedaan en andere relevante informatie waarvan de conversatie-agent op de hoogte moet zijn.

Het implementeren van black box AI voor conversaties met de huidige stand van de technologie is vergelijkbaar met de fout om te proberen een open chatbot te implementeren.

Bovendien is dit soort black box-benadering, ondanks de hierboven genoemde gebreken, extreem gegevensintensief en kost het daarom een fortuin om te implementeren. En het feit dat het een black box is, betekent dat het heel moeilijk is om van leverancier te veranderen, wat extreem hoge overstapkosten en dus lock-in met zich meebrengt.

Het is beter om eenvoudige NLP- en beslisboomtechnologieën te gebruiken om bots te bouwen en vervolgens AI te gebruiken met een beperkte reikwijdte rond de randen om de gebruiker terug te brengen naar het voltooien van de taak. We hebben gemerkt dat bedrijven eigenlijk verrast zijn over hoe toegankelijk en eenvoudig de technologie is om te gebruiken. Een competente ontwikkelaar kan in een paar uur leren hoe hij een bot moet bouwen die NLP en beslisbomen gebruikt.

Het is ook belangrijk om te begrijpen dat gesprekken met chatbots geen kopie moeten zijn van gesprekken met mensen. Grafische interfaces zijn bijvoorbeeld in veel gevallen veel efficiënter te gebruiken dan tekst of spraak. Op keuzeknoppen klikken gaat sneller dan een antwoord typen of uitspreken. Dit zou zelfs waar zijn als het mogelijk was om een chatbot op menselijk niveau te maken. Deze realiteit wordt vaak over het hoofd gezien bij het gebruik van een black box of voornamelijk op woorden gebaseerde AI-aanpak.

‍

Verkeerd platform

De problemen bij het kiezen van het verkeerde bot framework zijn misschien niet direct duidelijk, maar zullen na verloop van tijd duidelijk worden.

De snelste manier om een chatbot te bouwen is door een drag-and-drop platform te gebruiken. Het probleem hiermee is dat ontwikkelaars in de meeste gevallen al snel tegen harde beperkingen aanlopen. Bovendien betekent de generieke aanpak die wordt gebruikt dat wat eenvoudige functies zouden moeten zijn, in het systeem worden gehackt, waardoor het voor beheerders onhandig en moeilijk wordt om de bot te gebruiken.

De andere kant van het spectrum zijn op code gebaseerde propriëtaire platformen die ontwikkelaars toelaten om de bot vanaf nul te coderen. Het probleem met deze aanpak is dat het erg lang duurt om zelfs eenvoudige bots te bouwen.

De beste benadering is een raamwerk dat alle benodigde componenten en visuele interfaces, inclusief de drag-and-drop interfaces, out of the box biedt, maar tegelijkertijd toestaat dat al deze componenten en interfaces eenvoudig kunnen worden aangepast voor de taak die moet worden uitgevoerd.

Dit is vooral belangrijk omdat botsponsors meestal de meeste aandacht besteden aan hoe de bot zal werken voor eindgebruikers. Het probleem hiermee is dat er veel andere componenten en interfaces zijn die belangrijk zijn voor andere gebruikers van de bot zoals de administrators (die chatbot analytics willen monitoren en backend toegang willen beheren), technische en niet-technische creators (die het gedrag en de inhoud van de bot willen aanpassen) en human agents (die reageren op de conversaties die geëscaleerd worden door de bot).

Deze componenten vanaf nul opbouwen is een zeer tijdrovende bezigheid. Eenvoudige drag-and-drop frameworks hebben natuurlijk zeer generieke en beperkte versies van deze functionaliteit en kunnen niet eenvoudig worden aangepast.

De mogelijkheid om aan te passen is essentieel voor de eindgebruikersbot zelf, zelfs als dat niet van tevoren duidelijk is. Bijvoorbeeld, bij het bouwen van flows met behulp van de drag and drop flow builder kunnen er taken zijn die steeds herhaald moeten worden in verschillende flows, zoals het authenticeren van een gebruiker met een bedrijfssysteem of het verwerken van een betaling.

Het framework moet het mogelijk maken om deze componenten als visuele componenten toe te voegen aan de flow builder, zodat minder technische content creators deze functies eenvoudig kunnen toevoegen aan de processen.

Een platform dat niet gemakkelijk kan worden aangepast, zal het moeilijk maken om niet-technische gebruikers manieren te bieden om inhoud bij te werken omdat de methoden om dit te doen in het framework moeten worden "gehackt". Een framework dat het mogelijk maakt om alles aan te passen, zou het makkelijk moeten maken om speciaal ontworpen schermen te maken voor niet-technische gebruikers die makkelijk en intuïtief te gebruiken zijn.

Daarnaast is het ook zeer gunstig voor uw ontwikkelaars om toegang te hebben tot de onderliggende broncode van het systeem. Hierdoor zullen ze sneller begrijpen hoe dingen gedaan moeten worden en zullen ze problemen snel kunnen identificeren als deze zich voordoen.

Iets dat van vitaal belang is voor een framework is de mogelijkheid om je gegevens te controleren en te migreren. Het platform moet bedrijven in staat stellen om de bot overal waar ze maar willen in te zetten, op een eigen cloud of on-prem (op interne servers).

ROI is ook een belangrijke overweging in termen van platform. Het platform moet het mogelijk maken om werk van één bot te hergebruiken voor andere bots, d.w.z. door functionaliteit te bouwen voor één bot wordt het gemakkelijker om de volgende bot te bouwen. Dit maakt het schalen van één bot naar vele bots incrementeel goedkoper, wat het effect heeft dat de algehele ROI verbetert.

Een voorbeeld hiervan is dat slecht ontworpen platforms ervoor zorgen dat je een nieuwe bot aanmaakt voor elke nieuwe taal die je toevoegt, in plaats van dat je gewoon dezelfde content in een andere taal kunt aanbieden. Zelfs het niet scheiden van het flow design en de content maakt het beheren van de content moeilijker en foutgevoeliger omdat niet-technisch personeel de daadwerkelijke flows moet bewerken in plaats van simpelweg de content bij te werken.

Door beheerders en andere backend-gebruikers in staat te stellen hun werk op een efficiënte en eenvoudige manier te doen, besparen ze tijd en worden er minder fouten gemaakt, wat de ROI verbetert.

‍

Verkoper Insluiten

Vendor lock-in is op een aantal manieren een probleem.

Als je gedwongen wordt om hun technologie te gebruiken, d.w.z. het platform staat je niet toe om componenten van derden te gebruiken, dan gok je erop dat al hun componenten voor altijd de beste in hun klasse zullen zijn. Zo niet, dan ben je gedwongen om verouderde technologie te gebruiken terwijl de rest van de markt verder gaat of een zeer kostbare omschakeling ondergaat.

Als er onderdelen ontbreken of als je iets moet veranderen aan de manier waarop het werkt, moet je op hen vertrouwen voor de ontwikkeling op maat, wat niet alleen vertragingen veroorzaakt, maar ook een dure aangelegenheid kan zijn.

Tot slot, als je een gebonden klant bent, kunnen zij de prijs bepalen die erg duur kan zijn. Ze weten dat de volledige overstapkosten erg hoog kunnen zijn, vooral als ze het moeilijk maken om gegevens en code te migreren naar andere platformen.

Het gebruik van een gesloten systeem in plaats van een open systeem maakt lock-in waarschijnlijker en overstapkosten hoger. Daarnaast betekent de keuze voor een complexe benadering van chatbots die alleen kan worden geïmplementeerd door dataspecialisten dat het nog moeilijker wordt om aan lock-in te ontsnappen en dat de kosten van lock-in hoger zijn.

‍

Belanghebbenden niet aan boord krijgen

Dit is een veelgemaakte en voor de hand liggende fout voor elk softwareproject waarbij bestaand gedrag moet worden veranderd en de oplossingen zijn welbekend. Natuurlijk zijn de agenten van de klantendienst bijzonder belangrijk in de botwereld omdat ze zich bedreigd kunnen voelen door deze technologie. Ze moeten worden omgeschoold om een dienstenpakket aan te bieden dat de diensten van de bot aanvult, vooral om diepgaandere diensten aan te bieden aan klanten die complexere behoeften hebben die niet door de bots kunnen worden opgelost.

‍

De ROI negeren

Er zijn twee manieren waarop het negeren van de ROI kan leiden tot mislukking. De eerste is dat zonder een overtuigend ROI-cijfer het project niet gesponsord zal worden, zelfs al was er sponsoring voor een POC om de technologie te bewijzen. De tweede is dat belanghebbenden bij het project zich realiseren dat er geen ROI is als het project eenmaal draait.

Er is geen reden om de verwachte ROI niet vooraf te berekenen [calculating the ROI] en dit getal vervolgens bij te werken naarmate je meer informatie krijgt over de use case en de context. Er zijn veel use cases die een extreem hoge ROI hebben, dus het zou niet moeilijk moeten zijn om use cases te vinden.

‍

De bot niet stapsgewijs bouwen

Natuurlijk kunnen veel van de bovenstaande risico's worden vermeden door de bot stapsgewijs te implementeren.

Het is heel eenvoudig om oplossingen te bouwen die stapsgewijs getest kunnen worden. Begin met een enkele use case POC en routeer een paar eindgebruikers naar de bot om de prestaties te beoordelen. Op deze manier kan de effectiviteit van de oplossing, inclusief de respons van gebruikers, goedkoop getest en verfijnd worden bij elke stap.

Natuurlijk is het belangrijk om bij het selecteren van een use case voor deze oefening de use cases te selecteren die de meest "risicovolle" aannames uitdagen, zodat de meest onzekere en kritische aannames vooraf worden getest.

Veel leveranciers willen u graag overhalen om mee te doen aan een big bang-aanpak waarbij veel werk en moeite vooraf gaan voordat een werkende bot, zelfs een POC, wordt gepresenteerd aan gebruikers. Niet alleen dat, maar de leveranciers staan erop dat alleen dure consultants in staat zijn om de bot voor u te beheren en te monitoren. Dit zou een grote rode vlag moeten zijn.

‍

Conclusie

Er zijn veel overwegingen waar je rekening mee moet houden bij het bouwen van een chatbot. Zolang je je bewust bent van de belangrijkste risico's en de implementatie stapsgewijs aanpakt, heb je een grote kans om een succesvolle chatbot te bouwen en de fenomenale ROI's te behalen die daarbij horen.

‍