Chatbot-platforms: Ontwikkelaars en zakelijke gebruikers

Moeten Chatbot-platforms zich richten op zakelijke gebruikers of op ontwikkelaars?

Chatbot-platforms hebben blijkbaar een keuze. Richten ze zich op zakelijke gebruikers of op ontwikkelaars?

Een antwoord op deze vraag is dat ze beide nodig hebben, omdat ze allebei bij het proces betrokken moeten zijn.

Een betere vraag zou kunnen zijn wat de beste manier is om zakelijke gebruikers en ontwikkelaars effectief te laten bijdragen aan chatbot bouwen op een manier die het beste gebruik maakt van hun verschillende vaardigheden?

Zakelijke gebruikers begrijpen het bedrijfsdomein en het probleem dat ze proberen op te lossen beter dan de ontwikkelaar. Er kan veel tijd worden bespaard en de productkwaliteit kan worden verbeterd als ze de chatbot direct in de software kunnen bouwen.

Ontwikkelaars hebben natuurlijk de vaardigheden om de software op elke gewenste manier aan te passen. Als de software verder moet worden aangepast dan gemakkelijk kan worden gedaan, moeten er ontwikkelaars bij worden betrokken.

Vanuit het oogpunt van het chatbotplatform is de afweging dat de mogelijkheid om aan te passen het product complexer maakt. Op een gegeven moment wordt de leercurve te lastig voor zakelijke gebruikers en kunnen alleen power users het product gebruiken. Op een ander punt is de complexiteit zo groot dat alleen ontwikkelaars het product kunnen gebruiken.

Een manier om deze vraag naar de beste manier voor ontwikkelaars en zakelijke gebruikers om samen te werken te bekijken, is door na te gaan hoeveel complexiteit er eigenlijk nodig is om een bot te bouwen. Zou het mogelijk zijn om een platform te hebben waar zakelijke gebruikers alles kunnen doen?

Mijn antwoord hierop is "Nee" als de bot vanaf nul is opgebouwd of moet worden aangepast.

Mijn antwoord is "Ja" als de bot heel eenvoudig is of opgebouwd is uit een uitgebreid sjabloon.

‍

Een FAQ bot is een voorbeeld van een heel eenvoudige bot. Dit is het soort bot dat zakelijke gebruikers gemakkelijk kunnen bouwen. Een bot die uitsluitend is opgebouwd uit een sjabloon kan ook worden gebouwd door de zakelijke gebruikers.

De meeste bot use cases vereisen echter maatwerk, zelfs als ze gebruik maken van sjablonen. Op zijn minst moeten systemen worden geïntegreerd en dit kan niet worden gedaan door een zakelijke gebruiker. Er is ook het feit van maatwerk. Het komt vaak voor dat een bedrijf een nieuwe use case of ideeën heeft waarvoor de chatbot moet worden aangepast. Deze aanpassingen zijn normaal gesproken moeilijk te doen in een GUI die is gemaakt voor zakelijke gebruikers en daarom moeten ze worden gedaan door ontwikkelaars.

Dat wil niet zeggen dat er geen optimale manier is voor zakelijke gebruikers en ontwikkelaars om samen te werken op een platform om de productiviteit te optimaliseren. De vraag is op welke manieren het platform tegemoet moet komen aan zakelijke gebruikers en ontwikkelaars om deze optimale samenwerking te bereiken.

Er zijn bot-platforms die sterk vereenvoudigde GUI's bieden voor zakelijke gebruikers. Deze GUI's creëren de illusie dat zakelijke gebruikers de controle hebben over het chatbotbouwproces. De chatbotmodellen die ze bouwen zijn dan programmatisch toegankelijk voor ontwikkelaars om aanpassingen en integraties te maken.

Het probleem met de sterk vereenvoudigde GUI is dat het de mogelijkheden van de zakelijke gebruiker beperkt. Het is ook zo dat de ontwikkelaar normaal gesproken veel meer ervaring heeft in het begrijpen van de optimale manieren om software te bouwen, dus zij moeten misschien betrokken worden bij de ontwerpkeuzes op het niveau van de GUI.

Er is een botplatform waarmee zakelijke gebruikers ogenschijnlijk een geavanceerde chatbot vanaf nul kunnen maken zonder enige code. Het voorbeeld dat ik zag was van een chatbot die pizza's bestelde. In wezen hoefde de zakelijke gebruiker alleen maar een formulier in te vullen met de parameters die ze wilden vastleggen voor de pizza-bestelling, zoals de grootte en de toppings en de bijbehorende vragen, en de bot zou de rest doen.

Er waren hier drie problemen

De eerste is dat zakelijke gebruikers zonder training waarschijnlijk geen naamconventies voor parameters zullen gebruiken en zich niet zullen houden aan andere ontwerpconventies. Dit kan dan een rommelige bot creëren, zelfs als ze binnen de grenzen van de GUI werken.

Het tweede probleem is dat de chatbot in werkelijkheid uitgebreid zou moeten worden aangepast. De chatbot zou bijvoorbeeld prijzen moeten weten en bijhouden terwijl de gebruiker door de bestelling gaat en zou moeten integreren met de backend. Hoewel de zakelijke gebruiker veel meer kennis heeft van de vereisten, kan hij de ontwikkelaar vertragen door op deze manier betrokken te zijn.

Het derde probleem is dat de juiste GUI het werk van de ontwikkelaar juist zou kunnen versnellen. Als de ontwikkelaar de GUI wil gebruiken, moeten ze een GUI met zeer beperkte functionaliteit gebruiken en dan de rest in code doen, wat de meest complexe manier is om dingen te doen. Een geavanceerde GUI zou het coderen drastisch kunnen verminderen.

De optimale oplossing kan betekenen dat bedrijven realistischer moeten zijn over wat er nodig is om een chatbot van hoge kwaliteit te maken. Dit betekent dat ze moeten erkennen dat uitgebreid maatwerk nodig is, zoals voor elke software, en dat het daarom beter is dat ontwikkelaars (of op zijn minst power users met geavanceerde tools) de controle hebben over het ontwikkelproces.

Zakelijke gebruikers moeten controle hebben over het algemene ontwerp. Ze moeten ook direct controle hebben over de inhoud en de intenties.

De meest efficiënte manier voor hen om samen te werken met de ontwikkelaars is om een agile methodologie te volgen en te itereren naar de beste oplossing. Dit betekent dat je agile technieken gebruikt om de chatbot snel te bouwen volgens een origineel ontwerp en vervolgens zakelijke gebruikers de chatbot laat testen en verfijnen door regelmatig feedback te geven.

Vanuit het oogpunt van het botplatform betekent dit twee dingen:

1. Zorg ervoor dat zakelijke gebruikers gemakkelijk de dingen kunnen doen die ze zeker moeten doen, zoals inhoud beheren en de zinnen voor intenties.
2. Zorg ervoor dat de ontwikkelaars al het andere zo efficiënt mogelijk kunnen doen. Dit betekent ervoor zorgen dat de GUI zeer flexibel is en werkt zoals de ontwikkelaars het zouden willen.

‍

Bot-platforms moeten ook het aanmaken en delen van sjablonen en wizards mogelijk maken. Sjablonen en wizards (gebruikt door zakelijke gebruikers) kunnen bedrijven helpen om sneller in productie te gaan, zelfs als er nog materiaal moet worden aangepast.

Een andere trend in het bouwen van chatbots is dat intents worden vervangen door objectbeschrijvingen. Zakelijke gebruikers kunnen objecten selecteren die door het platform worden ondersteund en eenvoudig de eigenschappen bijwerken die aan deze objecten zijn gekoppeld. Het platform zal dan zorgen voor de afhandeling van vragen van eindgebruikers over deze objecten.

Een zakelijke gebruiker kan bijvoorbeeld een "creditcard"-object selecteren voor een chatbot voor bankieren en vervolgens een formulier invullen met betrekking tot dit object. Het formulier zou kunnen vragen met wie de gebruiker contact moet opnemen als de kaart kwijt is, met wie hij contact moet opnemen als de kaart vervangen moet worden, enz. Op een vergelijkbare manier als bij het gebruik van een sjabloon of wizard, kan de zakelijke gebruiker profiteren van een chatbot die al tot op zekere hoogte is gemaakt voor de betreffende taak.

Het chatbotplatform bepaalt voor een deel hoe zakelijke gebruikers en ontwikkelaars kunnen samenwerken aan een bepaalde chatbot. Naar onze mening is de meest efficiënte manier om samen te werken om zakelijke gebruikers volledige controle te geven over taken die ze volledig zelf kunnen doen, zoals content en augmenting intents, en vervolgens de ontwikkelaar de chatbot zo efficiënt mogelijk te laten bouwen.

De zakelijke gebruiker heeft uiteindelijk de leiding over het ontwerp en moet volledig betrokken zijn bij het proces om ervoor te zorgen dat de chatbot aan de verwachtingen voldoet. De ontwikkelaar zal de onderliggende functionaliteit zo efficiënt mogelijk moeten maken.