CASO · LOGÍSTICA Y DISTRIBUCIÓN · USA
Un operador last-mile que pasó del papel a una operación probada de punta a punta
Tres portales, prueba de entrega multimedia, una máquina de estados explícita y matching de productos con IA. Así rearmamos la operación de un operador logístico last-mile en Estados Unidos.
El proceso antes
Una operación que vivía de la memoria y el teléfono
Rutas en papel
El driver salía con una hoja impresa. Reordenar stops o reasignar un vehículo era una llamada y una nota a mano.
Sin prueba de entrega
"¿Llegó o no llegó?" se resolvía por teléfono. Ninguna foto, ninguna firma, ningún nombre de quien recibió.
Stock a ciegas
El inventario no sabía qué estaba en tránsito ni qué entraba por pickup. Se descubría el faltante cuando ya era tarde.
Cómo lo entendimos
Del recorrido real al flujo optimizado
Modelamos el pedido como máquina de estados
Definimos cada transición —incluyendo la rama de excepción— para que ningún envío quede en un estado ambiguo.
Separamos la operación en tres portales
Admin controla, el driver opera desde el teléfono y el cliente se autoservicia. Cada rol ve solo lo suyo.
Hicimos la prueba de entrega obligatoria
Fotos comprimidas, firma, notas de voz y "Received By" antes de poder cerrar el stop. La duda desaparece.
Conectamos pedidos e inventario en tiempo real
Shopify/Make entran por Edge Function, el matching resuelve el producto y el stock se reabastece solo en inbound.
Una operación, tres experiencias
Tres portales especializados por rol
El mismo pedido se ve distinto para quien lo despacha, quien lo entrega y quien lo recibe. Selecciona un portal para ver su experiencia.
Portal Admin
Orders (outbound + inbound PO), rutas, clientes, drivers, inventario, atenciones, asistente IA y settings con RBAC.
| ID | Destino | Estado |
|---|---|---|
| ORD-1042 | Brooklyn DC | on_route |
| ORD-1043 | Queens Hub | in_transit |
| PO-0218 | Inbound · Newark | pickup_ready |
| ORD-1041 | Bronx Store | delivered |
Inventory: 2 SKU bajo el 50% del mínimo · 6 unidades In Transit
Máquina de estados explícita
El pedido nunca está en un estado ambiguo
Cada transición está modelada en el backend. No hay "creo que ya salió": el pedido avanza por estados definidos y la rama de excepción es de primera clase.
Desde on_route / in_transit, rama de excepción:
Inbound (pickup PO): al recoger se registra la orden de compra; al llegar a delivered el stock se reabastece automáticamente. Inventario que se corrige solo.
Integración Shopify / Make
Matching de productos en 4 pasos
Los pedidos entran por una Edge Function con API key. El catálogo externo nunca calza perfecto con el interno, así que el match es una cascada: barato y determinista primero, IA solo cuando hace falta.
SKU exacto
Si el SKU del documento externo coincide con el catálogo, match inmediato.
si falla ↓
Nombre exacto
Sin SKU válido, se intenta coincidencia exacta por nombre normalizado.
si falla ↓
Fuzzy Jaccard ≥ 0.6
Similitud de tokens entre nombres; se acepta sobre el umbral 0.6.
si falla ↓
Fallback IA
Si nada resuelve, la IA decide el producto correcto con el contexto de la factura.
Además, los PDF de facturas se parsean con IA para extraer líneas y cantidades antes de pasar por la misma cascada de matching.
Qué se construyó
El sistema completo, no una pieza suelta
3 portales por rol
Admin (control total), Driver (mobile-first) y Cliente (autoservicio), cada uno con su propia UX.
POD multimedia
Múltiples fotos comprimidas (≤1280px / JPEG 0.7), firma digital, notas de voz y receptor obligatorio.
Matching de productos con IA
Cascada de 4 pasos: SKU → nombre → fuzzy Jaccard ≥0.6 → fallback IA. PDFs de factura parseados con IA.
Auto-replenish inbound
El pickup PO registra la orden de compra y al entregar el stock se actualiza sin intervención manual.
Realtime sobre Postgres
Triggers + suscripciones: lo que el driver confirma aparece al instante en admin y en el portal cliente.
RBAC granular módulo × acción
Permisos finos, has_role() SECURITY DEFINER y papelera de 30 días con restauración.
Alcance de desarrollo
Lo que hay debajo
- ▸Máquina de estados explícita: pending → assigned → picked → pickup_ready → on_route → in_transit → delivered, con ramas needs_attention / not_delivered.
- ▸RBAC granular por módulo y acción con función has_role() SECURITY DEFINER y soft-delete (trash 30 días).
- ▸Edge Functions Deno con API key para ingesta Shopify/Make y parseo de facturas PDF con IA.
- ▸Mapbox dark-v11 para rutas y stops; reordenamiento en el portal driver.
- ▸Realtime vía triggers Postgres + suscripciones Supabase en los tres portales.
Logros
Qué cambió en la operación
Toda entrega queda probada: nunca más una disputa de "¿llegó o no?".
El driver opera el día completo desde el teléfono, sin papel.
El inventario refleja la realidad: tránsito e inbound dejaron de ser puntos ciegos.
Operaciones dejó de ser un call center: el cliente se autoservicia.
TU OPERACIÓN ES EL SIGUIENTE CASO
¿Tu last-mile vive del teléfono y el papel?
Te mostramos cómo modelaríamos tu operación como sistema: portales por rol, prueba de entrega y estados explícitos. Agenda un diagnóstico de 30 minutos.