US-015 — Formulario de datos operativos

Detalle de la historia¶

Historia¶

Como cliente de FleteChat con una cotización sobre la que expresé la intención de aprobar, quiero completar los datos operativos del embarque en un formulario web con enlace temporal, para cerrar la operación sin tener que llenar un formato en WhatsApp ni crear una cuenta en un portal.

Persona de usuario¶

Aplica a todo cliente verificado (titular o colaborador autorizado) que ya pasó por el Paso 1 de la aprobación de cotización (ver historia de aprobación por WhatsApp) y recibió el enlace al formulario operativo por correo y WhatsApp.

Contexto de negocio¶

La cotización describe el "qué" de la operación (ruta, modalidad, total, vigencia). Para ejecutarla faltan los datos operativos del embarque: quién es el remitente, quién es el consignatario, qué mercancía concreta se transporta, con qué documentación, con qué observaciones y contactos de coordinación. Esos datos no son apropiados para capturarse en un intercambio conversacional largo por WhatsApp —se pierden, se cortan, se confunden— y pedirle al cliente que cree cuenta en un portal aumenta la fricción y mata la conversión.

El formulario web tokenizado resuelve ambos extremos: el cliente abre un enlace firmado que recibió por correo y WhatsApp, ve la cabecera con el resumen de la cotización que está a punto de completar, llena los campos que faltan con los datos operativos y envía. Con eso el sistema genera las instrucciones del embarque y dispara el Paso 3 de la aprobación formal (ver historia de aprobación por WhatsApp).

Diálogo de referencia¶

Envío del enlace al formulario desde el agente¶

Agente: Le envié a su correo c@empresa.com y por aquí el enlace al formulario del embarque de la cotización C187. Ábralo, revise los datos, complete remitente, consignatario, mercancía y observaciones, y envíelo. Con eso le preparo las instrucciones del embarque. Mientras la cotización siga vigente (hasta el 24/04/2026*) puede completar el formulario cuando quiera.

Cliente abre el enlace con la cotización vencida¶

[El cliente hace click en el enlace después del vencimiento de la cotización.]

Pantalla del formulario: La cotización C187 venció el 24/04/2026. Si quiere retomar la operación, pídale a FleteChat por WhatsApp que revise si los precios siguen vigentes; si es así, puede volver a este mismo formulario.

(El cliente regresa al chat de WhatsApp.)

Cliente: Se me venció la C187, ¿puedes revisarla?

Agente: Con gusto. Reviso la vigencia de los precios de la cotización C187. (continúa con el flujo de validación de vigencia; ver historia de vigencia y expiración de cotizaciones.)

Cliente pide reenvío del enlace¶

Cliente: No encuentro el enlace del formulario, mándamelo otra vez.

Agente: Con gusto. Le reenvío el mismo enlace al formulario de la cotización C187 por aquí y a su correo c@empresa.com*. La cotización sigue vigente hasta el 24/04/2026; puede completarlo cuando quiera.

Criterios de aceptación¶

Acceso al formulario¶

1. El enlace al formulario es tokenizado y firmado, ligado a la cotización CNNN como recurso. El enlace en sí no tiene fecha de expiración propia: la validez del acceso depende exclusivamente de la vigencia de la cotización asociada, que se valida en cada acceso al enlace y en cada intento de envío del formulario. Esto elimina ventanas intermedias y hace que toda extensión de la cotización se refleje sin regenerar el enlace.
2. Al abrir el enlace, FleteChat valida la vigencia de la cotización. Si está vigente, renderiza la página web pública (no requiere login) con la cabecera que muestra el resumen de la cotización (código CNNN, ruta, modalidad, total, desglose, fecha de vencimiento). Si la cotización está vencida o cancelada, muestra una página de error clara con la explicación del estado y el paso sugerido (volver a WhatsApp para validación de vigencia de precios).
3. Si el enlace ya fue consumido (el formulario ya se envió exitosamente en un intento anterior) o fue invalidado por regeneración, la página muestra el estado correspondiente con referencia al camino vigente (el embarque registrado o el enlace nuevo).
4. El formulario es responsive: se usa cómodamente desde celular (el canal esperado al recibir el enlace por WhatsApp) y desde escritorio.

Campos y validación¶

1. El formulario captura al menos los siguientes datos operativos: remitente (nombre, dirección, contacto), consignatario (5 campos: Empresa, Dirección, Persona de contacto, Teléfono, Email), descripción de la mercancía (tipo, cantidad, peso real, volumen, valor declarado), documentación requerida (factura comercial o proforma como único adjunto obligatorio; el resto se solicita durante la ejecución de la operación, ver AC 11), observaciones operativas. El conjunto de campos obligatorios para cada combinación modalidad + servicio se rige por PR-075.
2. Los campos obligatorios se indican visiblemente y se validan en cliente y en servidor antes de aceptar el envío.
3. La validación rechaza el envío si hay campos obligatorios faltantes, formatos inválidos o incompatibilidades con los datos de la cotización (por ejemplo, peso declarado que excede el contratado). El formulario muestra los errores y permite corregir sin perder los datos ya escritos.

Datos clave readonly y ajuste de cotización¶

1. Los datos clave de la cotización (peso, volumen, modalidad, Incoterm, ruta) aparecen en el formulario como campos readonly (no editables). Cualquier cambio sobre estos datos requiere abrir un flujo explícito de ajuste de cotización.
2. El formulario incluye un botón "Ajustar cotización" claramente visible junto a los campos readonly. Al hacer clic, el cliente abandona el formulario actual y FleteChat lo guía por WhatsApp para iniciar la recotización con los nuevos datos (ver historia de vigencia y expiración, US-014, para el flujo de re-cotización con datos heredados).

Prellenado de datos conocidos¶

1. Los datos del cliente ya conocidos al momento de la cotización (nombre del titular, contacto principal de la cuenta, correo, teléfono activo del contacto) y los datos del envío ya provistos en la fase de cotización aparecen prellenados en modo readonly. El cliente no vuelve a escribir información que ya entregó.

Documento único obligatorio para iniciar la operación¶

1. Para que el formulario sea aceptado, el único documento obligatorio que el cliente debe cargar es la factura comercial o proforma. El resto de documentos (packing list, certificados, BL/AWB, etc.) no bloquea el envío del formulario; se solicitan durante la ejecución de la operación, en los momentos en que cada uno se vuelve necesario.

Identificación de la cotización al pedir reenvío del enlace¶

1. Cuando el cliente pide por WhatsApp el reenvío del enlace, FleteChat identifica la cotización asociada antes de reenviar:
2. Si hay una sola cotización activa del cliente con formulario pendiente, FleteChat asume y reenvía el enlace correspondiente.
3. Si hay varias, FleteChat lista las cotizaciones activas (CNNN, ruta, vigencia restante) y pide al cliente elegir cuál.
4. Si no hay ninguna pendiente, FleteChat lo declara.

Envío y cierre¶

1. Al intentar enviar el formulario, FleteChat revalida la vigencia de la cotización como primer paso antes de aceptar los datos. Si la cotización venció entre el momento de abrir el enlace y el momento del submit, el formulario rechaza el envío, muestra el estado al cliente y sugiere el camino vigente (volver a WhatsApp para validación de vigencia de precios). Los datos ya escritos se conservan como borrador para reutilizarse si la cotización se extiende.
2. Al enviar exitosamente (cotización vigente al momento del submit), el formulario confirma al cliente en la misma página que los datos se recibieron y explica los siguientes pasos (revisar el correo con las instrucciones del embarque y aprobar formalmente desde el enlace del correo; ver historia de aprobación por WhatsApp).
3. El envío exitoso registra los datos operativos con referencia a la cotización CNNN, dispara la generación de las instrucciones del embarque (ver historia de distribución automática de instructivos) y marca el enlace como consumido. Un segundo acceso al mismo enlace muestra la página de "enlace ya consumido" con referencia al embarque generado.

Borrador y continuidad¶

1. Mientras la cotización esté vigente y el enlace no haya sido consumido, el cliente puede cerrar y regresar al formulario y encontrar sus datos ya escritos (borrador ligado al enlace).
2. El borrador se conserva aun si la cotización se extiende o se revalida: al volver al enlace con la cotización nuevamente vigente, los datos previamente escritos están disponibles para continuar desde donde se dejó.
3. El borrador se descarta cuando el enlace se marca como consumido (submit exitoso). El cliente nunca pierde datos en silencio: el formulario declara el estado al abrir.

Reenvío del enlace¶

1. El cliente puede pedir por WhatsApp que le reenvíen el enlace con frases naturales ("no encuentro el enlace", "mándame otra vez el formulario", "reenvíame el link"). FleteChat reenvía el mismo enlace (no genera uno nuevo): lo vuelve a entregar por correo al email verificado del contacto y por WhatsApp en la misma conversación.
2. El operador con rol autorizado (admin u operator) puede reenviar el enlace desde el backoffice a partir del embarque pendiente.
3. El reenvío no altera el estado del enlace: sigue siendo el mismo recurso, con el mismo borrador si existe. Si la cotización está vencida al momento del reenvío, FleteChat no reenvía y aplica el flujo de validación de vigencia de precios (ver historia de vigencia y expiración).
4. Cada reenvío queda registrado en el audit log con actor (cliente o operador), canal y timestamp.

Edge cases¶

• Cliente abre el enlace desde dos dispositivos a la vez. El formulario permite lectura simultánea pero el envío ganador es el primero que completa el submit; el otro dispositivo ve la página de "enlace ya consumido" al intentar enviar.
• El cliente queda sin conexión mid-formulario. Los datos ya escritos viven en el borrador ligado al enlace; al reconectarse y reabrir, el formulario se recarga con los datos preservados y revalida la vigencia de la cotización antes de continuar.
• La cotización vence mientras el cliente está llenando el formulario. El submit revalida la vigencia: si venció, el envío se rechaza y el cliente recibe el estado; los datos ya escritos se conservan como borrador. Si el cliente pide revalidación por WhatsApp y la cotización se extiende, al volver al mismo enlace el borrador está disponible para continuar.
• El cliente declara un peso o volumen que cambia el precio. El formulario lo detecta al validar, muestra el conflicto y sugiere re-cotizar. No registra los datos ni dispara instrucciones hasta que el conflicto se resuelve (ajustar dato o iniciar nueva cotización desde WhatsApp).
• Campos opcionales vacíos. El formulario acepta el envío; las instrucciones generadas lo reflejan sin inventar datos.
• El cliente se equivoca en un campo después de enviar. El enlace ya se marcó como consumido y la aprobación formal está en curso; el cliente debe pedir por WhatsApp que se corrija antes de hacer click en el enlace de aprobación del correo. FleteChat lo maneja con regeneración de instrucciones y nuevo enlace.
• Cliente sin email verificado al momento de pedir reenvío. FleteChat lo declara y ofrece handoff para verificación manual antes de proceder; el reenvío no se ejecuta mientras el email no esté verificado.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — es el paso 2 de la aprobación y sin esto la operación no se puede formalizar.
• 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-073 — Acceso público tokenizado. El formulario es una página web pública sin login, accesible únicamente mediante el enlace firmado de un solo uso. La autorización descansa en el token + el canal de entrega (correo verificado).
• PR-074 — Enlace sin expiración propia; validación en cada uso. El enlace al formulario no tiene fecha de expiración propia: está ligado a la cotización CNNN como recurso. La vigencia se valida en cada acceso al enlace y en cada intento de envío del formulario contra la cotización asociada. Si la cotización está vigente, el acceso y el envío proceden; si no, se rechazan con el estado correspondiente. Extensiones de la vigencia de la cotización se reflejan sin regenerar el enlace.
• PR-075 — Campos mínimos por servicio. El conjunto de campos obligatorios del formulario depende de la modalidad y del servicio contratado; el catálogo de FleteChat define qué campos son obligatorios para cada combinación.
• PR-076 — Responsivo y móvil primero. El formulario se diseña priorizando uso desde celular, porque el enlace llega típicamente por WhatsApp. Desktop es compatible pero no es el canal primario.
• PR-077 — Borrador local por enlace. Mientras el enlace esté vigente, el formulario preserva un borrador con los datos ya escritos. El borrador se descarta al vencer o invalidarse el enlace.
• PR-225 — Invalidación del enlace ante eventos de cierre de la cotización o emisión del embarque. El enlace del formulario se invalida automáticamente y no permite acceso ni envío cuando ocurre cualquiera de estos eventos sobre la cotización asociada: (a) la cotización vence según su vigencia (ya cubierto por PR-074); (b) la cotización se cancela explícitamente por operador o cliente; (c) el embarque queda emitido (el flujo de formulario fue consumido por otra vía o por un reenvío previo); (d) el cliente ejerce eliminación de datos sobre la cuenta titular (US-061). El intento de acceso a un enlace invalidado devuelve un mensaje claro con el estado correspondiente y el borrador local se descarta.
• PR-244 — Único documento obligatorio al iniciar la operación. El único documento que el cliente debe cargar para que el envío del formulario sea aceptado es la factura comercial o proforma. El resto de documentos (packing list, certificados, BL/AWB, dependencias por Incoterm) no bloquea el envío del formulario; se solicitan durante la ejecución de la operación a medida que cada uno se vuelve necesario.

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-073 a PR-077, PR-225 y PR-244 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente