Quello che avrei voluto sapere fin dall'inizio sullo sviluppo Chatbots

Erik gestisce un'agenzia di sviluppo di chatbot. Fornisce soluzioni di chatbot a grandi aziende, in particolare nel settore del servizio clienti e del marketing.

Erik mi ha detto che da un lato gli affari vanno molto bene, perché il tasso di conversione delle proposte per chatbots è estremamente alto. Questo forse riflette il fatto che è uno dei primi ad arrivare sul mercato in questo spazio.

Allo stesso tempo, ha faticato a trovare gli strumenti giusti per costruire in modo efficiente un sito chatbots di qualità.

Quando ha scoperto per la prima volta le piattaforme no-code come Chatfuel e Motion.ai, era ottimista sul fatto che questi strumenti avrebbero risolto il suo problema. Pur avendo constatato che funzionavano bene per la prototipazione dei bot, si è rapidamente imbattuto in problemi.

Molti bot dovevano essere personalizzati in modi che potevano essere rappresentati solo dal codice, e queste piattaforme non supportavano la codifica. Alcuni bot dovevano essere integrati con i sistemi legacy del cliente, e anche in questo caso non era possibile.

Questi problemi da soli erano un ostacolo, ma anche se potevano essere risolti, non si sentiva a suo agio con tutta la logica e i dati che risiedevano su un sistema di terze parti su cui non aveva alcun controllo. I suoi clienti spesso insistevano per ospitare il bot in prima persona per motivi di sicurezza.

Ha quindi deciso di far codificare i bot da zero utilizzando Microsoft Bot Framework e, ove possibile, di utilizzare sviluppatori in paesi a basso costo. Questa prevedibilità ha creato altri problemi.

Sebbene ora avesse la proprietà del codice e dei dati e potesse personalizzare il bot nella misura richiesta, i risultati erano contrastanti.

Si è rapidamente reso conto che tutti i bot avevano molte caratteristiche in comune, come la sicurezza basata sui ruoli, le sottoscrizioni, il broadcasting, l'human in the loop, ma queste caratteristiche venivano codificate da zero dagli sviluppatori, aumentando inutilmente i tempi di sviluppo e intaccando i suoi margini di profitto.

Anche i rischi di sviluppo erano inutilmente elevati, perché i diversi sviluppatori codificavano le funzionalità in modi diversi e l'architettura complessiva si evolveva in modo ad hoc. Alcuni sviluppatori avevano riconosciuto questo problema e avevano iniziato a creare librerie riutilizzabili per le funzionalità comuni, ma queste librerie non erano certo quelle di alta qualità su cui il cliente avrebbe voluto costruire la sua azienda. Presentavano rischi e dipendenze indesiderate, soprattutto quando le funzionalità necessarie erano complesse. Era difficile per lui verificare la qualità, per non parlare di dare ai suoi clienti la certezza che tutto ciò che veniva costruito fosse di livello sufficientemente alto.

Ha preso brevemente in considerazione l'idea di costruire una propria piattaforma, ma gli è sembrata eccessiva. Ciò avrebbe creato inutili costi di sviluppo e manutenzione, oltre a potenziali problemi di vendita nel caso in cui fossero emersi framework standard di mercato preferiti dai clienti, cosa che secondo lui sarebbe accaduta. Era solo una questione di tempo.

Nella sua mente il problema era simile a quello che gli sviluppatori web dovevano affrontare agli albori di Internet. All'epoca non esistevano strumenti di gestione dei contenuti come Wordpress, quindi i siti web dovevano essere codificati da zero ogni volta. Questo creava gli stessi problemi di aumento dei costi di sviluppo e di qualità variabile del codice e dell'output che lui si trovava ad affrontare ora quando creava i bot.

Quando Erik ha trovato online Botpress.io non ci ha messo molto a capire che Botpress offriva una potenziale soluzione ai suoi problemi. Gli piaceva l'architettura modulare in teoria e aveva senso per lui costruire un equivalente di un CMS per bot. Era ciò che riteneva necessario. Poteva essere il pezzo mancante del puzzle, ma prima doveva trovare una risposta ad alcune domande.

Innanzitutto doveva essere certo che la soluzione fosse robusta, sicura e affidabile.

In secondo luogo, doveva assicurarsi che tutte le caratteristiche critiche comuni che aveva identificato come necessarie fossero disponibili attraverso il framework.

In terzo luogo, doveva assicurarsi che l'economia funzionasse per la sua agenzia.

Essendo lui stesso una persona pratica e tecnica, ha deciso di convalidare personalmente le prime due domande testando effettivamente il sistema. Si è unito alla comunità di Botpress e ha seguito alcune esercitazioni video utilizzando la versione open source.

Il fatto che esistesse già un'ampia e attiva comunità di sviluppatori che utilizzava il software significava che era già stato testato, il che era positivo.

Inizialmente era preoccupato dal fatto che Botpress fosse open source e che i suoi clienti potessero considerarlo (giustamente in molti casi) un rischio per la sicurezza. Tuttavia, ha scoperto che Botpress aveva una versione aziendale curata, mantenuta separatamente dalla versione open source proprio per risolvere i problemi di sicurezza.

Naturalmente la versione open source offriva alcuni vantaggi, in quanto era gratuita e in molti casi ideale per lo sviluppo di bot al di fuori dei casi d'uso aziendali. Ciò significa che i componenti e l'approccio sono stati utilizzati e convalidati da molti sviluppatori diversi.

Molti dei suoi clienti chiedevano di ospitare il chatbot in sede e di controllare i dati per motivi di sicurezza e commerciali e Botpress li supportava. Inoltre, Botpress consentiva la completa personalizzazione del codice e l'integrazione con i sistemi interni, che era il problema iniziale che aveva con le piattaforme "no-code".

La maggior parte delle funzionalità desiderate erano disponibili. Tra queste, la sicurezza basata sui ruoli, la gestione multiutente e le interfacce utente per la gestione dei bot dopo la distribuzione. Avrebbe potuto facilmente aggiungere ciò che mancava come modulo.

In effetti, l'architettura modulare e le interfacce grafiche del sistema rendevano molto facile capire dove tutto si inserisse. In questo modo, anche se a metà di un progetto passava a nuovi sviluppatori o se qualcuno doveva riprendere in mano il codice dopo un lungo periodo di tempo, non ci sarebbe voluto molto perché la persona interessata si aggiornasse. Fin qui tutto bene.

Anche la questione economica era ovviamente importante. L'utilizzo di Botpress avrebbe ridotto i costi complessivi di sviluppo? I margini di profitto erano stretti. Si aspettava che l'uso di un framework come Botpress avrebbe ridotto i costi di sviluppo e allo stesso tempo aumentato la qualità e le funzionalità.

Le sue aspettative si sono rivelate corrette. Il costo di gestione di Botpress era una piccola frazione del costo di realizzazione di alcune funzionalità e la qualità era migliore rispetto a una soluzione proprietaria.

Il vantaggio nascosto dell'approccio basato sul framework era che avrebbe potuto dedicare più tempo all'interfaccia utente e alle funzionalità del chatbot, migliorando così in modo significativo l'esperienza del cliente finale.

Ha osservato che molti dei chatbots presenti sul mercato non erano così validi. Si potrebbe addirittura affermare che, come industria, i produttori di chatbot stavano deludendo i loro clienti.

Si potrebbe sostenere che ciò sia dovuto al fatto che le aziende non erano disposte a stanziare fondi ragionevoli per lo sviluppo di chatbots perché non erano sicure dei risultati.

Un'altra argomentazione è che il processo di sviluppo di chatbots è stato finora molto inefficiente perché i produttori di chatbot non hanno avuto a disposizione strumenti efficienti per sviluppare chatbots e quindi gran parte dei costi di sviluppo si sono concentrati su quella che è essenzialmente un'infrastruttura.

L'emergere di framework come Botpress ha potenzialmente migliorato in modo massiccio la qualità di chatbots , dato che un maggiore budget di sviluppo viene speso per l'esperienza utente.

Per la cronaca, Erik non è una persona vera e propria, ma un insieme di proprietari di agenzie che ci hanno contattato per sottoporci i loro problemi, le loro esigenze e il loro interesse per ciò che chatbots può fare. In vari modi hanno condiviso la loro versione di "Quello che avrei voluto sapere all'inizio sullo sviluppo di chatbots per i miei clienti".

Se potessimo riassumere le questioni principali sarebbero:

• La costruzione di chatbots richiede l'accesso al codice e ai dati.
• Gli sviluppatori devono personalizzare la logica aziendale e integrarla con i sistemi interni. Non è possibile creare un grande chatbots senza sviluppatori.
• Molti clienti aziendali hanno problemi di sicurezza e quindi vogliono eseguire il loro chatbot in sede. Inoltre, vogliono la stessa sicurezza basata sui ruoli e la stessa gestione degli utenti che si aspettano da qualsiasi software che utilizzano.
• Il framework scelto da un'agenzia dovrebbe fornire un'ampia gamma di funzionalità comuni.
• Non ha senso che un'agenzia (o un negozio di sviluppo) costruisca il proprio framework di chatbot per uso interno, così come non ha senso che costruisca i propri database da zero. Non solo sarebbe antieconomico e genererebbe ingenti costi di manutenzione, ma i loro clienti probabilmente preferirebbero che utilizzassero prodotti infrastrutturali consolidati e ben compresi, costruiti per lo scopo, piuttosto che cercare di costruire da soli un'infrastruttura non essenziale.
• Il settore ha bisogno di framework, in modo che un maggior numero di dollari per lo sviluppo possa essere destinato all'esperienza dell'utente piuttosto che all'infrastruttura.