US-034 — Notificación al operador

Detalle de la historia¶

Historia¶

Como operador de FleteChat, quiero recibir una notificación cuando se active un handoff con un cliente, para atenderlo rápidamente y evitar que se quede esperando sin respuesta.

Persona de usuario¶

Aplica a los operadores de FleteChat con rol operator o admin que están disponibles para atender handoffs. El grupo de operadores que recibe las notificaciones es configurable por el admin en el backoffice.

Contexto de negocio¶

Un handoff activado que no tiene quien lo atienda se convierte en una mala experiencia: el cliente espera, el agente no responde, y el silencio mata la confianza. FleteChat resuelve el problema con dos mecanismos complementarios: (a) notificación inmediata al grupo de operadores disponibles (por WhatsApp y por badge en el backoffice), y (b) primer operador que toma el handoff lo bloquea para los demás, evitando que dos operadores atiendan al mismo cliente.

La notificación incluye contexto suficiente para que el operador decida si puede atender: cliente, motivo declarado (breve), código de la operación asociada si la hay, y un enlace directo al chat de handoff en el backoffice.

Criterios de aceptación¶

Envío de la notificación¶

1. Al activarse un handoff (ver historia de transferencia a agente humano), FleteChat notifica inmediatamente a todos los operadores del grupo configurado para recibir handoffs. El grupo es configurable por el admin; si no hay configuración específica, recibe todos los operadores con rol operator y admin activos.
2. La notificación se envía por dos canales en paralelo: a. WhatsApp al operador, usando plantilla proactiva aprobada por Meta (el operador puede estar fuera de la ventana de 24 h). b. Badge y alerta visual en el backoffice al abrir la interfaz.
3. La notificación contiene: nombre del cliente, motivo declarado (breve, tomado de la descripción que el cliente dio en US-033 si existe), código de la operación asociada (cotización CNNN o embarque ENNN si el handoff tiene contexto operativo), timestamp del handoff, y un enlace directo al chat de handoff en el backoffice.

Bloqueo por "primer operador que toma"¶

1. En el backoffice, cada handoff pendiente tiene un botón "Tomar handoff". El primer operador que hace click bloquea la conversación para los demás: los otros operadores ven el handoff como "tomado por [nombre]" y no pueden tomarlo.
2. El operador que toma un handoff se convierte en el asignado de esa conversación hasta que la devuelva al agente (ver historia de devolución al agente) o se la transfiera explícitamente a otro operador.
3. Si un operador toma un handoff por error, puede liberar la conversación de vuelta a pending_handoff; otros operadores vuelven a verla disponible. La acción queda auditada.

Visibilidad para el admin¶

1. El admin ve la lista completa de handoffs pendientes y tomados con filtros por estado, operador asignado y antigüedad. Puede reasignar manualmente un handoff si el operador asignado no está disponible.
2. El admin ve métricas simples en tiempo real: handoffs pendientes, tiempo medio de espera, operador con más carga activa.

Audit log¶

1. Cada evento (handoff activado, notificación enviada, handoff tomado, liberado, reasignado) queda registrado con actor, timestamp y handoff ID.

Edge cases¶

• Handoff activado sin operadores activos en el grupo. FleteChat registra el evento y notifica al admin (por correo y badge); el cliente recibe un mensaje de espera hasta que alguien tome el handoff.
• Operador toma un handoff pero nunca responde al cliente. Un timeout configurable escalará el handoff al admin (por defecto, 15 minutos; ver PR-140), que puede reasignar a otro operador.
• Todos los operadores rechazan la notificación por WhatsApp. FleteChat insiste con el badge en el backoffice y con recordatorios periódicos hasta que alguien tome; el cliente no queda sin atención indefinidamente porque el admin lo ve en su dashboard.
• Dos operadores hacen click casi simultáneamente en "Tomar handoff". La operación es atómica: el que llegue primero gana; el otro ve el mensaje "ya lo tomó [nombre]" sin experiencia de error.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P1 — sin esta notificación el handoff funcional (US-033) se queda en un estado pending_handoff sin llegar a nadie.
• 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-139 — Grupo de operadores configurable. El grupo de operadores que recibe notificaciones de handoff es configurable por el admin. Si no hay configuración específica, recibe todos los operadores con rol operator y admin activos.
• PR-140 — Timeout de atención por operador asignado. Un operador que toma un handoff y no responde al cliente dentro de un timeout configurable (por defecto 15 minutos) escala el handoff al admin para reasignación.
• PR-141 — Bloqueo atómico al tomar. La acción de "Tomar handoff" es atómica: sólo un operador puede tomar un handoff dado. Los demás ven el estado actualizado sin experiencia de error.

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