Lo que me hubiera gustado saber desde el principio sobre el desarrollo Chatbots

Erik dirige una agencia de desarrollo de chatbots. Proporcionan soluciones de chatbot a grandes empresas, sobre todo en el ámbito de la atención al cliente y el marketing.

Erik me dijo que, por un lado, el negocio va muy bien porque la tasa de conversión de los lanzamientos para chatbots es extremadamente alta. Tal vez esto refleje el hecho de que es uno de los primeros en comercializar este espacio.

Al mismo tiempo, se esforzaba por encontrar las herramientas adecuadas para construir eficazmente un sitio web de calidad: chatbots .

Cuando descubrió por primera vez las plataformas sin código, como Chatfuel y Motion.ai, era optimista y pensaba que estas herramientas resolverían su problema. Aunque descubrió que funcionaban bien para crear prototipos de bots, enseguida se encontró con problemas.

Muchos bots necesitaban personalizarse de formas que sólo podían representarse en código, y estas plataformas no admitían la codificación. Algunos bots necesitaban integrarse con los sistemas heredados de su cliente, y de nuevo esto no era posible.

Estos problemas por sí solos rompían el acuerdo, pero aunque pudieran resolverse, seguía sin sentirse cómodo con toda la lógica y los datos residiendo en un sistema de terceros sobre el que no tenía ningún control. Sus clientes solían insistir en alojar ellos mismos el bot por motivos de seguridad.

Por eso decidió programar los bots desde cero con Microsoft Bot Framework y, en la medida de lo posible, recurrir a desarrolladores de países de bajo coste. Esta previsibilidad creó otros problemas.

Aunque ahora era propietario del código y los datos y podía personalizar el bot en la medida necesaria, los resultados fueron desiguales.

Rápidamente se dio cuenta de que todos los bots tenían muchas características en común, como la seguridad basada en roles, las suscripciones, la difusión, los humanos en el bucle, pero estas características estaban siendo codificadas desde cero por los desarrolladores, lo que aumentaba innecesariamente el tiempo de desarrollo y mermaba sus márgenes de beneficio.

Los riesgos de desarrollo también eran innecesariamente altos, porque los distintos desarrolladores codificaban las funciones de maneras diferentes y la arquitectura general evolucionaba de forma ad hoc. Algunos desarrolladores habían reconocido este problema y empezaron a crear bibliotecas reutilizables para funciones comunes, pero estas bibliotecas difícilmente eran las bibliotecas de alta calidad en las que querría basar su negocio crea . Presentaban sus propios riesgos y dependencias no deseadas, sobre todo cuando la funcionalidad necesaria era compleja. Le resultaba difícil verificar la calidad, por no hablar de dar confianza a sus clientes de que todo lo que se construía era de un nivel suficientemente alto.

Consideró brevemente la idea de crear su propia plataforma, pero le pareció exagerado. Eso generaría costes innecesarios de desarrollo y mantenimiento, además de posibles problemas de venta si surgían marcos estándar en el mercado que los clientes prefirieran, lo que él creía que ocurriría. Era cuestión de tiempo.

En su mente, el problema era similar al que tenían los desarrolladores web en los albores de Internet. En aquella época no existían herramientas de gestión de contenidos como Wordpress, por lo que los sitios web debían codificarse desde cero cada vez. Esto creaba los mismos problemas de aumento de los costes de desarrollo y calidad variable en el código y los resultados a los que se enfrentaba ahora al crear bots.

Cuando Erik encontró Botpress.io en Internet no tardó en reconocer que Botpress ofrecía una solución potencial a sus problemas. En teoría le gustaba la arquitectura modular y para él tenía sentido crea un equivalente de un CMS para bots. Era lo que él creía que se necesitaba. Podía ser la pieza que faltaba en el rompecabezas, pero antes necesitaba que le respondieran a algunas preguntas.

En primer lugar, necesitaba estar seguro de que la solución era sólida, segura y fiable.

En segundo lugar, tenía que asegurarse de que todas las características críticas comunes que había identificado como necesarias estuvieran disponibles a través del framework

En tercer lugar, tenía que asegurarse de que la economía funcionaría para su agencia.

Al ser una persona práctica y técnica, decidió validar personalmente las dos primeras preguntas probando el sistema. Se unió a la comunidad Botpress y trabajó con algunos de los tutoriales en vídeo utilizando la versión de código abierto.

El hecho de que ya existiera una comunidad amplia y activa de desarrolladores que utilizaban el programa significaba que estaba probado en batalla, lo cual era positivo.

Al principio le preocupaba que Botpress fuera de código abierto, lo que sus clientes podían considerar (con razón en muchos casos) un riesgo para la seguridad. Sin embargo, descubrió que Botpress contaba con una versión para empresas que se mantenía separada de la versión de código abierto, específicamente para abordar los problemas de seguridad.

Por supuesto, la versión de código abierto ofrecía algunas ventajas, ya que su uso era gratuito y, en muchos casos, resultaba ideal para desarrollar bots fuera del ámbito empresarial. Significaba que los componentes y el enfoque eran muy utilizados y validados por muchos desarrolladores diferentes.

Muchos de sus clientes exigían alojar el chatbot in situ y controlar los datos por motivos comerciales y de seguridad, y Botpress lo permitía. Además, Botpress permitía la personalización completa del código y la integración con sistemas internos, que era el problema original que tenía con las plataformas "sin código".

La mayoría de las funciones que quería estaban disponibles. Entre ellas, seguridad basada en roles, gestión multiusuario e interfaces de usuario para gestionar los bots tras su despliegue. Podía añadir fácilmente lo que faltaba como módulo.

De hecho, la arquitectura modular y las interfaces gráficas del sistema hacían que fuera muy fácil entender dónde encajaba cada cosa. Esto significaba que incluso si cambiaba a nuevos desarrolladores a mitad de un proyecto o alguien tenía que retomar el código después de un largo intervalo, la persona en cuestión no tardaría mucho en ponerse al día. Hasta aquí todo bien.

Obviamente, la cuestión económica también era importante. ¿Reduciría Botpress sus costes generales de desarrollo? Los márgenes de beneficio eran estrechos. Esperaba que el uso de un marco como Botpress redujera los costes de desarrollo y, al mismo tiempo, aumentara la calidad y las prestaciones.

Resultó que sus expectativas eran correctas. El coste de funcionamiento de Botpress fue una pequeña fracción del coste de construir incluso algunas de las características por sí mismo y la calidad fue mejor que una solución propietaria.

La ventaja oculta del enfoque del marco era que podría dedicar más tiempo a la interfaz de usuario y la funcionalidad del chatbot y, por tanto, mejorar significativamente la experiencia del cliente final.

Había observado que muchos de los chatbots del mercado no eran tan buenos. Incluso podría decirse que, como industria, los creadores de chatbots estaban fallando a sus clientes.

Podría argumentarse que esto se debe a que las empresas no estaban dispuestas a destinar fondos razonables al desarrollo de chatbots porque no estaban seguras de los resultados.

Otro argumento es que el proceso de desarrollo de chatbots ha sido muy ineficiente hasta la fecha porque los creadores de chatbot no han contado con herramientas eficientes para desarrollar chatbots y, por tanto, gran parte del coste de desarrollo se ha centrado en lo que es esencialmente infraestructura.

La aparición de frameworks como Botpress tenía el potencial de mejorar masivamente la calidad de chatbots , ya que se gasta más presupuesto de desarrollo en la experiencia del usuario.

Para que conste, Erik no es una persona real, sino un retrato robot de algunos de los propietarios de agencias que se han puesto en contacto con nosotros para contarnos sus problemas, requisitos e interés por lo que puede hacer chatbots . De diversas maneras, compartieron su versión de "Lo que me hubiera gustado saber al principio sobre el desarrollo de chatbots para mis clientes".

Si pudiéramos resumir las principales cuestiones serían:

• Para construir un gran chatbots es necesario tener acceso al código y a los datos.
• Los desarrolladores tienen que personalizar la lógica empresarial e integrarla con los sistemas internos. No es posible crear una gran chatbots sin desarrolladores.
• Muchos clientes empresariales se preocupan por la seguridad y, por lo tanto, quieren ejecutar su chatbot in situ. También quieren la misma seguridad basada en roles y la gestión de usuarios que esperarían de cualquier software que utilicen.
• El marco que elija una agencia debe ofrecer una amplia gama de características comunes desde el primer momento.
• No tiene sentido que una agencia (o tienda de desarrollo) cree su propio marco de chatbot en crea para uso interno, como tampoco tiene sentido que cree sus propias bases de datos en crea desde cero. No sólo sería antieconómico y generaría grandes costes de mantenimiento, sino que sus clientes probablemente preferirían que utilizaran productos de infraestructura establecidos y bien entendidos, creados para un fin, en lugar de intentar crea ellos mismos la infraestructura no básica.
• El sector necesita marcos que permitan destinar más dinero al desarrollo de la experiencia del usuario que a la infraestructura.