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 un asesor humano 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.

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 humano se da por el contenido del mensaje (el operador se presenta por nombre), no por un cambio de canal ni de número.

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 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente