Open vs. gesloten oplossingen

Momenteel wordt de ontwikkeling van klantenservice chatbots gedomineerd door dure specialisten die vaak propriëtaire technologie gebruiken om oplossingen te leveren.

Deze oplossingen hebben de volgende belangrijke nadelen:

• Ze binden klanten aan propriëtaire oplossingen
• De klanten hebben geen of beperkte toegang tot hun eigen gegevens of kritieke broncode
• De klanten kunnen de oplossingen niet gemakkelijk uitbreiden of aanpassen zonder hulp van de leverancier
• De oplossingen worden vaak aangedreven door black box-technologie die zelfs voor experts moeilijk te debuggen en te controleren is
• De oplossingen zijn duur voor wat ze zijn

Er is geen reden waarom het zo zou moeten zijn, behalve het feit dat de chatbotmarkt relatief nieuw is (hoewel niet zo nieuw) en er minder informatie beschikbaar is voor zowel makers van chatbotten als bedrijven over alternatieve oplossingen.

Eén ding is echter zeker: de kosten van deze oplossingen zullen dalen naarmate meer mensen ontdekken dat de technologie voor natuurlijke taalverwerking(NLP) overal beschikbaar is, voor de meeste ontwikkelaars vrij eenvoudig te gebruiken is en scherp geprijsd is.

Maar zelfs als de kosten omlaag gaan, blijven de andere drie nadelen bestaan. Dit zijn nadelen die Botpress wil oplossen door chatbotontwikkeling te democratiseren.

Ons doel bij Botpress is om het maken van hoogwaardige, op maat gemaakte bots binnen het bereik te brengen van beginnende ontwikkelaars en contentmakers, en om manieren te vinden waarop geavanceerde chatbotontwikkelaars de waarde van hun vaardigheden kunnen maximaliseren.

Botpress Sjablonen worden gebouwd op populaire, goed begrepen technologieën (bijvoorbeeld met behulp van het Botpress framework), wat betekent dat de gegevens en broncode open zijn, dat het gemakkelijk is om ontwikkelaars te vinden die aan uw projecten kunnen werken en dat de sjablonen aanpasbaar en uitbreidbaar zijn.

Uitbreidbaarheid is zo belangrijk, want als een bedrijf eenmaal een basisklantenservicebot heeft draaien, zullen ze zich plotseling realiseren welke mogelijkheden dit biedt om andere betrokken diensten op een geïntegreerde manier aan klanten te leveren.

Als het systeem niet open en uitbreidbaar is en het niet eenvoudig is om ontwikkelaars te vinden die eraan willen werken, zullen ze niet in staat zijn om de functionaliteit die ze nodig hebben tegen een redelijke prijs of zelfs helemaal niet toe te voegen.

Stel je bijvoorbeeld voor dat een bedrijf dat tickets verkoopt voor concerten een FAQ-bot maakt om eenvoudige, steeds terugkerende vragen te beantwoorden en om moeilijkere vragen door te sturen naar agenten. Ze realiseren zich dan dat sommige van de vragen die worden gesteld betrekking hebben op de beschikbaarheid van tickets voor bepaalde concerten die niet kunnen worden beantwoord met een eenvoudige FAQ-implementatie. Daarom besluiten ze om de bot te integreren met hun ticketingsysteem om de antwoorden te krijgen.

Het probleem dat ze hebben is of ze in staat zijn om dit te doen of niet, als ze een propriëtaire botoplossing hebben gekocht, zijn ze sterk afhankelijk van de leverancier om dit te doen als het al mogelijk is. En zelfs als het mogelijk is, zullen de kosten om dit te doen veel hoger zijn dan voor een open systeem, aangezien ze een gebonden klant zijn.

Een ander probleem is dat het werk dat ze doen om hun externe systeem met de bot te integreren alleen werkt met het systeem van de leverancier. Het kan niet gemakkelijk worden omgeschakeld om met een ander systeem te werken, dus hoe meer werk ze met die leverancier doen, hoe meer ze vast komen te zitten.

En natuurlijk is de kwaliteit van de oplossing zelf sterk afhankelijk van de eigen oplossing van de leverancier, omdat ze geen toegang hebben tot de beste oplossingen van derden, maar beperkt zijn tot de oplossing van de leverancier.

Dit probleem wordt nog nijpender wanneer het ticketingbedrijf zich realiseert dat ze eigenlijk rechtstreeks vanuit de bot tickets zouden kunnen verkopen, omdat ze beseffen dat dit nog meer investeringen zal vergen en de oplossing zal lijden onder dezelfde nadelen die eerder werden besproken.

Daarom besluiten ze om de bot met veel kosten en moeite opnieuw in te zetten op een open framework. De reden hiervoor is dat ze zich nu realiseren dat deze veranderingen slechts het begin zijn van wat er mogelijk is voor bots en dat uiteindelijk het contactcenter en de services zullen worden gecombineerd in een onmi-channel ervaring die open en uitbreidbaar moet zijn.