US-008 — Guía conversacional dinámica

Detalle de la historia¶

Historia¶

Como cliente de FleteChat, quiero que FleteChat me pregunte solo los datos que faltan según el tipo de operación que estoy cotizando, para no responder preguntas irrelevantes ni repetir información que ya di.

Persona de usuario¶

Aplica a todo cliente verificado que está en el flujo de cotización (propio o vía colaborador).

Contexto de negocio¶

Una cotización aérea no necesita los mismos datos que una cotización marítima FCL: el aéreo pide peso y dimensiones, el FCL pide tipo y cantidad de contenedores, el LCL pide volumen, etc. Si FleteChat pidiera siempre el mismo set de preguntas, obligaría al cliente a responder "no aplica" o a entender por qué le preguntan algo que no tiene sentido en su caso.

La guía dinámica hace lo opuesto: según la modalidad, el Incoterm, el tipo de operación y lo que ya se sabe, FleteChat identifica el set mínimo de datos faltantes y lo pide en orden natural (de lo más general a lo más específico), aceptando varios datos juntos cuando el cliente los da.

Diálogo de referencia¶

Set de preguntas varía según modalidad¶

Cliente: Quiero cotizar a Miami, marítimo.

Agente: Perfecto. ¿Es contenedor completo o carga suelta?

Cliente: Suelta.

Agente: Anotado: marítimo LCL a Miami. Necesito el origen y el volumen o las dimensiones de la carga.

Cliente da varios datos en un mensaje¶

Cliente: Ah, sale de Bogotá y son 3 cajas de 80×60×50 cm, pesan 120 kilos en total.

Agente: Listo: LCL Bogotá → Miami, 3 bultos, 0.72 m³ en total, 120 kg. Un último dato: ¿es importación suya o se lo están enviando en condiciones CIF / FOB?

Cliente cambia la modalidad a mitad del flujo¶

Cliente: Mejor mándamelo aéreo.

Agente: Cambio a modalidad aérea. Para aéreo ya no necesito el volumen total, pero sí las dimensiones por bulto para calcular el peso volumétrico. ¿Me confirma 80 × 60 × 50 cm para cada una de las 3 cajas?

Criterios de aceptación¶

Identificación de lo que falta¶

1. FleteChat consulta al sistema qué datos se requieren para la combinación (modalidad + tipo de operación + Incoterm) antes de preguntar.
2. FleteChat compara el set requerido con los datos ya provistos en la conversación y pide solo los faltantes.
3. FleteChat no pregunta datos ya provistos, ni datos que se pueden inferir de otros (por ejemplo, no pregunta volumen total si ya tiene las dimensiones por bulto y la cantidad).

Orden y agrupación¶

1. FleteChat pide los datos en orden natural para el cliente (primero ruta, luego modalidad, luego características de carga, luego Incoterm). No usa un orden técnico ni alfabético.
2. FleteChat acepta varios datos en un solo mensaje del cliente y los procesa todos antes de preguntar lo siguiente.

Recálculo ante cambios¶

1. Si el cliente cambia un dato que afecta el set de campos requeridos (por ejemplo, cambia modalidad de marítimo a aéreo), FleteChat recalcula qué le falta y pide solo lo nuevo; no vuelve a pedir datos que siguen siendo válidos.
2. FleteChat avisa al cliente cuando un cambio vuelve irrelevante un dato ya provisto ("ya no necesito el volumen total porque pasamos a aéreo").

Claridad de cierre¶

1. Cuando FleteChat tiene todos los datos necesarios, lo declara al cliente y pasa a la siguiente fase (servicios opcionales y precio), sin seguir pidiendo datos.

Edge cases¶

• Cliente ya dio todos los datos en el primer mensaje. FleteChat confirma el resumen y pasa directo a servicios opcionales / precio, sin hacer preguntas intermedias.
• Cliente rehúsa dar un dato requerido. FleteChat explica brevemente por qué lo necesita; si el cliente sigue sin darlo, FleteChat ofrece handoff humano.
• Combinación cambia a una no soportada mid-flujo. FleteChat declara la situación y activa el flujo de handoff por combinación no soportada, sin seguir pidiendo datos de una ruta que no puede cotizar.
• Cliente responde un dato en la conversación equivocada (por ejemplo, responde al agente otro dato mientras estaba hablando con un humano). FleteChat usa el dato si es válido para la cotización actual; si no tiene sentido, pide aclaración.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — sin guía dinámica, el flujo de cotización se vuelve tedioso.
• 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-045 — Fuente del set de campos requeridos. Los datos obligatorios por combinación (modalidad + tipo de operación + Incoterm) los define el sistema operativo de FleteChat. FleteChat los consulta; no los infiere.
• PR-046 — Orden natural de preguntas. FleteChat pregunta en orden natural al cliente (ruta, modalidad, carga, Incoterm), no en orden técnico ni alfabético.
• PR-047 — Recálculo ante cambios. Cambios que afectan el set requerido (modalidad, Incoterm) disparan un recálculo; datos ya válidos se conservan y no se vuelven a pedir.

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