US-033 — Transferencia a agente humano

Detalle de la historia¶

Historia¶

Como cliente de FleteChat cuya necesidad no puede resolver el agente automático, quiero ser transferido a un operador humano con consentimiento explícito, para resolver casos complejos sin quedar atrapado conversando con el bot.

Persona de usuario¶

Aplica a todo cliente (verificado o en proceso de registro) en cualquier punto de una conversación con el agente. Aplica también indirectamente al operador de FleteChat que recibe la transferencia (ver historia de notificación al operador).

Contexto de negocio¶

Un agente conversacional bien diseñado resuelve la gran mayoría de los casos por sí solo. Pero inevitablemente hay situaciones en las que el cliente necesita hablar con una persona: una combinación que el motor no soporta, una reclamación compleja, una negociación comercial, una duda que el agente no puede responder con certeza. Negarse a transferir es mala experiencia; transferir sin avisar al cliente también.

El handoff de FleteChat tiene dos caminos: (1) el agente decide, por el contexto de la conversación, que debe transferir (por ejemplo, el cliente pide "hablar con alguien" o describe un problema que excede sus capacidades); (2) el motor de cotización devuelve una "combinación no soportada". En ambos casos —y esto refina el SOW original que preveía transferencia automática— el agente explica al cliente por qué sería mejor transferir y le pide consentimiento explícito antes de ejecutar el handoff. Ante "sí", activa el handoff; ante "no", ofrece alternativas.

Diálogo de referencia¶

Cliente pide explícitamente hablar con un humano¶

Cliente: Quisiera hablar con una persona.

Agente: Con gusto, le paso con un asesor humano. ¿Me cuenta brevemente de qué se trata, así le anticipo al asesor de qué hablan?

Cliente: Tengo un problema con la factura del envío pasado.

Agente: Anotado. Un momento por favor, le paso con uno de nuestros asesores. Le sigo escribiendo por aquí mismo cuando se conecte.

Motor devuelve "combinación no soportada"¶

Cliente: Necesito cotizar un envío aéreo de mercancía peligrosa a Caracas.

Agente: Esa combinación (mercancía peligrosa a Caracas por aéreo) no la tengo disponible en mi catálogo de servicios. Un asesor humano podría revisar si es algo que podamos gestionar de forma especial. ¿Quiere que le pase con un asesor?

Cliente: Sí, por favor.

Agente: Perfecto. Un momento, le paso con un asesor. Le sigo escribiendo por aquí mismo cuando se conecte.

Cliente rechaza el handoff ofrecido¶

Cliente: Necesito cotizar un envío aéreo de mercancía peligrosa a Caracas.

Agente: Esa combinación no la tengo disponible en mi catálogo. ¿Quiere que le pase con un asesor humano para revisar opciones?

Cliente: Mejor no. Dime qué opciones tienes a Caracas.

Agente: Claro. A Caracas tengo marítimo LCL, marítimo FCL y aéreo para carga general. ¿Cuál le sirve explorar?

Criterios de aceptación¶

Camino 1 — Criterio del agente¶

1. El agente detecta que debe transferir a partir de señales en la conversación: el cliente pide explícitamente hablar con una persona, el cliente expresa frustración sostenida, o el contexto describe un caso que excede las capacidades del agente.
2. En ese caso, el agente anticipa al cliente que lo va a transferir, pide una breve descripción del motivo (para pasarla al asesor) y confirma antes de ejecutar.

Camino 2 — Combinación no soportada¶

1. Cuando el motor de cotización o consulta retorna "combinación no soportada" (por ejemplo, una ruta + modalidad + Incoterm que no existe, o un servicio que el sistema no ofrece), el agente (a) valida con el modelo que efectivamente es una combinación no cubierta y no un error de interpretación, (b) explica al cliente la situación en términos entendibles, (c) pregunta "¿quiere que lo pase con un asesor?" y (d) activa el handoff sólo ante el "sí" explícito del cliente.
2. Si el cliente dice "no" al handoff ofrecido, el agente ofrece reformular la solicitud o explorar opciones alternativas soportadas.

Activación del handoff¶

1. Al activar el handoff (por cualquiera de los dos caminos), la conversación pasa a estado pending_handoff en el sistema. Desde ese momento y hasta que un operador tome la conversación, el agente no responde mensajes nuevos del cliente automáticamente.
2. Mientras la conversación esté en pending_handoff, FleteChat muestra al cliente un mensaje de estado ("un asesor lo va a atender en un momento") si el cliente escribe.
3. El handoff queda registrado en el audit log con: motivo declarado (camino 1 o 2), descripción del cliente si la dio, timestamp, identidad del agente en ese momento.

Mensaje transparente al cliente¶

1. El agente siempre le avisa al cliente cuando inicia el handoff (no se hace en silencio) y le indica que la conversación sigue por el mismo WhatsApp una vez conectado el asesor.
2. Cada vez que el control regresa al agente (por cualquier causa: el operador resuelve el caso, el operador cierra por falta de respuesta del cliente, o el sistema cierra por desconexión del operador) FleteChat notifica proactivamente al cliente que la sesión con el asesor se cerró y que el agente retoma la atención, indicando que el cliente puede continuar escribiendo cuando lo desee. Si la ventana de 24 h de WhatsApp está cerrada al momento de la devolución, la notificación se envía por plantilla Meta aprobada (ver PR-150). La mecánica detallada de las distintas causas de devolución vive en la historia de devolución al agente.

Edge cases¶

• Cliente pide hablar con un humano fuera del horario de atención (en v1.0 no hay horario formal configurado, pero puede aparecer). El agente transfiere igual a pending_handoff y explica al cliente que puede haber una demora en la respuesta.
• Cliente inicia handoff, abandona la conversación, y vuelve horas después. El estado pending_handoff persiste; el operador que eventualmente toma la conversación ve el historial completo y decide cómo retomar.
• Cliente quiere cancelar el handoff antes de que lo atienda un operador. El agente acepta la cancelación con consentimiento explícito y la conversación vuelve a estado ai_handling; el evento queda auditado.
• El agente identifica que debería transferir pero el cliente insiste en dialogar con el bot. El agente respeta la voluntad del cliente, registra el evento, y continúa intentando ayudar dentro de sus capacidades.
• Dos motores distintos retornan "combinación no soportada" durante la misma sesión. El agente no dispara handoffs duplicados; consolida en un único ofrecimiento al cliente.
• Cliente no responde tras activar el handoff (ni siquiera mientras el operador intenta atenderlo, o deja de responder a mitad de la atención). El operador puede cerrar el handoff y devolver la conversación al agente desde el backoffice. El agente notifica al cliente (ver AC 9 y PR-150) que la sesión con el asesor terminó y queda a disposición para cuando el cliente vuelva a escribir. La mecánica del cierre (acción manual del operador, devolución automática por desconexión prolongada del operador, uso de plantilla Meta si la ventana de 24 h está cerrada) se desarrolla en la historia de devolución al agente.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P1 — sin handoff el agente se convierte en un callejón sin salida para casos no triviales.
• 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-136 — Consentimiento explícito antes del handoff. Ante cualquier situación que justifique transferir (criterio del agente o combinación no soportada), FleteChat avisa al cliente y pide confirmación explícita antes de ejecutar el handoff. Un "sí" ambiguo no activa handoff; el agente vuelve a preguntar. (Refinamiento sobre SOW §2.2, que originalmente preveía transferencia automática.)
• PR-137 — Estado pending_handoff detiene respuestas del agente. Mientras la conversación está en pending_handoff, el agente no responde mensajes nuevos del cliente. FleteChat muestra al cliente un mensaje de estado si escribe antes de que el operador tome la conversación.
• PR-138 — Audit log del handoff. Cada handoff (solicitado, confirmado, cancelado por el cliente, tomado por operador) queda registrado en el audit log con timestamp, actor e identificadores relevantes.
• PR-150 — Notificación obligatoria en toda devolución al agente. Siempre que el control regresa del operador al agente —sea por resolución del caso, cierre por falta de respuesta del cliente o cierre automático por desconexión del operador— FleteChat notifica proactivamente al cliente que la sesión con el asesor terminó y que el agente retoma la atención. Si la ventana de 24 h de WhatsApp está cerrada al momento de la devolución, la notificación se envía por plantilla Meta aprobada registrada a tal efecto. Ninguna devolución ocurre en silencio.
• PR-216 — Intents críticos del cliente durante pending_handoff. Aunque el agente no responde mensajes de contenido mientras la conversación está en pending_handoff (PR-137), FleteChat sigue detectando intents críticos del cliente y actúa sobre ellos sin esperar al operador. Los intents críticos son, como mínimo: cancelación del handoff ("cancelá", "olvidalo", "ya no quiero hablar con un asesor") → FleteChat acepta la cancelación con confirmación explícita y devuelve la conversación al estado anterior; opt-out de comunicaciones proactivas → FleteChat registra el cambio y confirma; emergencia o alerta de seguridad declarada por el cliente → FleteChat eleva la prioridad del handoff al operador y avisa al cliente. El resto de los mensajes del cliente se acumulan para que el operador los vea al tomar la conversación; el agente muestra el mensaje de estado de PR-137 para los mensajes no críticos.

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-136 a PR-138, PR-150 y PR-216 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente