US-060 — Manejo transparente de errores

Detalle de la historia¶

Historia¶

Como cliente de FleteChat, quiero que si FleteChat tiene un problema técnico me lo diga con transparencia y me ofrezca una alternativa (reintentar o hablar con una persona), para no quedar sin respuesta ni con una respuesta dudosa cuando algo falla.

Persona de usuario¶

Aplica a todo cliente del servicio logístico que interactúa con FleteChat por WhatsApp. También protege a FleteChat: un agente que oculta sus fallos erosiona la confianza mucho más rápido que un agente que los reconoce.

Contexto de negocio¶

Los sistemas fallan: un proveedor externo se cae, una consulta demora, el modelo da timeout, la base operativa no responde a tiempo. La pregunta no es si va a pasar, sino cómo se comporta FleteChat cuando pasa.

Dos comportamientos son inaceptables:

• Silencio. El cliente queda esperando indefinidamente y no sabe si su mensaje llegó.
• Simulación. FleteChat responde con algo genérico o inventado porque no pudo consultar el sistema.

Esta historia define la tercera opción: reconocer el fallo con lenguaje claro y dar al cliente una salida (reintentar automáticamente, volver a intentar más tarde, o hablar con un asesor humano). Complementa la historia de precisión y anti-alucinación (no inventar datos) con la contrapartida operativa (qué hacer cuando el sistema no puede responder bien).

Diálogo de referencia¶

Fallo al consultar tarifa¶

Cliente: Cotízame FCL Shanghái a Balboa.

Agente: Estoy teniendo un inconveniente consultando las tarifas en este momento. ¿Prefiere que lo intente de nuevo en un minuto o que lo pase con un asesor?

Fallo persistente tras reintento¶

Agente: Sigo sin poder consultar las tarifas. Lo paso con un asesor humano para que pueda atenderlo sin demora. Un momento por favor.

Fallo parcial del agente¶

Cliente: ¿Qué me decías antes?

Agente: Tengo un inconveniente leyendo la conversación completa en este momento. Para no hacerle perder tiempo, ¿me recuerda qué tema estábamos tratando y seguimos desde ahí?

Criterios de aceptación¶

Reconocimiento del fallo¶

1. Ante un fallo técnico que le impide responder correctamente, FleteChat se lo comunica al cliente en lenguaje claro y sin jerga técnica.
2. FleteChat no muestra al cliente mensajes técnicos (códigos de error, nombres de servicios internos, trazas, identificadores de sistemas, detalles de la falla).
3. FleteChat no simula funcionamiento cuando no puede consultar el sistema: no entrega respuestas operativas sin respaldo bajo ningún motivo (ver historia de precisión).

Ruta de recuperación¶

1. Ante cualquier fallo que le impida avanzar, FleteChat ofrece al cliente al menos una opción explícita: reintentar, intentar más tarde, o hablar con un asesor humano.
2. Si un reintento automático es seguro y razonable, FleteChat lo ejecuta una vez antes de molestar al cliente con el fallo; si el reintento resuelve, el cliente no se entera.
3. Si un fallo persiste tras el reintento automático, FleteChat escala automáticamente a un asesor humano conforme a la historia de handoff, sin hacer esperar al cliente para que elija.

Preservación del trabajo en curso¶

1. Durante un fallo, FleteChat no pierde los datos ya recolectados en la conversación: cuando el cliente retoma, no tiene que empezar de cero.
2. Si el cliente retoma tras un fallo y el agente no pudo completar una acción (por ejemplo, guardar una cotización), FleteChat lo declara al cliente y ofrece reintentar la acción.

Edge cases¶

• Fallo del motor de lenguaje (modelo no responde). FleteChat reintenta una vez; si sigue sin responder, escala a un asesor humano y envía al cliente un aviso breve.
• Fallo de la base operativa (no puede consultar tarifas / embarques). FleteChat lo declara; no responde preguntas operativas hasta que el sistema vuelva o hasta que intervenga un humano.
• Fallo del canal de salida (WhatsApp no recibe el mensaje). No es visible al cliente por naturaleza; el sistema registra el fallo para auditoría y reintento posterior.
• Fallo parcial (puede leer, no escribir, o viceversa). FleteChat continúa con lo que sí funciona y declara lo que no puede hacer en este momento.
• Cascada de fallos repetidos para el mismo cliente en poco tiempo. FleteChat no pide al cliente reintentar una y otra vez; al segundo fallo consecutivo, escala.

Cómo mediremos éxito¶

• Cero silencios técnicos: ningún reporte de cliente indicando que FleteChat "no contestó nada" tras un mensaje durante los primeros 90 días de operación, contando con logs de errores que respalden la detección.
• Escalada automática ante fallo persistente: en una muestra de fallos detectados en producción, el 100% de los que no se resolvieron solos en un reintento terminaron en handoff humano sin intervención manual.
• Ausencia de respuestas simuladas: cero discrepancias entre lo que FleteChat le dijo al cliente durante un fallo y lo que realmente se registró en sistema.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P0 — sin manejo de errores transparente, el cliente pierde confianza en la primera caída.
• 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-015 — Transparencia ante fallos. FleteChat reconoce explícitamente los fallos técnicos al cliente con lenguaje claro, sin mostrar detalle técnico ni simular funcionalidad.
• PR-016 — Reintento automático. FleteChat ejecuta un reintento silencioso cuando es seguro hacerlo, antes de informar el fallo al cliente.
• PR-017 — Escalada automática ante fallo persistente. Si el fallo persiste tras el reintento, FleteChat activa handoff humano automáticamente sin pedirle al cliente que elija qué hacer.
• PR-018 — Preservación del trabajo en curso. Los datos recolectados antes del fallo se conservan; el cliente puede retomar sin reingresarlos.

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