Respuesta a la revisión de Fase 1 — Refinamientos dentro del alcance¶

Este documento es la segunda parte de la respuesta a la revisión de Fase 1 de FleteChat v1.0. Se concentra en las observaciones que no expanden el alcance del producto pero ajustan reglas, flujos, lenguaje o detalles dentro de lo ya previsto. En la mayoría de los casos se traducen en criterios de aceptación adicionales sobre historias existentes.

Las otras dos partes de la respuesta se entregan como documentos separados:

• Impactos en el alcance — qué se incorpora a v1.0, qué se difiere a v1.1 y qué se descarta.
• Respuestas a comentarios con dudas — preguntas planteadas durante la revisión y su respuesta.

Los refinamientos se agrupan por historia de usuario para facilitar el cruce con los comentarios originales. Cada bloque sintetiza todas las anotaciones recibidas sobre esa historia y da la respuesta consolidada.

US-003 — Titular y colaboradores¶

Respuesta consolidada.

• #2 — Se acepta. El correo de verificación de cualquier registro deja claro el rol (titular vs. colaborador) y el nombre con el que se registró el usuario. Si el rol o el nombre no son correctos, el correo ofrece un enlace para corregir antes de confirmar.
• #5 — Se acepta con un matiz. En el flujo de US-003, el titular confirma explícitamente al colaborador (con clic). Para cerrar la verificación bidireccional, el colaborador también recibe una notificación cuando el titular lo confirma, con la identidad del titular declarada. Si el colaborador no reconoce al titular, puede declinar la asociación desde ese mismo mensaje. La asociación solo se activa cuando ambos lados están de acuerdo.
• #7 — Se acepta. Cada cotización aprobada por un colaborador genera una notificación al titular por WhatsApp (al número verificado del titular). El contenido es resumido (cotización, cliente, monto, colaborador que aprobó) sin requerir acción del titular.

US-005 — Alta de cliente desde el backoffice¶

Respuesta consolidada. Coincide con el diseño previsto, lo aclaramos en la US: el flujo es (1) el operador da de alta al cliente desde el backoffice con sus datos básicos; (2) el sistema envía al correo del cliente un mensaje de bienvenida con un enlace de verificación + resumen de los datos registrados; (3) el cliente hace clic, confirma los datos y desde ese momento queda verificado. Si los datos no son correctos, el correo ofrece un enlace separado para reportar la discrepancia, que llega al operador.

US-006 — Edición de datos de cliente¶

Respuesta consolidada. Se acepta. La edición de titular se habilita en el backoffice como caso especial: el operador puede transferir la condición de titular de un usuario a otro dentro de la misma cuenta (debe ser un colaborador ya verificado de la cuenta). El cambio dispara una notificación a ambos (titular saliente y titular entrante) y queda registrado en el audit log.

US-008 — Guía conversacional dinámica¶

Respuesta consolidada. Se acepta. Cuando el cliente declara que le falta un dato y necesita consultarlo, el bot suspende la solicitud sin perderla: guarda el contexto y le dice al cliente que cuando tenga la información, regrese a la conversación con esos datos y la cotización se retoma desde donde quedó. No hay límite de tiempo estricto para la suspensión; si pasa una ventana razonable (parametrizable) sin actividad, el bot envía un recordatorio al cliente.

US-009 — Selección de servicios opcionales¶

Respuesta consolidada. Se acepta. El bot solo menciona los opcionales si aplican (lista positiva); si no aplican, no dice nada al respecto. La frase "no hay opcionales" se elimina del libreto.

US-010 — Precio total con desglose¶

Respuesta consolidada.

• #16 y #17 — Confirman el diseño. El flujo es exactamente ese: cotización conversada en chat, PDF por correo con condiciones detalladas, aprobación formal por clic en el correo. La aprobación final del cliente no es por texto en WhatsApp, es por el clic.
• #18 — Se acepta. La cotización incluye un campo "Condiciones especiales" libre por cotización (cuando aplique), que se imprime en el PDF y se menciona en el mensaje de WhatsApp si su contenido afecta precio o tiempo de tránsito. Si solo son condiciones administrativas estándar, el mensaje WhatsApp solo menciona "ver condiciones en el PDF".
• #19 — Se acepta. Cuando el cliente menciona un código de cotización que no pertenece a su cuenta, el bot lo declara explícitamente sin revelar a quién pertenece: "Ese número de cotización no está asociado a tu cuenta. ¿Quieres que busquemos por descripción o por fecha?".
• #20 — Sin acción. Comentario de cierre del anterior.

US-011 — Tiempo de tránsito estimado¶

Respuesta consolidada. Se acepta. El mensaje de WhatsApp con la cotización ya etiquetará el tiempo de tránsito como "estimado". En el PDF se incluye un párrafo en las condiciones que explica que los tiempos son estimados y dependen de factores externos (rutas, escalas, clima, aduana, etc.). Esto se cruza con #71 del documento de alcance (Condiciones Generales del Servicio) — ambas observaciones apuntan a lo mismo desde dos ángulos.

US-012 — Aprobación de cotización por WhatsApp¶

Respuesta consolidada. Se acepta. El formulario operativo (US-015) muestra los datos clave que definieron el precio (peso, volumen, modalidad, Incoterm, ruta) como solo lectura, sin posibilidad de tipear sobre ellos. Si el cliente necesita cambiar alguno de esos datos, dispone de un botón explícito "Ajustar cotización" en el formulario, que abre un flujo separado: el cliente indica qué datos cambian, el sistema recotiza con la información nueva y emite una cotización actualizada que el cliente debe aprobar antes de continuar con el formulario operativo. Esto separa claramente lo que es "completar datos para operar" de lo que es "modificar la cotización vigente", y evita que un cambio en un dato crítico altere el precio de forma silenciosa.

US-014 — Vigencia y expiración¶

Respuesta consolidada.

• #25 — Se acepta. El bot confirma el número antes de tomar acción (esto se cruza con #19 en US-010 — patrón general: ante referencia ambigua o no existente, confirmar antes de actuar).
• #26 — Se acepta. Cuando se actualizan las tarifas (US-044), el sistema identifica las cotizaciones emitidas con vigencia abierta cuyo precio cambiaría con la nueva tarifa y le notifica al asesor responsable (o al equipo en su defecto). El cliente sigue protegido por la tarifa cotizada hasta el vencimiento — la notificación al asesor es para que pueda conversar proactivamente con el cliente si tiene sentido.

US-015 — Formulario de datos operativos del embarque¶

Respuesta consolidada.

• #27 y #32 — Se acepta. Cuando el cliente pide reenvío del enlace del formulario, el bot identifica primero a qué cotización está vinculado: si el cliente tiene una sola cotización pendiente de formulario, la confirma y reenvía; si tiene varias, lista las opciones y le pide elegir.
• #28 y #29 — Se acepta. La estructura de datos del consignatario queda: empresa, dirección, persona de contacto, teléfono, email. Cinco campos, sin agrupaciones rebuscadas.
• #30 — Se acepta. Todos los datos ya conocidos al momento de cotizar (cliente titular, ruta, modalidad, Incoterm, carga, valor declarado, etc.) aparecen prellenados en modo solo lectura en el formulario operativo. El cliente solo completa lo nuevo (consignatario, proveedor, fechas tentativas, documento de la operación).
• #31 — Se acepta. El formulario operativo solo solicita factura comercial o proforma como documento obligatorio (uno u otro, según corresponda al momento de la operación). El resto de documentos (lista de empaque, certificados, permisos, etc.) se solicitan durante la operación si la ruta o el tipo de carga los requieren, no de antemano. Esto mantiene el formulario corto.

US-019 — Instructivo para el proveedor del cliente (PDF)¶

Respuesta consolidada.

• #36 — Se acepta. El instructivo al proveedor incluye en el encabezado los datos del cliente que solicita la mercancía (nombre del cliente y su persona de contacto) y, en el cuerpo, la referencia explícita al documento de la operación (número de factura comercial o proforma) para que el proveedor pueda vincularlo con su propio registro.
• #37 — Se acepta. El cliente recibe copia del instructivo del proveedor al mismo correo donde recibe la cotización y el resto de comunicaciones del embarque, para que tenga visibilidad de lo que se le pidió al proveedor.

US-020 — Instructivo para el operador logístico externo (PDF)¶

Respuesta consolidada.

• #39 — Se acepta. El template del instructivo al operador incluye secciones condicionales que aparecen según el Incoterm aplicable: para DDP/DAP se incluyen secciones de coordinación de despacho destino y entrega final; para FOB/CFR/CIF se omiten esas secciones y se enfatizan las de origen. La estructura del PDF se adapta sin requerir templates separados por Incoterm.
• #42 — Se acepta. El instructivo al operador no se envía al cliente, ni se incluye un enlace que el cliente pueda usar. PR-096 ya excluye información comercial; con esto se complementa que tampoco se expone la información operativa interna al cliente.

US-022 — Distribución automática de instructivos¶

Respuesta consolidada. Se acepta. Cuando el embarque ha sido aprobado por el cliente pero la distribución de instructivos al proveedor aún no se ha disparado (porque depende de un dato pendiente o de una confirmación del cliente), el sistema envía al cliente un recordatorio por WhatsApp después de un tiempo configurable (por ejemplo, 24 horas hábiles). Si pasa el doble de ese tiempo sin acción, también se notifica al operador FleteChat para revisión.

US-023 — Consulta de estatus por WhatsApp¶

Respuesta consolidada. Se acepta el cambio de criterio sugerido por #44/#45: el bot no adivina el embarque cuando la referencia del cliente es ambigua. En su lugar, lista los embarques activos del cliente (en una respuesta breve con número, ruta, fecha aproximada y estatus actual) y le pide elegir cuál. Si el cliente solo tiene un embarque activo, lo asume directamente. Para #46: los datos mostrados en el resumen son los más útiles para el cliente — proveedor (de quien viene la mercancía), referencia de proforma o factura, volumen y ruta. El Incoterm no se muestra en el resumen porque no ayuda al cliente a identificar el embarque (sí se mantiene visible para el operador FleteChat en el backoffice, ver #48).

US-026 — Notificación proactiva al cliente¶

Respuesta consolidada. Se acepta. Aun cuando el cliente haya desactivado las notificaciones proactivas (opt-out), dos notificaciones se consideran críticas y se entregan siempre: (1) llegada de la mercancía al puerto/aeropuerto destino en operaciones de importación, y (2) salida confirmada desde el origen en operaciones de exportación. El opt-out solo silencia las actualizaciones intermedias (en tránsito, embarcado, etc.).

US-027 — Secuencia dinámica de estatus¶

Respuesta consolidada. Se acepta. El bot responde sobre el estatus actual con precisión y, si el cliente pregunta por uno futuro ("¿cuándo llega a destino?", "¿ya pasó por aduana?"), responde según corresponda: si la fecha estimada existe, la entrega con la etiqueta "estimado"; si no existe aún, le explica que ese hito todavía no está programado y que se le notificará cuando avance.

US-028 — Consulta conversacional de reportes¶

Respuesta consolidada.

• #53 — Se acepta. El reporte conversacional siempre incluye un enlace o opción para descargar la versión exportable (CSV o Excel — ver pregunta abierta #54 en el documento de dudas).
• #55 — Se acepta. El bot resuelve referencias geográficas con alias razonables: "España" mapea a las ciudades de España presentes en los embarques del cliente; si hay varias y la pregunta admite ambigüedad, el bot pide precisión. Lo mismo aplica a "China", "Asia", "Europa", etc. — el bot resuelve cuando puede y pregunta cuando no.
• #56 — Se acepta. El copy del bot cuando no tiene una métrica solicitada sigue la forma sugerida: reconoce la limitación, propone lo más cercano que sí tiene, y deja claro que la métrica solicitada se evalúa para versiones futuras.

US-032 — Reportes estructurados por dimensión¶

Respuesta consolidada. Se acepta. El backoffice muestra el Incoterm en la vista detalle del embarque, en el listado de embarques (columna opcional configurable), y en los reportes (como columna disponible aunque no sea dimensión de agrupación). El cliente no lo ve en los resúmenes conversacionales (ver #46), pero el operador sí.

US-033 — Transferencia del cliente a un agente humano (handoff)¶

Respuesta consolidada para #51. Se acepta. Una vez el operador toma la conversación y le escribe al cliente, el bot bloquea nuevas solicitudes automáticas de handoff por una ventana configurable (por ejemplo, 15 minutos desde el último mensaje del operador). Si el cliente está en pleno intercambio con el operador, no debería poder pedir "que me atienda un humano" porque ya está atendido. La ventana se renueva con cada mensaje del operador; si el operador deja de responder, después del tiempo configurado la ventana se cierra y el cliente puede volver a solicitar handoff.

Respuesta consolidada para #59 (cotización manual cuando la combinación no es soportada):

Esta pregunta apunta a un detalle de US-033 que la historia daba por implícito pero no explicitaba. US-033 establece que ante una combinación no soportada el bot escala al asesor con consentimiento del cliente; lo que faltaba aclarar es cómo entra al sistema la cotización que el asesor construye después. Se trata, por tanto, de un criterio de aceptación adicional sobre US-033, no de funcionalidad nueva: sin este AC, la historia de handoff queda colgada y la cotización armada por el asesor sería invisible para US-010 (envío), US-012 (aprobación), US-014 (vigencia), US-023 (consulta) y US-031/032 (reportes).

Cómo funciona. Cuando el bot detecta una combinación que no soporta (típicamente una ruta nueva), entra el asesor para construir la cotización con el cliente. El asesor consulta tarifas con sus proveedores fuera del sistema (eso no cambia respecto a hoy) y, cuando tiene el precio armado, carga la cotización en un formulario del backoffice. El formulario acepta los campos como texto libre cuando no están en catálogo (origen, destino, etc.) y persiste la cotización marcada como manual.

A partir de ese momento, la cotización sigue el mismo flujo que una automática: el sistema le genera código, arma el PDF, lo envía al cliente por WhatsApp y por correo, calcula vigencia, dispara recordatorios, y al aprobar emite los instructivos y el embarque. Para el cliente la experiencia es indistinguible de una cotización automática; el sistema mantiene trazabilidad completa.

Límite del flujo. Esto aplica solo cuando la operación es estructuralmente igual a las soportadas por el sistema: cambia la ruta o la tarifa, pero se mantienen los mismos servicios, los mismos pasos operativos y la misma secuencia de estatus del modelo estándar. Si el servicio es estructuralmente distinto (carga peligrosa con declaración DGR, carga refrigerada con monitoreo de temperatura, carga sobredimensionada con permisos viales, carga regulada con licencias de importación, etc.), no se carga al sistema: el asesor coordina ese caso con el cliente por fuera (correo, WhatsApp directo). El sistema no es la herramienta para improvisar tipos de servicio en runtime.

La forma de cubrir esos servicios estructuralmente distintos es modelarlos en el catálogo desde el levantamiento inicial — como tipos de servicio con sus campos adicionales y sus secuencias de estatus propias. De ahí en adelante el bot los cotiza automáticamente, sin handoff.

US-034 — Notificación al operador cuando se activa un handoff¶

Respuesta consolidada. Se acepta. El sistema permite configurar un horario de atención (por ejemplo, lunes a viernes 8:00 a 18:00). Fuera de ese horario, cuando un cliente solicita handoff, el bot le explica claramente que el equipo está fuera de horario, le ofrece la opción de dejar su consulta para que se le contacte al inicio del próximo turno hábil, e indica explícitamente cuándo (por ejemplo, "lunes a las 8:00"). La notificación al operador queda registrada para ser atendida al inicio del turno.

US-035 — Chat de handoff en tiempo real¶

Respuesta consolidada. Se acepta. Se evita la palabra "humano" en los libretos de mensajes al cliente. Se usan alternativas naturales: "uno de nuestros asesores", "un miembro del equipo", "Carlos del equipo FleteChat", etc. La distinción entre bot y persona se hace siempre explícita (el cliente sabe cuándo le escribe el bot y cuándo le escribe el asesor), pero sin la palabra que resulta extraña.

US-036 — Devolución de la conversación al agente automático¶

Respuesta consolidada. Esto se incorpora dentro del cambio aceptado en el item #64 del documento de alcance (control de conversaciones desatendidas). La bandeja del operador presenta dos columnas — conversaciones activas (asignadas al operador) y conversaciones pendientes (sin asignar, esperando que alguien las tome) — con tiempo desde el último mensaje en cada item.

US-043 — Catálogos de modalidades, Incoterms y tipos de operación¶

Respuesta consolidada. Se acepta. El modelo de catálogos de US-043 se refina para incluir rutas (origen-destino) como dimensión de primer nivel: las modalidades, los Incoterms y los tipos de operación aplicables se configuran por ruta (o por familia de rutas, ej. "rutas marítimas desde Asia"), no de forma global. Esto refleja la realidad: no todas las rutas admiten todas las modalidades, ni todos los Incoterms son razonables en cualquier ruta. La estructura concreta del modelo de datos se acuerda al refinar US-043 con el equipo técnico (no es decisión del cliente porque no afecta la experiencia visible, solo la operación interna del catálogo).

US-044 — Actualización manual de listas de precios¶

Respuesta consolidada.

• #69 — Se acepta. Al editar una tarifa, si el valor nuevo difiere en más de un umbral configurable respecto al valor anterior (por defecto 30% hacia arriba o hacia abajo, parametrizable), el formulario muestra un warning antes de guardar y pide confirmación explícita. No bloquea el cambio — solo solicita un segundo clic consciente.
• #70 — Se acepta. Cada tarifa puede tener costo mínimo (ya previsto) y, opcionalmente, costo máximo. Si el cálculo resultante de una cotización excede el costo máximo configurado, se aplica el máximo (analogía con el comportamiento ya previsto para el mínimo).