Flujo de trabajo de chatbot: cómo diseñar uno que resuelva tickets

Qué es en realidad un flujo de trabajo de chatbot

Si despojas a un chatbot de todo lo demás, quedan dos cosas: una interfaz conversacional y la lógica subyacente que decide qué pasa después. Esa lógica es el flujo de trabajo, y es el verdadero motor detrás de cualquier IA de atención al cliente. Tidio lo dice sin rodeos en su guía de diagramas de flujo de conversación: los chatbots son "poco más que diagramas de árbol de decisión equipados con una interfaz de usuario conversacional".

Eso es cierto sobre la forma de un flujo de trabajo, pero lo interesante es lo que llena cada nodo. Un flujo de trabajo no es solo "si el usuario hace clic en A, ve a B". Uno bueno tiene que entender un mensaje que nunca ha visto, encontrar la respuesta correcta en una base de conocimiento y saber la diferencia entre una pregunta que puede cerrar con seguridad y una que nunca debería tocar. El mapa es la parte fácil. El criterio dentro de cada paso es donde un flujo de trabajo de chatbot triunfa o fracasa.

Aquí está todo de un vistazo, y luego recorro cada etapa.

Las seis etapas de un flujo de trabajo de chatbot de soporte

Casi todo flujo de trabajo de chatbot de soporte, basado en reglas o en IA, atraviesa las mismas seis etapas. Nombrarlas deja claro dónde el tuyo es débil.

1. Disparador. Algo pone en marcha el flujo de trabajo: un cliente abre la burbuja de chat, envía un correo, escribe por WhatsApp, o llega un ticket nuevo al helpdesk. El disparador también trae contexto que querrás después, como el canal, el historial de pedidos del cliente o en qué página estaba.
2. Entender la intención. El bot averigua qué quiere realmente la persona. Un flujo basado en reglas hace esto con botones y palabras clave; un flujo de IA lee el texto libre directamente, así que "mi paquete todavía no llega" y "dónde está mi pedido" aterrizan en la misma intención sin que hayas escrito ninguna de las dos frases.
3. Recuperar conocimiento. El bot busca la respuesta en un centro de ayuda, tickets anteriores, documentos internos o un sistema en vivo como una base de datos de pedidos. Esta es la etapa que la mayoría de las demostraciones se saltan y de la que dependen la mayoría de los flujos de trabajo reales: un bot sin fundamento simplemente se inventa las cosas.
4. Decidir y ramificar. Con la intención y una respuesta en mano, el flujo de trabajo elige un camino: responder directamente, hacer una pregunta aclaratoria, ejecutar una acción o escalar. Este es el cerebro del flujo de trabajo, y es donde pertenece la verificación de confianza.
5. Ejecutar una acción. Para preguntas simples, la "acción" es solo responder. Para resoluciones reales, es hacer algo: consultar un pedido, emitir un reembolso, etiquetar y enrutar el ticket, actualizar un campo. Un flujo de trabajo que solo puede hablar, nunca actuar, tiene como techo la desviación y nunca llega a la resolución.
6. Resolver o escalar. La conversación termina de una de dos maneras: el bot la resuelve, o la transfiere limpiamente a un humano con todo el contexto adjunto. Una transferencia que arroja al cliente a una cola nueva para que reexplique todo no es una transferencia, es un castigo.

Así es como se ven las etapas de la 2 a la 6 dentro de un producto real, en vez de en un diagrama: el cliente pregunta, el agente responde desde el conocimiento conectado, y en el momento en que no puede ayudar, ofrece a un humano.

Vi esta misma secuencia jugarse hace poco en el chat en vivo del sitio de una herramienta de SEO: el bot respondió dos preguntas de cómo hacer algo desde la documentación, y en el instante en que el usuario escribió "¿puedo hablar con un humano?", transfirió sin dudarlo. Esa desviación limpia seguida de un traspaso es lo que se ve en la vida real cuando un flujo de trabajo está sano, y es el patrón que vale la pena diseñar.

Flujos de trabajo basados en reglas frente a flujos de agente de IA

La decisión más importante que tomarás no es una etapa, es qué tipo de flujo de trabajo estás construyendo. Los dos se ven parecidos en una pizarra y se comportan de forma completamente distinta en producción.

Un flujo de trabajo basado en reglas es un árbol de decisión que dibujas a mano. Es predecible y barato de razonar, y para un flujo estrecho y de alto volumen ("consultar el estado de mi pedido" detrás de tres botones) funciona realmente bien. La trampa es todo lo que queda fuera del guion, y las matemáticas son brutales: Tidio señala que un árbol "simple" de solo siete preguntas de sí o no ya se ramifica en 128 escenarios posibles, por lo que su propia regla es "un bot de decisión, un tema". Pasa ese límite y el cliente escribe algo que no anticipaste, y el bot no tiene dónde enviarlo: el clásico callejón sin salida del diagrama de flujo. Terminas manteniendo un árbol que crece sin parar, añadiendo ramas cada vez que aparece una nueva forma de decir algo, y aun así no puede seguir el ritmo de cómo escribe realmente la gente.

Un flujo de trabajo de agente de IA invierte el esfuerzo. En lugar de que enumeres cada camino, el agente lee la intención en texto libre, recupera la respuesta de tu conocimiento y decide qué hacer, incluido reconocer cuándo está fuera de su alcance. Ya no dibujas ramas; estableces barreras de protección.

Esto no es un argumento de que "las reglas están muertas". Muchos buenos flujos de trabajo usan reglas para las partes deterministas (horario comercial, un número de pedido obligatorio) y dejan la comprensión difusa del lenguaje a la IA. Pero si estás construyendo un flujo de trabajo de soporte esperando manejar toda la variedad de lo que escriben los clientes, un árbol de decisión puro te va a costar una batalla eterna. Es la misma razón por la que los equipos abandonan los bots con guion hacia un verdadero agente de IA a medida que crece el volumen.

Los dos puntos de decisión que realmente importan

Una vez que una IA se encarga de la comprensión del lenguaje, tu trabajo de diseño se reduce a dos preguntas: ¿cuándo debería actuar el bot por su cuenta, y cuándo debería apartarse? Acierta en esto y el resto del flujo de trabajo prácticamente se resuelve solo.

Enruta según la confianza, no las palabras clave

El control más solicitado que escucho de los equipos de soporte es el enrutamiento basado en confianza: dejar que el bot maneje solo aquello de lo que está seguro, y dejar el resto en paz. Una líder de CX en una marca de suplementos DTC, que gestiona cerca de 7.000 tickets al mes en Gorgias, expresó ese temor mejor de lo que yo podría. La IA nunca responderá el 100% de las preguntas, me dijo, y si solo responde "lo siento, no lo sé", ella no puede volver atrás y revisar 7.000 tickets para ver si realmente ayudó. Lo que quería era una IA que "solo maneje los tickets que tiene la confianza de manejar, y todos los demás, que los deje en paz".

Ese es todo el argumento para puntuar la confianza en la etapa de decidir y ramificar. Un flujo de trabajo que responde a todo es un flujo de trabajo que se equivocará con confianza. Un flujo de trabajo que puntúa su propia certeza puede autorresolver los tickets fáciles, redactar una respuesta para un humano en los casos medios y nunca tocar los que no entiende.

Esta también es tu mejor defensa contra las alucinaciones. En lugar de esperar que el modelo se comporte, estableces un piso: por debajo de un umbral, el bot redacta en vez de enviar, o escala en vez de adivinar. El umbral de confianza de intención es un mando real en las herramientas maduras, no una abstracción.

Diseña el escalamiento, no lo añadas después

El otro punto de decisión es el traspaso a un humano, y merece tanto diseño como el camino ideal. Escucho el objetivo planteado casi de forma idéntica en las llamadas de ventas: un gerente de soporte en un servicio de rastreo de autobuses, que gestiona entre 200 y 250 tickets de Zendesk al mes, quería un agente que pudiera "manejar el 60% de los tickets entrantes de Zendesk y saber cuándo traer a una persona real para un mejor análisis y resolución". La mitad de "saber cuándo traer a una persona real" es la mitad importante.

Un buen escalamiento lleva la conversación completa, el contexto del cliente y la mejor suposición del bot sobre el problema directamente al humano o la cola correctos, para que nadie tenga que reexplicar nada. Por eso los desarrolladores maduros tratan el traspaso como un paso terminal con una carga útil real adjunta: en el creador de agente de IA de Zendesk, "transferir al agente" es un paso final que crea silenciosamente un ticket con todo el historial de la conversación que el cliente nunca ve. eesel hace lo mismo dejando una respuesta redactada y el contexto como una nota interna, o transfiriendo al helpdesk, según cómo lo hayas configurado.

También querrás control sobre lo que el bot tiene permitido tocar. Los equipos reales piden esto constantemente ("hay ciertos tickets que no quiero que pasen por la IA"), y un flujo de trabajo que no puede excluir un tipo de ticket, o actuar solo cuando se invoca explícitamente, no está listo para una cola en producción. El escalamiento no es un respaldo; es una rama de primera clase. Nuestro análisis completo sobre las escalaciones de agentes de IA profundiza más en la mecánica.

Errores comunes en los flujos de trabajo de chatbot

Los clientes pueden describir un flujo de trabajo roto mejor que cualquier especificación. Un hilo de r/automation clavó los síntomas:

"the tells: loop you back to FAQ, ask you to rephrase (3 times), refuse to escalate. the fix isn't a smarter chatbot. it's a chatbot that knows when to hand off."

La mayoría de los flujos de trabajo rotos fallan del mismo puñado de maneras. Presta atención a esto:

• Callejones sin salida. El clásico basado en reglas. Todo camino debería llevar a algún lado, aunque ese "algún lado" sea un humano. Si una rama puede atrapar a un cliente sin forma de avanzar, es un error.
• Sobreautomatización. Dejar que el bot responda a todo para perseguir una cifra de desviación. Así es como terminas con respuestas erróneas dadas con confianza, a escala. Limita al bot a lo que tiene la confianza de manejar.
• Sin fundamento de conocimiento. Un flujo de trabajo con un gran árbol de decisión y nada de donde recuperar información improvisará, y las respuestas de soporte improvisadas son la forma en que terminas en una captura de pantalla en redes sociales. Fundamenta cada respuesta en documentos reales y tickets anteriores.
• Escalamiento como algo secundario. Transferir a una cola fría donde el cliente reexplica todo. Lleva el contexto contigo.
• Lanzarlo a ciegas. Soltar un flujo de trabajo con clientes en vivo sin haberlo probado nunca contra los mensajes que realmente va a recibir. Lo cual nos lleva al último paso, y el que más se salta.

Prueba el flujo de trabajo antes de lanzarlo en producción

Aquí está la parte que casi nadie hace, y la razón por la que la incorporo en cada lanzamiento: ejecuta el flujo de trabajo contra tus tickets históricos reales antes de que hable con un cliente. Aprendí esto por las malas, viendo a un bot que sonaba seguro dar respuestas incorrectas en silencio, así que ahora lo primero que hace cualquier agente nuevo es una simulación sobre tickets anteriores, no una conversación en vivo.

Una simulación reproduce miles de tus tickets cerrados a través del flujo de trabajo y te muestra exactamente qué habría dicho, qué porcentaje habría resuelto y en qué temas es débil, todo antes de que esté en producción. Encuentras las brechas, añades la documentación que falta, ajustas el umbral de confianza y vuelves a ejecutarlo. Convierte el "esperamos que funcione" en un número que puedes señalar, que es más o menos la diferencia entre un flujo de trabajo en el que confías y uno que te pone nervioso cada mañana.

El beneficio de un flujo de trabajo probado se nota rápido. Gridwise logró que eesel resolviera el 73% de sus solicitudes de nivel 1 en el primer mes, con resultados visibles durante una prueba de 7 días. Smava ejecuta un agente totalmente automatizado sobre más de 100.000 tickets alemanes al mes. Ninguna de esas cifras viene de un prompt afortunado; vienen de un flujo de trabajo que se probó contra tickets reales antes de lanzarse.

Prueba eesel para tu flujo de trabajo de chatbot

Si has leído hasta aquí, puedes ver el trabajo que exige un flujo de trabajo de chatbot: mapear etapas, fundamentar respuestas, ajustar la confianza, diseñar el escalamiento, probarlo todo. eesel hace ese trabajo por ti. Conectas tu helpdesk y tus documentos, construye el flujo de trabajo a partir de tus tickets y conocimiento anteriores desde el primer día, configuras cuándo interviene y cómo transfiere en lenguaje sencillo, y simulas todo contra tickets históricos antes de que un solo cliente lo vea.

Se conecta con Zendesk, Freshdesk, Gorgias, Slack, Shopify, Confluence y más de 100 herramientas más, funciona en más de 80 idiomas desde el primer momento, y es de pago por uso a $0,40 por ticket sin tarifa por asiento. Ese modelo tiende a salir más barato que la plantilla una vez que haces las cuentas. Puedes ver un flujo de trabajo funcionando en vivo dentro de tu helpdesk:

La forma más rápida de ver si un flujo de trabajo de chatbot encaja con tu cola es ejecutar uno contra tus propios tickets. Eso es una prueba gratuita, sin tarjeta, y la simulación te dice tu tasa de resolución real antes de que te comprometas con nada.