Saltar a contenido

Flujo end-to-end del cliente

Recorrido objetivo del usuario desde que abre la app por primera vez hasta confirmar la entrega de un paquete en Cuba. Es la vista canónica del flujo MVP y debe ser consistente con datos/estados.md, producto/decisiones-vigentes.md y los documentos por etapa.

Cada paso debe cubrir los estados de UI obligatorios definidos en diseno/estados-ui.md: loading, vacío, error, éxito, offline, modo demo y bloqueo de negocio.

0. Entrada

  1. Bienvenida con branding y botón "Empezar".
  2. Decisión D-200: login real o acceso demo.
  3. Si login real: validar credenciales o recuperar sesión por OTP o enlace.
  4. Si acceso demo: entrar con credenciales visibles y mostrar banda "Datos de demostración".
  5. Tutorial solo en la primera entrada, con "Saltar" y accesible desde Ayuda.
  6. Dashboard con resumen de paquetes y sección "Requiere tu atención" si aplica.

1. Obtener dirección de casillero

  • El usuario copia su identificador y dirección de Miami desde el dashboard.
  • Debe existir ayuda contextual por plataforma (Amazon/SHEIN/Temu) que explique dónde colocar el identificador.
  • Acción del usuario: pegar la dirección al hacer checkout.

2. Reportar compra (prealerta)

Ver prealerta.md en detalle. Resumen canónico:

  1. Paso 1 — Compra: tienda, número de orden, fecha, categoría, descripción, cantidad, valor.
  2. Paso 2 — Seguimiento: tracking opcional, comprobante opcional, notas.
  3. Confirmación: ID demo y estado
  4. reportada si hay tracking;
  5. reportada_sin_tracking si no lo hay.
  6. CTA "Añadir tracking después" visible en el detalle.

3. Seguimiento hasta almacén

  • La app muestra qué conoce y qué no.
  • No inventar estados como "en camino" si solo existe la prealerta sin evento del transportista.
  • Si llegan eventos del operador (conciliación, identificación), se traducen a estados canónicos.

4. Recepción

  • El operador identifica, pesa, mide, clasifica y captura fotos.
  • Estados canónicos resultantes: recibido_sin_identificar, recibido_identificado o pendiente_conciliacion.
  • El cliente recibe notificación que abre el detalle correcto (deep link).

5. Decisión logística

Para paquetes en en_almacen o esperando_instrucciones:

  • Solicitar servicio adicional (inspección / reempaque / fotografía).
  • Solicitar devolución.
  • Enviar como paquete individual.
  • Consolidar con otros paquetes.

Aquí se confirman destinatario y vía (no en la prealerta). Resolver D-206.

6. KYC

Si la acción requiere KYC y el usuario no lo tiene aprobado:

  1. Mostrar gate con motivo, beneficio y próxima acción.
  2. Conservar la intención original del usuario para no perder contexto.
  3. Al aprobar KYC, el usuario vuelve a la acción sin re-crear el flujo.

Ver kyc.md.

7. Cotización y pago

  1. Desglose único y marcado como estimado o final.
  2. Confirmar destinatario, vía y condiciones.
  3. Aplicar el método de pago aprobado para MVP (D-107: registro manual).
  4. Mostrar estado real: pendiente, pago_enviado_para_validacion, pagado o fallido.

Ver consolidacion-pago.md.

8. Despacho y tránsito

  • Timeline con eventos reales (despachado_desde_almacen, en_transito_a_cuba, en_aduana, liberado_de_aduana, en_reparto).
  • Fecha estimada de entrega visible.
  • Acceso directo a "Reportar incidencia".

9. Entrega y cierre

  • Estado entregado con marca de tiempo.
  • Acceso a factura/comprobante.
  • Política de incidencia posterior a la entrega según normativa.

Estados transversales

Cada pantalla con datos debe tratar:

  • Loading (skeleton o indicador).
  • Vacío con CTA explícito.
  • Error con causa humana, código técnico en detalles y reintento.
  • Éxito con próxima acción.
  • Offline: lo que se puede consultar; lo que se guarda para enviar luego.
  • Modo demo: banda persistente con datos ficticios.
  • Bloqueo de negocio: motivo, condición para desbloquear, CTA y alternativas.

Prototipo demo actual

La APK demo implementa este recorrido en memoria de sesión: crear prealerta, añadir tracking posterior, simular recepción, enviar KYC, simular su resultado, crear consolidación y cotización, reportar pago, aprobarlo y despachar el envío. Cada transición actualiza listas, detalle, dashboard y notificaciones desde DemoSessionRepository.

Las acciones de operador se identifican explícitamente como demo. No sustituyen el backoffice ni persisten al reiniciar la aplicación. La integración real con backend, push y almacenamiento de archivos sigue fuera de este prototipo.