Pedidos en Ruta para Vendedores de Distribuidora: App Offline-First

Una distribuidora típica argentina tiene vendedores que pasan 6-8 horas al día en ruta visitando clientes, muchos en zonas con conectividad inestable. Una app bien diseñada permite cargar pedidos sin señal, sincronizar automáticamente al recuperarla, y eliminar la friction de cargar pedidos por WhatsApp al final del día. La arquitectura, el stack y los costos reales en Argentina 2026.

Lecturas previas útiles: sistema a medida para distribuidoras y migrar de Excel a sistema a medida en 90 días.

Por qué offline-first es no-opcional

Realidad de la conectividad AR fuera de zonas urbanas

Aún en CABA y GBA hay zonas con cobertura 3G/4G inestable: depósitos en parques industriales, clientes en sótanos, edificios con paredes gruesas, supermercados con jaulas Faraday. En interior del país (PBA, Córdoba, Santa Fe, Mendoza), la conectividad inconsistente es la norma fuera de centros urbanos.

Una app online-only obliga al vendedor a:

• Esperar reload de pantalla cada vez que entra a un cliente
• Anotar pedidos en papel y cargarlos al final del día (defeats the purpose)
• Llamar al admin por WhatsApp para que cargue el pedido (defeats the purpose harder)

Una app offline-first elimina la friction completamente.

Arquitectura offline-first

Componentes clave

[Mobile device]
  ├─ UI (React/Next.js PWA)
  ├─ Local store (IndexedDB)
  ├─ Service Worker (caching + sync)
  └─ Sync queue (pending operations)
       ↓ (cuando hay señal)
       ↓
[Backend]
  ├─ API (REST/GraphQL)
  ├─ Conflict resolution
  └─ DB (Postgres)

Local store con IndexedDB

IndexedDB es la BBDD del navegador moderna. Capacidad: cientos de MB sin pedir permisos extras. Permite:

• Cachear catálogo completo (10k productos = ~5MB)
• Guardar pedidos pendientes de sincronización
• Indexar por cliente, producto, fecha
• Queries instantáneas sin red

Librerías recomendadas: Dexie.js (wrapper sobre IndexedDB) o RxDB (sync automatizado). Dexie es más simple para casos típicos.

Service Worker para caching + offline

Service Worker maneja:

• Cache de assets (HTML, JS, CSS, fonts) para que la app cargue sin red
• Network-first o cache-first strategy según endpoint
• Background sync para reintentos automáticos

Sync queue

Cada acción del vendedor (crear pedido, actualizar cliente, marcar pago) se guarda como "operación pendiente" en una queue local. Cuando la app detecta conectividad, procesa la queue en orden FIFO.

Lib: Workbox (de Google) implementa Background Sync API correctamente.

Stack recomendado

Frontend

• Next.js 16 con PWA support (next-pwa o next-offline)
• TypeScript para type safety
• Tailwind + shadcn/ui para UI rápida
• Dexie.js para IndexedDB
• TanStack Query con persister para cache de servidor

Backend

• Next.js API Routes o FastAPI
• Postgres (multi-tenant si es plataforma para varias distribuidoras)
• Redis opcional para queue de sync events

Hosting

• Vercel para frontend
• Railway / Fly.io para backend Python si aplica

Más en stack tecnológico para sistemas empresariales 2026. Si necesitás esta app integrada a tu operación, suele venir junto a un proyecto de sistemas a medida para distribuidoras.

Funcionalidades críticas

1. Catálogo offline

• Lista completa de productos con foto, precio, stock referencial
• Búsqueda local instantánea (sin red)
• Filtros por categoría, marca, promoción
• Última actualización visible (ej: "actualizado hace 2 horas")

2. Carga de pedidos sin señal

• Selección rápida de cliente (autocomplete con histórico)
• Adición de items con scanner de código de barras (camera API)
• Validación de stock disponible (referencia local + warning si dudoso)
• Cálculo automático de descuentos por cliente/producto
• Total con IVA + percepciones

3. Comprobante de pedido

• PDF generado localmente (jsPDF)
• Compartible por WhatsApp / email al cliente
• Firma digital del cliente con touch
• Foto opcional de remito firmado

4. Sincronización inteligente

• Background sync cuando vuelve señal
• Indicador visible: "5 pedidos pendientes de sincronizar"
• Retry automático con backoff exponencial
• Merge de updates del backend (precios cambiados, stock actualizado)

5. Histórico de cliente

• Últimos 10-20 pedidos con detalle
• Estado de cuenta (saldo + vencimientos)
• Notas internas del vendedor
• Tags personalizados

6. Hoja de ruta

• Pedidos a entregar en el día
• Optimización de recorrido (Google Maps Directions API)
• Marcar como visitado/no visitado
• Foto + firma de entrega

Conflict resolution

Tipos de conflictos típicos

1. Precio cambió mientras estaba offline - sistema decide: aplicar precio del momento de carga del pedido o precio actual al sincronizar. Recomendado: aplicar precio del momento (timestamp del cliente).
2. Stock insuficiente - pedido se marca como "pendiente revisión" con alerta al admin
3. Cliente bloqueado - pedido se rechaza al sincronizar, vendedor recibe notificación
4. Pedido duplicado - matching por cliente + fecha + items, marca duplicado para revisión

Estrategia recomendada

• Cliente (vendedor) wins en conflictos de datos del pedido (precios, items)
• Servidor wins en validaciones de negocio (cliente bloqueado, stock muy negativo)
• Casos borderline → revisión humana en admin

Costos reales

Inversión inicial

• App básica (catálogo + pedidos + sync): USD 4-7k, 4-6 semanas
• App con histórico + comprobante: USD 6-10k, 5-7 semanas
• App full (hoja de ruta + GPS + integraciones): USD 10-18k, 7-10 semanas

Mantenimiento mensual

• Plan básico: USD 200-400 (bug fixes + ajustes menores)
• Plan estándar: USD 400-800 (incluye evolución continua)

ROI típico

Para distribuidora con 10 vendedores:

• Tiempo ahorrado por vendedor: 1-2h/día (vs cargar pedidos por WhatsApp + Excel al final)
• Errores reducidos: 5-12% → 0.5-1%
• Vendedores cargan más visitas/día (no pierden tiempo en zonas sin señal)

ROI break-even típico: mes 5-9.

Errores típicos a evitar

1. App online-only "porque siempre hay señal"

Falso. Hay zonas donde no la hay. La app deja de funcionar y el vendedor vuelve a Excel/WhatsApp = inversión perdida.

2. Sincronización manual

"El vendedor aprieta sync al final del día." Mal. Vendedor se olvida o se carga el dato. Sync debe ser automático.

3. Cache estático sin updates

Catálogo cacheado eternamente. Vendedor vende a precio viejo. Updates incrementales en cada sync (delta sync).

4. Sin indicador visual de estado offline

Vendedor no sabe si está sincronizando o sin señal. Toggle visible en topbar.

5. Sin queue persistente

Si el vendedor cierra la app antes de sync, los pedidos se pierden. Queue debe estar en IndexedDB, no en memoria.

Escenario real

Distribuidora de productos de consumo masivo en GBA con 8 vendedores.

Diagnóstico previo:

• Vendedores cargaban pedidos en libreta papel + planilla Excel al final del día
• Tiempo administrativo del vendedor: 2-3h/día post-ruta
• Errores de carga: 8-12%
• Stock desfasaje: 15%

Solución implementada:

• App PWA con catálogo offline, carga de pedidos, hoja de ruta, comprobante PDF
• Sync background con backend custom
• Stack: Next.js + Dexie + Workbox + Postgres

Resultado a 6 meses:

• Tiempo administrativo vendedor: 2-3h/día → 15-20 min/día
• Errores de carga: 10% → 0.8%
• Stock desfasaje: 15% → 2%
• Vendedores cargan 4-6 visitas más por día (porque no pierden tiempo)

Inversión: USD 7.500 setup + USD 350/mes.

ROI break-even: mes 6.

Cómo aplicar esto

App de pedidos en ruta offline-first es la diferencia entre vendedores cargando pedidos sin friction vs vendedores luchando con Excel y WhatsApp al final del día. Para distribuidoras con 5+ vendedores en ruta, el caso suele pagarse en 5-9 meses con la suma de tiempo ahorrado + reducción de errores + más visitas/día.

Stack recomendado en 2026: PWA con Next.js + Dexie + Workbox + sync API custom. Costos arrancan en USD 4-7k según alcance.

Necesitás esto en tu empresa? Hablemos. Lecturas: sistema a medida para distribuidoras, stack tecnológico para sistemas empresariales 2026, la guía de software a medida en Argentina.