Wat ik wou dat ik vanaf het begin had geweten over ontwikkelen Chatbots

Erik runt een chatbot-ontwikkelingsbureau. Ze leveren chatbot-oplossingen aan grote bedrijven, met name op het gebied van klantenservice en marketing.

Erik vertelde me dat de zaken aan de ene kant erg goed gaan omdat de conversieratio op pitches voor chatbots extreem hoog is. Dit weerspiegelt misschien het feit dat hij een van de eersten is die in deze ruimte op de markt komt.

Tegelijkertijd worstelde hij met het vinden van de juiste tools om efficiënt kwaliteit chatbots te bouwen.

Toen hij voor het eerst de no-code platforms zoals Chatfuel en Motion.ai ontdekte, was hij optimistisch dat deze tools zijn probleem zouden oplossen. Hoewel hij merkte dat ze goed werkten voor het maken van prototypes van de bots, stuitte hij al snel op problemen.

Veel bots moesten worden aangepast op manieren die alleen in code konden worden weergegeven, en deze platforms ondersteunden geen codering. Sommige bots moesten worden geïntegreerd met de bestaande systemen van zijn klant en ook dit was niet mogelijk.

Deze problemen alleen al waren dealbreakers, maar zelfs als ze konden worden opgelost, voelde hij zich nog steeds niet op zijn gemak met alle logica en gegevens die zich op een systeem van een derde partij bevonden waar hij geen controle over had. Zijn klanten stonden er om veiligheidsredenen vaak op om de bot zelf te hosten.

Daarom besloot hij om de bots vanaf nul te laten coderen met behulp van Microsoft Bot Framework en waar mogelijk ontwikkelaars in lagelonenlanden te gebruiken. Door deze voorspelbaarheid ontstonden er andere problemen.

Hoewel hij nu eigenaar was van de code en gegevens en de bot naar wens kon aanpassen, waren de resultaten gemengd.

Hij realiseerde zich al snel dat alle bots veel functies gemeen hadden, zoals rolgebaseerde beveiliging, abonnementen, broadcasting, human in the loop, maar deze functies werden vanaf nul gecodeerd door de ontwikkelaars, wat de ontwikkelingstijd onnodig verlengde en ten koste ging van zijn winstmarges.

De ontwikkelingsrisico's waren ook onnodig hoog omdat verschillende ontwikkelaars de functies op verschillende manieren codeerden en de algehele architectuur zich op een ad hoc manier ontwikkelde. Sommige ontwikkelaars hadden dit probleem onderkend en waren begonnen met het maken van herbruikbare bibliotheken voor veelgebruikte functies, maar deze bibliotheken waren nauwelijks van de hoge kwaliteit waarop hij zijn bedrijf zou willen bouwen. Ze brachten hun eigen risico's en ongewenste afhankelijkheden met zich mee, vooral wanneer de benodigde functionaliteit complex was. Het was moeilijk voor hem om de kwaliteit te controleren, laat staan zijn klanten het vertrouwen te geven dat alles wat gebouwd werd van voldoende hoge kwaliteit was.

Hij overwoog kort om zijn eigen platform te bouwen, maar dat leek hem een overkill. Dit zou onnodige ontwikkelings- en onderhoudskosten met zich meebrengen en mogelijk ook verkoopproblemen als er standaardframeworks op de markt zouden komen waaraan klanten de voorkeur zouden geven, wat volgens hem wel zou gebeuren. Het was gewoon een kwestie van tijd.

In zijn gedachten was het probleem vergelijkbaar met het probleem waar webontwikkelaars mee te maken hadden aan het begin van het internet. In die tijd waren er geen content management tools zoals Wordpress, dus de websites moesten elke keer opnieuw worden gecodeerd. Dit zorgde voor dezelfde problemen van hogere ontwikkelingskosten en variabele kwaliteit in code en output als waar hij nu mee te maken had bij het maken van bots.

Toen Erik online Botpress.io vond, besefte hij al snel dat Botpress een potentiële oplossing was voor zijn problemen. Hij hield van de modulaire architectuur in theorie en het leek hem logisch om een equivalent van een CMS voor bots te bouwen. Het was wat hij nodig achtte. Het zou het ontbrekende stukje in de puzzel kunnen zijn, maar hij had eerst een aantal vragen beantwoord nodig.

Allereerst moest hij er zeker van zijn dat de oplossing robuust, veilig en betrouwbaar was.

Ten tweede moest hij ervoor zorgen dat alle gemeenschappelijke kritieke functies waarvan hij had vastgesteld dat ze nodig waren, beschikbaar waren via het framework.

Ten derde moest hij er zeker van zijn dat de economie zou werken voor zijn agentschap.

Omdat hij zelf een praktisch en technisch persoon is, besloot hij de eerste twee vragen persoonlijk te valideren door het systeem daadwerkelijk te testen. Hij sloot zich aan bij de Botpress community en doorliep enkele van de video tutorials met de open source versie.

Het feit dat er al een grote en actieve gemeenschap van ontwikkelaars was die de software gebruikten, betekende dat het al door de strijd was getest, wat een goede zaak was.

Hij was aanvankelijk bezorgd dat Botpress open source was, wat zijn klanten (in veel gevallen terecht) als een beveiligingsrisico zouden kunnen zien. Hij ontdekte echter dat Botpress een aangepaste bedrijfsversie had die apart van de open source versie werd onderhouden, specifiek om de beveiligingsproblemen aan te pakken.

Natuurlijk bood de open source versie een aantal voordelen, omdat deze gratis te gebruiken was en in veel gevallen ideaal voor het ontwikkelen van bots buiten de enterprise use case. Het betekende dat de componenten en aanpak intensief werden gebruikt en gevalideerd door veel verschillende ontwikkelaars.

Veel van zijn klanten eisten dat ze de chatbot on-premises zouden hosten en dat ze de gegevens zouden beheren om veiligheids- en commerciële redenen en Botpress ondersteunde dit. Bovendien maakte Botpress volledige aanpassing van de code en integratie met interne systemen mogelijk, wat het oorspronkelijke probleem was dat hij had met de "no-code" platforms.

De meeste functies die hij wilde, waren beschikbaar. Deze omvatten rolgebaseerde beveiliging, multi-user beheer en gebruikersinterfaces voor het beheren van de bots na de implementatie. Wat nog ontbrak, kon hij gemakkelijk als module toevoegen.

De modulaire architectuur en de grafische interfaces van het systeem maakten het zelfs heel gemakkelijk om te begrijpen waar alles in paste. Dit betekende dat zelfs als hij halverwege een project overschakelde op nieuwe ontwikkelaars of als iemand na een lange pauze de code moest oppakken, het niet lang zou duren voordat de betreffende persoon op snelheid zou zijn. Tot zover ging het goed.

De economische vraag was natuurlijk ook belangrijk. Zou het gebruik van Botpress zijn totale ontwikkelingskosten verlagen? De winstmarges waren krap. Zijn verwachting was dat het gebruik van een framework als Botpress de ontwikkelingskosten zou verlagen en tegelijkertijd de kwaliteit en functies zou verhogen.

Het bleek dat zijn verwachtingen juist waren. De kosten van Botpress waren een fractie van de kosten om zelf een aantal functies te bouwen en de kwaliteit was beter dan een propriëtaire oplossing.

Het verborgen voordeel van de framework-aanpak was dat hij meer tijd kon besteden aan de UI en functionaliteit van de chatbot en zo de uiteindelijke klantervaring aanzienlijk kon verbeteren.

Hij had gemerkt dat veel van de chatbots op de markt niet zo goed waren. Je zou zelfs kunnen zeggen dat de chatbot-makers als industrie hun klanten in de steek lieten.

Men zou kunnen aanvoeren dat dit komt doordat bedrijven niet bereid waren om redelijk veel geld uit te trekken voor de ontwikkeling van chatbots omdat ze niet zeker waren van de resultaten.

Een ander argument is dat het ontwikkelingsproces voor chatbots tot nu toe erg inefficiënt is geweest, omdat chatbotmakers geen efficiënte tools hadden om chatbots te ontwikkelen en veel van de ontwikkelingskosten daarom gericht waren op wat in wezen infrastructuur is.

De opkomst van frameworks zoals Botpress had het potentieel om de kwaliteit van chatbots enorm te verbeteren, omdat er meer ontwikkelingsbudget wordt besteed aan gebruikerservaring.

Voor de goede orde: Erik is geen echt persoon, maar een samenstelling van een aantal eigenaren van agentschappen die contact met ons hebben opgenomen met hun problemen, eisen en interesse in wat chatbots kan doen. Op verschillende manieren deelden ze hun versie van "Wat ik wilde dat ik in het begin wist over het ontwikkelen van chatbots voor mijn klanten".

Als we de belangrijkste kwesties zouden kunnen samenvatten, zouden ze dat zijn:

• Voor het bouwen van geweldige chatbots is toegang tot de code en gegevens nodig.
• Ontwikkelaars moeten de bedrijfslogica aanpassen en integreren met interne systemen. Het is niet mogelijk om geweldige chatbots te maken zonder ontwikkelaars.
• Veel zakelijke klanten hebben zorgen over de beveiliging en willen daarom hun chatbot op locatie laten draaien. Ze willen ook dezelfde rolgebaseerde beveiliging en gebruikersbeheer die ze verwachten van elke software die ze gebruiken.
• Het raamwerk dat een agentschap kiest, moet een breed scala aan gemeenschappelijke functies out of the box bieden.
• Het heeft geen zin voor een agentschap (of ontwikkelingswinkel) om hun eigen chatbot framework te bouwen voor intern gebruik, net zo min als het zin heeft voor hen om hun eigen databases vanaf nul te bouwen. Dat zou niet alleen oneconomisch zijn en hoge onderhoudskosten met zich meebrengen, maar hun klanten zouden waarschijnlijk liever zien dat ze gevestigde, goed begrepen infrastructuurproducten gebruiken die voor hun doel zijn gebouwd dan dat ze zelf proberen om niet-kerninfrastructuur te bouwen.
• De industrie heeft behoefte aan frameworks zodat er meer ontwikkelingsgeld naar de gebruikerservaring kan gaan in plaats van naar de infrastructuur.