US-058 — Solicitar humano a demanda
Detalle de la historia¶
Historia¶
Como cliente de FleteChat, quiero poder pedir hablar con un asesor en cualquier momento de la conversación, aun cuando el agente no haya detectado un problema, para resolver cosas que prefiero discutir directamente con alguien.
Persona de usuario¶
Aplica a todo cliente (nuevo o reconocido, verificado o en proceso de registro) que explicita su deseo de hablar con un asesor.
Contexto de negocio¶
El handoff existente en US-033 cubre dos caminos: el agente detecta que debe transferir, o el motor retorna "combinación no soportada". Esta historia formaliza un tercer disparador explícito: el cliente lo pide sin que el agente ni el motor lo necesiten. Frases del cliente como "quiero hablar con una persona", "pásame con un humano", "necesito un asesor" deben resolverse inmediatamente: el cliente tiene derecho a elegir con quién conversa.
Esta historia no introduce un flujo nuevo de handoff distinto al de US-033: usa el mismo mecanismo (consentimiento, activación, notificación al operador, chat en backoffice, devolución). La diferencia está en el disparador: aquí es el cliente quien lo inicia con intención explícita. El consentimiento que pide el agente en US-033 (Camino 2) no aplica aquí: el cliente ya está dando consentimiento al pedirlo.
Diálogo de referencia¶
Cliente pide un asesor directamente¶
Cliente: Quiero hablar con una persona.
Agente: Con gusto, le paso con uno de nuestros asesores. ¿Me cuenta brevemente de qué se trata, así le anticipo al asesor?
Cliente: Tengo una consulta sobre tarifas que me gustaría discutir.
Agente: Anotado. Un momento por favor, le paso con uno de nuestros asesores. Le sigo escribiendo por aquí mismo cuando se conecte.
Cliente pide un asesor en medio de un flujo¶
Agente: ¿Cuál es el peso estimado del envío?
Cliente: Mejor páseme con un asesor.
Agente: Con gusto. Pauso la cotización que estábamos armando y le paso con un asesor. ¿Me cuenta algo más para anticiparle el contexto?
Criterios de aceptación¶
Detección¶
- FleteChat detecta la intención del cliente de pedir un asesor ante expresiones como "quiero hablar con una persona", "pásame con un humano", "necesito un asesor", "un operador", "una persona", "alguien de FleteChat", y variantes naturales equivalentes. Las expresiones base son configurables (ver PR-199).
- La detección funciona en cualquier punto de la conversación, incluso en medio de un flujo crítico (cotización, aprobación, consulta de estatus).
Activación del handoff¶
- Ante la intención detectada, FleteChat activa el handoff según la mecánica de US-033 (estado
pending_handoff, notificación al operador, chat en backoffice, notificación al cliente, devolución posterior). No se requiere pregunta adicional de consentimiento porque el cliente ya lo está pidiendo activamente. - Antes de activar el handoff, el agente pide una breve descripción del motivo si el cliente no la dio en el mensaje inicial, para pasarla al asesor (mantiene el patrón de US-033 AC 2).
- Si el cliente pide un asesor en medio de un flujo activo (cotización, por ejemplo), el agente pausa el flujo y avisa al cliente que se retomará cuando el asesor lo devuelva al agente (o el cliente decida continuar).
Caso "no hay asesores disponibles"¶
- Si no hay operadores activos en el grupo que atiende handoffs (ver US-034 edge cases), FleteChat activa igualmente
pending_handoff, notifica al admin y le informa al cliente que puede haber una demora; no lo rechaza.
Edge cases¶
- Cliente pide un asesor con tono ambiguo (por ejemplo, "esto es imposible, no sé qué hacer"). El agente pregunta explícitamente si desea hablar con un asesor antes de activar handoff.
- Cliente pide un asesor repetidamente en una misma sesión ya en handoff (ya fue transferido y el operador está atendiendo). El agente no aplica, porque ya está en
human_handling; el mensaje queda en el chat del operador como cualquier otro. - Cliente pide un asesor y, en el siguiente mensaje, dice "olvídalo, sigo con el asistente". El agente confirma si desea cancelar el handoff pendiente; si el cliente confirma, FleteChat cancela
pending_handoffy vuelve a estadoai_handling(ver US-033 edge cases). - Cliente pide un asesor fuera del horario operativo definido por FleteChat. v1.0 no define horario operativo formal; la alerta se envía igual y el admin lo ve por la mañana si aplica (ver US-034 edge case).
Tamaño, prioridad y tipo¶
- Tamaño: S
- Prioridad: P1 — derecho del cliente a elegir; su ausencia deja al cliente atrapado con el agente.
- 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-199 — Expresiones para pedir un asesor configurables. El conjunto de expresiones que FleteChat interpreta como "pedir un asesor" es configurable por FleteChat desde parámetros globales (ver US-046). El motor conversacional detecta también variantes naturales equivalentes sin lista explícita.
Refinamiento y Definition of Ready¶
Notas¶
| Fecha | Participantes | Acuerdo / Nota |
|---|---|---|
| 2026-04-19 | Kaeus | Versión inicial. |
| 2026-04-20 | Kaeus | Aprobación interna: pase a 🔵 Refinada. |
| 2026-05-27 | Kaeus | v2.0 (sweep PR-245) — Aplicación de PR-245 (definida en US-035 y reforzada en US-053): "humano" se reemplaza por "asesor" en la historia (Como/Quiero/Para), persona de usuario, encabezados de los diálogos de referencia, líneas habladas del agente (de "asesor humano" a "uno de nuestros asesores"), AC 1, edge cases y PR-199. Se mantiene "humano" únicamente en las frases del cliente citadas como ejemplos de detección (lista configurable de PR-199 / AC 1) y en el contexto donde la palabra forma parte literal del lenguaje natural del cliente. Filename y title de la historia se mantienen por ser identificadores externos referenciados desde el backlog. |
| 2026-05-27 | Kaeus | Audit cross-historia (consistency-audit-v2.0.md): verificación de alineación con PR-241 (ventana de bloqueo de re-handoff post-toma del operador, definida en US-033) y PR-242 (umbrales de handoff + aviso al 80 %, definida en US-036). US-058 gobierna sólo el disparador inicial del handoff por petición explícita del cliente; la mecánica completa (incluidas las ventanas y umbrales) se delega íntegramente a US-033 vía AC 3. La toma del operador, el bloqueo de re-handoff posterior y los umbrales de duración son eventos posteriores al disparo y viven en sus historias dueñas. Conclusión del audit: sin conflicto, sin cambios en AC ni premisas. |
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
- ⬜ Premisa PR-199 confirmada por el cliente
- ⬜ Reglas de negocio aplicables aprobadas
- ⬜ Requerimientos funcionales aplicables aprobados
- ⬜ Historia aprobada formalmente por el cliente