US-035 — Chat de handoff en tiempo real

Detalle de la historia¶

Historia¶

Como operador de FleteChat que tomó un handoff, quiero atender al cliente desde un chat en el backoffice con historial completo y mensajes en tiempo real, para dar continuidad a la conversación sin pedirle al cliente que repita lo ya conversado.

Persona de usuario¶

Aplica al operador de FleteChat (operator o admin) que tomó un handoff pendiente. No aplica al cliente final (sigue conversando desde su WhatsApp sin cambio) ni a otros operadores no asignados al handoff.

Contexto de negocio¶

Una vez tomado el handoff, el operador necesita dos cosas para atender bien: ver el contexto completo de lo que pasó antes (toda la conversación, lo que dijo el cliente, cómo respondió el agente) y escribir mensajes al cliente en tiempo real a través del mismo WhatsApp por el que el cliente inició la conversación.

El chat del backoffice entrega ambas cosas: muestra el historial cronológico con indicador claro de quién dijo qué (cliente / agente / operador), escribe vía el canal de WhatsApp del cliente de forma bidireccional, y actualiza en vivo cuando el cliente responde (sin refrescar la página). Sólo el operador asignado al handoff puede escribir; los demás pueden ver el chat (si tienen permiso) pero no intervenir.

Diálogo de referencia¶

Vista del operador al abrir el chat¶

(El operador abre el chat del handoff en el backoffice. Ve la conversación completa:)

Agente (10/04 09:12): Con gusto le ayudo. ¿Me cuenta de qué se trata?

Cliente, María Pérez (10/04 09:13): Tengo un problema con la factura del envío pasado. Me cobraron distinto.

Agente (10/04 09:13): Entiendo. Le paso con uno de nuestros asesores que puede revisar su caso. Un momento por favor.

Sistema (10/04 09:14): Handoff activado. Motivo: problema con la factura del envío pasado.

(El operador tomó el handoff hace 30 segundos. Escribe:)

Operador, Juan Rodríguez (10/04 09:15): Hola, María, soy Juan de FleteChat. Me paso su caso ahora mismo. ¿Me confirma el número del embarque para que lo busque?

Cliente (10/04 09:15): Es el E42.

Criterios de aceptación¶

Vista de historial¶

1. El chat del backoffice muestra toda la conversación con el cliente en orden cronológico, desde el primer mensaje (aun antes del handoff) hasta el más reciente.
2. Cada mensaje tiene indicador visual claro del autor: agente automático, cliente (con nombre y foto si están disponibles), operador (con nombre). Eventos de sistema (activación del handoff, cambio de operador, devolución al agente) se muestran como líneas destacadas con icono y timestamp.
3. El chat muestra adjuntos (imágenes, PDFs, audios) recibidos y enviados, con miniatura y opción de abrir en otra pestaña.

Envío y recepción en tiempo real¶

1. El operador escribe en un campo de texto y, al enviar, el mensaje se envía inmediatamente por WhatsApp al cliente a través del canal del sistema. El operador ve confirmación de envío y, cuando aplica, de entrega/lectura (según soporte del canal).
2. Los mensajes nuevos del cliente aparecen en el chat sin refrescar la página (canal de actualización en tiempo real; por ejemplo, WebSocket). El operador recibe también una alerta visual y sonora al llegar un mensaje nuevo.
3. El indicador de "cliente escribiendo" aparece cuando el canal lo provee; es opcional.

Exclusividad del operador asignado¶

1. Sólo el operador asignado al handoff puede escribir en el chat. Otros operadores (con permiso de visualización) pueden leer pero no responder; si intentan escribir, la UI lo impide con un mensaje de "handoff asignado a [nombre]".
2. El admin puede reasignar el handoff a otro operador (ver historia de notificación al operador); tras la reasignación, el nuevo operador toma el control del chat.

Adjuntos y mensajes salientes¶

1. El operador puede enviar adjuntos (imágenes, PDFs, documentos) desde el chat; se reenvían al cliente por WhatsApp.
2. El operador puede copiar un mensaje para reusarlo o compartirlo con otro operador internamente. Los mensajes copiados sólo salen del chat si el operador los envía explícitamente al cliente desde el campo de envío.

Navegación lateral: cotizador y matriz de precios¶

1. La vista del chat de handoff incluye una zona lateral (panel lateral, drawer o split-screen, según diseño de UI) con dos herramientas accesibles sin abandonar el chat:
2. Cotizador manual del asesor para construir cotizaciones para casos que no resolvió el motor automático (ver US-033 AC 11). Toda cotización manual creada desde aquí queda vinculada a la conversación y sigue el mismo flujo posterior que las automáticas (vigencia, aprobación, instructivos).
3. Matriz de precios vigente, consultable para responder dudas del cliente sin alternar pestañas.

Léxico al cliente¶

1. Los mensajes que FleteChat envía al cliente desde el flujo de handoff (mensaje de espera durante pending_handoff, mensaje de saludo del operador, mensaje de devolución al agente) evitan la palabra "humano". Usar "uno de nuestros asesores", "Carlos del equipo FleteChat", "un asesor de FleteChat" u opciones equivalentes. La regla aplica también al prompt del agente conversacional (US-053) que decide derivar.

Edge cases¶

• El cliente envía un mensaje mientras el operador está escribiendo. El mensaje entrante se inserta arriba del campo de texto del operador sin interrumpir lo que está escribiendo.
• El cliente abandona la conversación por horas o días sin responder. El chat queda abierto en el backoffice con el último mensaje visible; el operador decide cuándo dar seguimiento o devolver al agente.
• Caída del servicio de tiempo real (WebSocket cae). La UI lo declara visualmente ("conexión perdida, reintentando") y recupera la conexión automáticamente; cuando vuelve, sincroniza mensajes pendientes.
• El cliente envía un mensaje muy largo o con formato no renderizable. La UI lo trunca con "ver completo" y, al abrir, muestra el mensaje original sin cambios.
• Cliente comparte un número o información sensible (por ejemplo, dato de tarjeta). El operador no comparte esa información por otros canales; queda registrada en el chat para efectos del caso. FleteChat puede alertar al operador visualmente si detecta patrones sensibles, sin bloquear el envío.

Tamaño, prioridad y tipo¶

• Tamaño: L
• Prioridad: P1 — es el corazón del handoff una vez activado; sin chat en tiempo real el handoff se vuelve intercambio de correos.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-142 — Exclusividad del operador asignado. Sólo el operador asignado al handoff puede escribir en el chat. Otros operadores con permiso pueden leer; admins pueden reasignar.
• PR-143 — Actualización en tiempo real. El chat se actualiza sin refresco manual a medida que llegan mensajes del cliente. La UI declara visualmente cuando la conexión en tiempo real se pierde y cuando se restablece.
• PR-144 — Continuidad del canal para el cliente. El cliente no percibe el cambio de interlocutor a nivel de canal: sigue conversando en el mismo WhatsApp. La identificación del operador se da por el contenido del mensaje (el operador se presenta por nombre), no por un cambio de canal ni de número.
• PR-245 — Léxico: evitar "humano" en mensajes al cliente. Los mensajes del agente y de los operadores hacia el cliente final evitan la palabra "humano". Usar "asesor", "uno de nuestros asesores", "un asesor del equipo FleteChat" o equivalentes. La regla cubre los textos parametrizables del agente, el prompt del LLM y las plantillas Meta. Excepciones temporales (literales que ya están en plantillas Meta aprobadas) se documentan caso por caso hasta su próxima revisión.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-142 a PR-144 y PR-245 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente