Un agente, todos los canales
Cómo el widget web, Telegram y WhatsApp llegan al mismo agente con la misma memoria — resolución de identidad, flujo de control compartido y qué queda propio de cada canal.
Un cliente pregunta algo en su web y dos semanas después retoma la conversación desde WhatsApp. Que eso sea una relación o dos desconocidos lo decide cómo se resuelve la identidad, no la interfaz de chat.
La forma del asunto
Los canales son puertas de entrada, no compartimentos. Cada uno desemboca en las mismas tres cosas:
El agente no se duplica por canal. La recuperación, la memoria y los seguimientos cuelgan del espacio, así que llegar por otra aplicación cambia el transporte y nada más.
Resolución de identidad
Cada canal aporta un identificador externo: el id de usuario final de un token de widget, un id de usuario de Telegram, un número de WhatsApp. La resolución se hace por (tenant, external_user_id): una consulta y un alta la primera vez.
Dos detalles que conviene conocer:
- El primer contacto tiene condición de carrera, y está resuelto. Dos mensajes que llegan a la vez no encontrarían usuario y ambos intentarían crearlo. La restricción de unicidad decide, y el que pierde vuelve a leer en lugar de fallar, así que una ráfaga de primeros mensajes simultáneos produce un usuario, no un error.
- El espacio se resuelve o se crea. Todo usuario tiene un espacio por defecto; un espacio pedido explícitamente debe pertenecer a ese usuario o la petición se rechaza. Esa comprobación es lo que impide que una petición manipulada lea las conversaciones de otra persona.
Vincular a una misma persona entre canales es una decisión del inquilino, no una conjetura. La plataforma no fusiona a un visitante de la web con un número de WhatsApp porque se parezcan: esa inferencia es la manera en que los sistemas filtran el historial de un cliente a otro. Donde usted pueda identificar a la misma persona (un usuario autenticado, un enlace con un id de usuario final), pase el mismo identificador y el historial la acompañará; donde no pueda, quedarán separados.
Qué comparte el adaptador y qué no
Telegram y WhatsApp se ven distintos pero hacen el mismo trabajo. La capa de adaptador contiene todo lo que no debería divergir:
| Compartido en el adaptador | Propio de cada canal |
|---|---|
| Resolución de identidad y búsqueda del espacio | Renderizado de mensajes y llamadas de envío |
| Lectura y escritura de la sesión actual | Teclados en línea y formularios de Telegram |
| Comandos — nueva, listar, cambiar, historial, renombrar, eliminar, ubicación, ayuda | Listas y respuestas interactivas de WhatsApp |
| Reproducción y formato del historial | Manejo de adjuntos específico de cada plataforma |
| El aviso de respuesta lenta | |
| La ejecución de un turno |
La regla es que la semántica de la conversación vive en un solo sitio. Si el cambio de sesión funcionara de forma algo distinta en WhatsApp que en Telegram, esa diferencia sería invisible hasta que un cliente se topara con ella.
Una consecuencia práctica: se trata de integraciones de chat privado. En un chat privado de Telegram el id del chat y el id del remitente son el mismo, así que el destino del envío y la clave de identidad colapsan en un único valor, y por eso el adaptador puede tratar «quién es esta persona» y «dónde respondo» como un solo concepto.
Respuestas que tardan
Algunas respuestas no pueden producirse dentro del turno. El agente puede programar el trabajo y dejar que la respuesta llegue después, empujada al canal por el que vino la petición: una burbuja en el widget web, un mensaje en Telegram o en WhatsApp. Vea Seguimientos programados.
Qué significa esto en la práctica
- Un cliente, un historial, escriba desde donde escriba.
- Añadir un canal no bifurca la lógica de la conversación.
- La recuperación y la memoria se comportan igual en todas partes, porque están ancladas al espacio y no al canal.
La puesta en marcha de los canales se explica en Telegram y WhatsApp y en Integrar el widget web.