Eventos de los chats y ciclo de vida del diálogo

Copiar enlace al artículo

Copiado

Contenido

1. Chat, diálogo y canal
2. Cómo el agente «escucha» el chat
3. Eventos a los que reacciona el agente
4. Responsable del diálogo: quién lleva la conversación ahora
5. Cuándo se arranca el agente
6. Qué ocurre en los eventos clave
7. Cómo cancelar el arranque automático del agente
8. Arranque del agente cuando el diálogo no está en el bot
9. Comando del asesor para arrancar el agente
10. Protección contra bucles
11. Selección del agente para el evento

El agente no funciona por sí solo. Reacciona a lo que ocurre en el chat con el cliente: a un mensaje nuevo, a la asignación de un diálogo, a su cierre. Esta sección describe de qué se compone un chat, qué eventos surgen en él y cómo llevan al arranque del agente. Entender esta capa explica por qué en unas situaciones el agente le responde al cliente y en otras se mantiene al margen.

Chat, diálogo y canal

Antes de hablar de los eventos, conviene distinguir tres conceptos con los que trabaja el sistema de chats.

El canal es la fuente de la conversación: WhatsApp, Telegram, el consultor en línea del sitio web, Instagram y otros. El agente se configura para trabajar en canales concretos, y es por el canal que el sistema decide qué agente debe atender la conversación.

El chat es la conversación con un cliente concreto en un canal concreto. Una misma persona que te escribe por WhatsApp y por Telegram está representada en el sistema mediante dos chats distintos.

El diálogo es una solicitud individual dentro del chat. Tiene un estado (abierto o cerrado) y un responsable: quien lleva la conversación en ese momento, el asesor o el bot. A lo largo de su historia, un mismo chat puede contener muchos diálogos: el cliente hace una consulta, se resuelve, el diálogo se cierra; más tarde el cliente vuelve a escribir y se abre un diálogo nuevo.

Dentro del servicio, a estos conceptos les corresponden «Cliente» y «Conversación» de la sección «Conceptos y términos». En resumen: cada chat del cliente en un canal es un «cliente» aparte en el sistema, y todo el historial de comunicación con él que ve el agente se guarda en su «conversación» activa. El agente siempre trabaja con una única conversación activa.

Cómo el agente «escucha» el chat

El trabajo del agente en el chat se realiza a través de un bot conectado a los chats mediante la MG Bot API por una conexión permanente (WebSocket). Por esa conexión, el bot recibe un flujo de eventos sobre todo lo que ocurre en los chats de la cuenta.

El servicio no reacciona a todo el flujo, sino solo a un conjunto limitado de eventos que de verdad influyen en el trabajo del agente: los mensajes nuevos en el chat, las asignaciones y los cierres de diálogos. Todo lo demás se ignora.

El formato externo de los eventos se describe en la documentación de la MG Bot API.

Eventos a los que reacciona el agente

El evento más frecuente es un «mensaje nuevo» en el chat. Pero los mensajes son de distinto tipo, por eso el sistema primero determina de quién y de qué tipo llegó el mensaje, y solo entonces decide qué hacer con él. Así, un único evento técnico se convierte en uno de varios eventos con sentido:

Los mensajes propios del bot bajo el que funciona el agente se filtran de inmediato: el agente no reacciona a lo que él mismo envió.

Responsable del diálogo: quién lleva la conversación ahora

Es la idea clave de toda la sección. Cada diálogo tiene en todo momento un responsable, y de él depende si el agente puede responder al cliente. Hay tres estados posibles:

• diálogo en el bot: el responsable es nuestro bot; el agente tiene derecho a responder al cliente;
• diálogo en el asesor: el responsable es un empleado (u otro bot); el agente no interviene en la conversación;
• diálogo sin nadie: no hay responsable asignado.

Es una barrera de seguridad. Mientras el diálogo lo lleva un asesor, el agente no le escribirá al cliente, aunque reciba todos sus mensajes. El agente responde solo cuando el diálogo pertenece al bot. Aun así, puede ejecutar tareas en segundo plano (por ejemplo, analizar la conversación y asignar etiquetas), pero eso ya son acciones aparte, no respuestas al cliente.

Es el comportamiento por defecto y se puede configurar: el escenario puede arrancar al agente incluso en un diálogo ajeno, para trabajar en segundo plano o para tomar el diálogo (ver «Arranque del agente cuando el diálogo no está en el bot»).

Si llega un evento al chat mientras el agente ya está trabajando en esa misma conversación, el nuevo arranque interrumpe al anterior. Así el sistema evita que un mismo agente lleve en paralelo dos veces la misma conversación.

Cuándo se arranca el agente

El arranque del agente no es una reacción automática a cualquier evento. Por defecto, solo dos eventos lo activan, y solo si el diálogo está asignado al bot:

• la asignación del diálogo al bot: es el arranque «inicial» típico, cuando las reglas de distribución o el asesor transfieren el diálogo al agente;
• el mensaje del cliente: el cliente escribió y espera respuesta.

El resto de los eventos, por sí mismos, no arrancan al agente. Si quieres que el agente se active ante uno de ellos —por ejemplo, ante un mensaje del asesor o una acción diferida—, para eso se configuran los pasos activados por eventos. A diferencia de los pasos normales, con los que trabaja el propio agente, estos pasos los arranca el sistema cuando ocurre el evento correspondiente.

Aquí hay una diferencia importante entre los dos tipos de pasos. Un paso con el que trabaja el agente, tras ejecutarse, por defecto puede devolverle de nuevo el trabajo al agente. En cambio, un paso activado por evento no despierta al agente por sí mismo: solo ejecuta las acciones definidas en él y termina. Para que, ante un evento, el agente realmente se active —por ejemplo, le escriba al cliente—, dentro de ese paso hay que añadir explícitamente la acción «Llamar al agente de IA» (o «Ir a otro paso», con transición a un paso gestionado por el agente).

Por eventos se activan todos los pasos salvo los que elige el propio agente: la reacción a una señal, los pasos ante un mensaje del cliente o del asesor, ante la asignación y el cierre del diálogo, ante una acción diferida. Lo que importa no es qué acciones están configuradas dentro de ese paso, sino cuáles de ellas se ejecutaron realmente teniendo en cuenta las condiciones y la disponibilidad.

Esta separación está presente ya en la propia creación del paso: en el editor del escenario, para los dos tipos de pasos hay botones distintos: uno añade un paso con el que trabaja el agente, y el otro, un paso activado por evento.

Qué ocurre en los eventos clave

Mensaje del cliente. El mensaje se guarda en el historial de la conversación. Los recordatorios de espera de respuesta programados antes se cancelan: el cliente respondió, ya no hace falta recordarle nada. Si el diálogo está en el bot, se arranca al agente.

Asignación del diálogo. Si el diálogo se asignó al bot, el agente toma la conversación y empieza a trabajar: normalmente es aquí donde se saluda al cliente y se entra en el escenario. Si el diálogo se asignó a otra persona (por ejemplo, a un asesor), el agente, por el contrario, se detiene y deja de intervenir en la conversación. Y si la asignación se produjo por una acción del propio agente según el escenario, el evento se ignora para no arrancar el trabajo de nuevo (ver «Protección contra bucles»).

Cierre del diálogo. Por defecto, el agente reinicia el contexto del escenario acumulado durante el diálogo —las señales, las tareas del dashboard, la visibilidad de los pasos— para que la siguiente solicitud del mismo cliente empiece desde cero. Este comportamiento es configurable, y qué se reinicia exactamente y qué sobrevive al cierre se explica en detalle en la sección «Qué se acumula en el contexto y cuándo se reinicia». Además, para el cierre se puede configurar un paso propio activado por este evento.

Mensaje del asesor. El agente, por defecto, no responde. La intervención del empleado se guarda en el historial de la conversación como un mensaje del asistente, igual que las propias respuestas del agente. Esto se hace a propósito: para el agente, los mensajes del asesor y los suyos propios son indistinguibles y se perciben como intervenciones de una misma parte. Así, el agente ve lo que ya se le dijo al cliente, tiene en cuenta las palabras del asesor como parte de la respuesta común y no las duplica. Si es necesario, para el mensaje del asesor se puede configurar un paso activado por este evento, para acciones en segundo plano.

Acción diferida. Arranque interno de un paso concreto del escenario mediante temporizador tras un tiempo definido. El mecanismo se describe en detalle en la sección «Acciones diferidas».

Cómo cancelar el arranque automático del agente

El arranque automático del agente ante un mensaje del cliente y ante la asignación del diálogo es el comportamiento por defecto, y se puede redefinir. Esto hace falta cuando, ante un evento, debe ejecutarse un conjunto fijo de acciones sin arrancar al agente.

El mecanismo se apoya en el orden de procesamiento: los pasos configurados para un mensaje del cliente o para la asignación del diálogo, el sistema los procesa antes de que se dispare el arranque del agente por defecto. El propio arranque automático es, en esencia, una ruta de respaldo: se activa solo si ningún paso de ese tipo tomó el control. Y esa toma de control se apoya en la propiedad de los pasos por evento ya descrita: un paso así no despierta al agente por sí mismo. Por eso, si a un evento «de arranque» (un mensaje del cliente o la asignación del diálogo) le asignas un paso que se ejecute pero no invoque la acción «Llamar al agente de IA», el arranque automático del agente ante ese evento se cancela: ese paso toma el control y simplemente hace su trabajo.

La acción «Llamar al agente de IA» en sí solo está disponible en los pasos activados por eventos. En los pasos con los que trabaja el agente no está, porque ahí no hace falta: ese paso, por defecto, ya puede continuar el trabajo del agente.

Una advertencia importante: el paso debe ejecutarse realmente. Si sus condiciones no se cumplen en ese momento y el paso queda filtrado, el sistema considera que no hubo toma de control y se dispara el arranque automático normal del agente.

Para desactivar por completo el arranque automático del agente en un canal, hacen falta dos pasos de este tipo:

• un paso para el evento de mensaje del cliente, sin la acción «Llamar al agente de IA»;
• un paso para el evento de asignación del diálogo, sin la acción «Llamar al agente de IA».

Juntos toman el control de los dos eventos que, de otro modo, arrancarían al agente.

Para qué sirve. Así, en el chat se puede construir un comportamiento útil sin arrancar al agente ni una sola vez, es decir, sin costo: el cobro se aplica por el trabajo del agente, mientras que la ejecución de un conjunto simple de acciones en pasos activados por eventos es gratuita.

Un ejemplo típico es atender el horario no laboral con un agente aparte. Este agente está configurado para trabajar solo fuera del horario laboral y no debe llevar el diálogo por sí mismo. En lugar de arrancar al agente ante un mensaje del cliente, este:

1. le envía al cliente un aviso breve de que ahora es horario no laboral;
2. programa una acción diferida para el inicio del horario laboral, pero ya para otro agente, configurado para el horario laboral.

Cuando llega el horario laboral, la acción diferida arranca al agente de horario laboral, y este continúa la conversación con el cliente. Toda la interacción fuera de horario, así, transcurre sin arrancar al agente y sin costo. Las acciones en sí pueden ser cualesquiera; la idea es que se ejecutan mediante un conjunto fijo de pasos, sin recurrir al agente.

Arranque del agente cuando el diálogo no está en el bot

La regla «el agente responde solo cuando el diálogo está en el bot» es el comportamiento por defecto, pero se puede redefinir de forma consciente. La acción «Llamar al agente de IA» tiene un ajuste de modo de arranque que determina qué ocurre si, en el momento en que se activa el paso, el diálogo no lo lleva el bot, sino un asesor u otro bot.

Hay tres modos, de pasivo a activo:

• Responsable asignado (por defecto). El agente trabaja solo cuando es el responsable del diálogo. Si el diálogo lo lleva un asesor u otro bot, el agente no se arranca: el paso simplemente no lo despierta. Las demás acciones del paso, aun así, se ejecutan (actualizar el estado, retirar recordatorios, asignar una etiqueta). Esto conserva el comportamiento anterior: en un diálogo ajeno, el agente calla.
• Trabajo en segundo plano. El agente se arranca aunque no sea el responsable del diálogo. No puede tomar el diálogo —el responsable sigue siendo un asesor u otro bot—, pero sí puede escribirle al cliente y ejecutar acciones. Sirve para la preparación: clasificar la solicitud, asignar etiquetas, buscar materiales en la base de conocimientos, actualizar el estado. El agente ejecuta un solo arranque: los eventos posteriores no lo despertarán por sí mismos hasta que los procese un paso con arranque forzado del agente.
• Toma del diálogo. El agente toma el diálogo (lo reasigna al bot) y sigue trabajando como de costumbre, incluso responde al cliente. Es una acción visible para el asesor y una decisión de nivel de negocio: se usa para una toma de control explícita —escalada por un disparador, traspaso del diálogo al bot cuando el asesor no está disponible, o un tramo del escenario que debe llevar precisamente el agente—. Si no se logra tomar el diálogo, el agente no se arranca y el paso se marca como erróneo.

El modo se elige directamente en la acción «Llamar al agente de IA», por eso, en un mismo paso, mediante condiciones se pueden combinar distintos modos: por ejemplo, ante una reclamación sin resolver, tomar el diálogo, y en los demás casos, limitarse al análisis en segundo plano.

Comando del asesor para arrancar el agente

El asesor puede conectar al agente a la conversación manualmente desde el propio chat, con el comando de servicio /agent. Se envía como un mensaje privado y no es visible para el cliente.

Es una posibilidad importante, porque a través de la interfaz del sistema no se puede asignar manualmente un diálogo a un agente por ahora. El comando /agent es la única forma de que el asesor transfiera un diálogo concreto al bot: asigna el diálogo al agente configurado para el canal de ese chat y lo arranca. Resulta cómodo cuando el asesor quiere que el agente retome una conversación que antes llevaba una persona. Si en ese momento el diálogo estaba en el asesor, el bot primero se lo asigna a sí mismo y luego se arranca.

El comando tiene dos modos:

• Solo transferir el diálogo al agente: /agent sin parámetros. El agente toma la conversación y decide por sí mismo qué hacer a continuación, a partir de la conversación y de los pasos del escenario disponibles.
• Transferir el diálogo y asignar una tarea de inmediato: /agent NombreDelPaso, opcionalmente con una instrucción adicional: /agent NombreDelPaso texto de la instrucción. Entonces el agente se arranca directamente desde la ejecución del paso del escenario indicado, y la instrucción se añade como una precisión a la tarea. El paso objetivo, además, debe estar configurado para el evento «Comando del asesor». El nombre exacto del paso para el comando se puede copiar desde la ficha de ese paso en la interfaz.

Protección contra bucles

Parte de las acciones del agente modifican el propio diálogo. Si un paso del escenario asigna el diálogo a alguien o lo cierra (mediante la acción de cierre del diálogo correspondiente), el sistema externo le enviará al bot un evento sobre ese cambio: una asignación o un cierre. Sin protección, esto provocaría un bucle: la acción del agente genera un evento, el evento vuelve a arrancar al agente, y así en círculo.

Para que esto no ocurra, el servicio marca los cambios provocados por las acciones del propio agente y reconoce los eventos que llegan por ellos. La asignación del diálogo hecha por el propio agente simplemente se omite. Con el cierre es más sutil: la limpieza del contexto el servicio la realiza de la forma habitual —un cierre propio no la cancela—, pero los pasos configurados para el cierre del diálogo no se activan en ese tipo de cierre.

Selección del agente para el evento

Cuando un evento está listo para procesarse, el servicio selecciona el agente que debe ocuparse de él. La lógica de selección es simple:

1. se determina el canal del que llegó la conversación;
2. entre los agentes activos de la cuenta se busca el que esté configurado para ese canal;
3. se comprueba el horario de trabajo actual del CRM y el modo de trabajo del agente (siempre, solo en horario laboral o solo fuera de él);
4. se toma el primer agente adecuado.

Si el diálogo está asignado al bot pero ahora no hay un agente adecuado (por ejemplo, nadie está configurado para ese horario), el servicio retira al bot del diálogo para que la conversación no quede «colgada» sin responsable y un asesor pueda retomarla.