O que eu gostaria de ter conhecido desde o início sobre o desenvolvimento Chatbots

Erik dirige uma agência de desenvolvimento de chatbots. Fornecem soluções de chatbot a grandes empresas, em particular no sector do serviço ao cliente e do marketing.

Erik disse-me que, por um lado, o negócio está a correr muito bem porque a taxa de conversão das propostas para chatbots é extremamente elevada. Isto talvez reflicta o facto de ele ser um dos primeiros a entrar no mercado neste espaço.

Ao mesmo tempo, estava a lutar para encontrar as ferramentas certas para construir chatbots de qualidade e de forma eficiente.

Quando descobriu as plataformas sem código, como a Chatfuel e a Motion.ai, estava otimista quanto à possibilidade de estas ferramentas resolverem o seu problema. Embora tenha descoberto que funcionavam bem para criar protótipos de bots, rapidamente se deparou com problemas.

Muitos bots precisavam de ser personalizados de formas que só podiam ser representadas em código, e estas plataformas não suportavam a codificação. Alguns bots precisavam de ser integrados com os sistemas antigos do cliente e, mais uma vez, isso não era possível.

Só estes problemas já eram um problema, mas mesmo que pudessem ser resolvidos, ele ainda não se sentia confortável com toda a lógica e dados a residir num sistema de terceiros sobre o qual não tinha qualquer controlo. Os seus clientes insistiam frequentemente em alojar o bot eles próprios por razões de segurança.

Por conseguinte, decidiu codificar os bots de raiz utilizando o Microsoft Bot Framework e, sempre que possível, recorrer a programadores em países de baixo custo. Esta previsibilidade criou outros problemas.

Embora agora tivesse a propriedade do código e dos dados e pudesse personalizar o bot à medida das suas necessidades, os resultados foram díspares.

Apercebeu-se rapidamente de que todos os bots tinham muitas características em comum, como a segurança baseada em funções, as subscrições, a difusão, os humanos no circuito, mas estas características estavam a ser codificadas de raiz pelos programadores, o que aumentava desnecessariamente o tempo de desenvolvimento e corroía as suas margens de lucro.

Os riscos de desenvolvimento eram também desnecessariamente elevados porque diferentes programadores codificavam as funcionalidades de formas diferentes e a arquitetura geral evoluía de forma ad hoc. Alguns programadores tinham reconhecido este problema e começaram a criar bibliotecas reutilizáveis para funcionalidades comuns, mas estas bibliotecas dificilmente eram as bibliotecas de alta qualidade sobre as quais ele gostaria de construir o seu negócio. Apresentavam os seus próprios riscos e dependências indesejadas, especialmente quando a funcionalidade necessária era complexa. Era difícil para ele verificar a qualidade, quanto mais dar aos seus clientes a confiança de que tudo o que era construído era de um nível suficientemente elevado.

Considerou brevemente a ideia de construir a sua própria plataforma, mas isso pareceu-lhe um exagero. Se o fizesse, criaria custos de desenvolvimento e manutenção desnecessários, bem como potenciais problemas de vendas se surgissem estruturas padrão de mercado que os clientes preferissem, o que ele acreditava que iria acontecer. Era apenas uma questão de tempo.

Na sua mente, o problema era semelhante ao que os programadores Web enfrentavam no início da Internet. Nessa altura, não existiam ferramentas de gestão de conteúdos, como o Wordpress, pelo que os sítios Web tinham de ser sempre codificados de raiz. Isto criou os mesmos problemas de aumento dos custos de desenvolvimento e de qualidade variável do código e dos resultados que ele estava a enfrentar agora ao criar bots.

Quando Erik encontrou Botpress.io online, não demorou muito tempo a reconhecer que Botpress oferecia uma potencial solução para os seus problemas. Ele gostou da arquitetura modular em teoria e fez sentido para ele construir um equivalente a um CMS para bots. Era o que ele acreditava ser necessário. Podia ser a peça que faltava no puzzle, mas primeiro precisava de algumas perguntas respondidas.

Em primeiro lugar, precisava de ter a certeza de que a solução era robusta, segura e fiável.

Em segundo lugar, precisava de se certificar de que todas as características críticas comuns que tinha identificado como sendo necessárias estavam disponíveis através do quadro

Em terceiro lugar, precisava de ter a certeza de que a economia funcionaria para a sua agência.

Sendo ele próprio uma pessoa técnica e prática, decidiu validar pessoalmente as duas primeiras questões, testando efetivamente o sistema. Juntou-se à comunidade Botpress e trabalhou em alguns dos tutoriais em vídeo utilizando a versão de código aberto.

O facto de já existir uma comunidade grande e ativa de programadores que utilizam o software significa que este foi testado em combate, o que é bom.

Inicialmente, ele estava preocupado com o facto de o Botpress ser de código aberto, o que os seus clientes poderiam considerar (com razão em muitos casos) como um risco de segurança. No entanto, descobriu que o Botpress tinha uma versão empresarial que era mantida separadamente da versão de código aberto, especificamente para resolver os problemas de segurança.

É claro que a versão de código aberto oferecia algumas vantagens pelo facto de ser de utilização gratuita e, em muitos casos, ideal para desenvolver bots fora do caso de utilização empresarial. Isso significava que os componentes e a abordagem eram muito utilizados e validados por muitos programadores diferentes.

Muitos dos seus clientes exigiam que o chatbot fosse alojado no local e que os dados fossem controlados por razões de segurança e comerciais, e o Botpress apoiava esta exigência. Além disso, o Botpress permitia a personalização total do código e a integração com sistemas internos, que era o problema original que ele tinha com as plataformas "sem código".

A maioria das funcionalidades que ele queria estava disponível. Estas incluíam segurança baseada em funções, gestão multiutilizador e interfaces de utilizador para gerir os bots após a implementação. Ele poderia facilmente adicionar o que faltava como um módulo.

De facto, a arquitetura modular e as interfaces gráficas do sistema tornavam muito fácil perceber onde tudo se encaixava. Isto significava que, mesmo que ele mudasse para novos programadores a meio de um projeto ou que alguém tivesse de pegar no código após um longo intervalo, não demoraria muito tempo até que a pessoa em questão se habituasse a trabalhar. Até aqui tudo bem.

A questão económica era obviamente também importante. A utilização do Botpress reduziria os seus custos globais de desenvolvimento? As margens de lucro eram reduzidas. A sua expetativa era que a utilização de uma estrutura como Botpress reduziria os custos de desenvolvimento e, ao mesmo tempo, aumentaria a qualidade e as funcionalidades.

Verificou-se que as suas expectativas estavam correctas. O custo de funcionamento do Botpress era uma pequena fração do custo de construir ele próprio algumas das funcionalidades e a qualidade era superior à de uma solução proprietária.

A vantagem oculta da abordagem da estrutura era o facto de poder dedicar mais tempo à interface do utilizador e à funcionalidade do chatbot, melhorando assim significativamente a experiência do cliente final.

Ele tinha observado que muitos dos chatbots existentes no mercado não eram assim tão bons. Poder-se-ia mesmo dizer que, enquanto indústria, os fabricantes de chatbots estavam a falhar com os seus clientes.

Poder-se-ia argumentar que tal se deve ao facto de as empresas não estarem preparadas para afetar fundos razoáveis ao desenvolvimento de chatbots por não terem a certeza dos resultados.

Outro argumento é que o processo de desenvolvimento do chatbots tem sido muito ineficiente até à data, porque os fabricantes de chatbots não dispõem de ferramentas eficientes para desenvolver o chatbots e, por conseguinte, grande parte do custo de desenvolvimento centrou-se no que é essencialmente uma infraestrutura.

O surgimento de estruturas como Botpress tinha o potencial de melhorar enormemente a qualidade de chatbots , uma vez que mais orçamento de desenvolvimento é gasto na experiência do utilizador.

Para que conste, Erik não é uma pessoa real, mas uma composição de alguns dos proprietários de agências que nos contactaram com os seus problemas, requisitos e interesse no que o chatbots pode fazer. De várias formas, partilharam a sua versão de "O que gostaria de ter sabido desde o início sobre o desenvolvimento de chatbots para os meus clientes".

Se pudéssemos resumir as principais questões, elas seriam as seguintes:

• Para construir um ótimo chatbots é necessário ter acesso ao código e aos dados.
• Os programadores precisam de personalizar a lógica comercial e de a integrar nos sistemas internos. Não é possível criar um ótimo chatbots sem programadores.
• Muitos clientes empresariais têm preocupações de segurança e, por isso, querem executar o seu chatbot no local. Também pretendem a mesma segurança baseada em funções e gestão de utilizadores que esperam de qualquer software que utilizem.
• O quadro que uma agência escolhe deve fornecer uma vasta gama de características comuns de imediato.
• Não faz sentido para qualquer agência (ou loja de desenvolvimento) construir a sua própria estrutura de chatbot para uso interno, tal como não faz sentido para eles construir as suas próprias bases de dados de raiz. Não só isso não seria económico e geraria grandes custos de manutenção, como os seus clientes provavelmente prefeririam que utilizassem produtos de infraestrutura estabelecidos e bem compreendidos que são construídos para o efeito, em vez de tentarem construir eles próprios infra-estruturas não essenciais.
• A indústria necessita de estruturas para que mais dólares de desenvolvimento possam ser canalizados para a experiência do utilizador e não para a infraestrutura.