Skip to main content

App de Vendas Externas (Força de Campo) | Cenário de uso | Offline Support | Arquitetura

  • App de Vendas Externas (Força de Campo) | Cenário de uso | Offline Support | Arquitetura

Contexto​

Uma empresa possui vendedores que visitam clientes em regiões com conectividade instável (3G fraco ou sem sinal).

A aplicação permite:

  • Consultar catálogo
  • Criar pedidos
  • Atualizar dados do cliente
  • Registrar pagamentos

Sem suporte offline, o fluxo depende 100% da API.

Cenário 1 — Sem Offline Support

Fluxo​

  1. Vendedor acessa cliente
  2. Cria pedido
  3. Aplicação envia para API
  4. API responde

Problema​

Se estiver offline:

  • Pedido não é criado
  • Vendedor precisa anotar manualmente
  • Pode perder informação
  • Pode gerar retrabalho
  • Experiência degradada

Resultado prático​

  • Taxa de conversão menor
  • Perda de pedidos
  • Inconsistência entre sistema e realidade

Cenário 2 — Com Offline Support (Outbox Pattern + Cache)

Arquitetura​

Camadas:

  • UI
  • Sync Manager
  • Banco local (SQLite / IndexedDB)
  • Fila Outbox
  • API

Fluxo Offline​

  1. Vendedor cria pedido
  2. Pedido salvo localmente
  3. Pedido inserido na Outbox
  4. UI mostra "Pedido criado (pendente de sincronização)"
  5. Quando conexão retorna → Sync executa

Estrutura Local​

Pedido salvo:

{
  "id": "local-123",
  "clientId": 45,
  "items": [...],
  "status": "pending_sync",
  "version": 1
}

Outbox:

{
  "id": "event-789",
  "type": "CREATE_ORDER",
  "payload": {...},
  "retryCount": 0
}

Sync Worker​

Fluxo:

  1. Detecta conexão online
  2. Envia eventos da outbox
  3. Atualiza ID real do servidor
  4. Remove da fila

Resultado Mensurável

Antes​

  • 12% dos pedidos falhavam por instabilidade
  • Tempo médio de venda: 4 minutos
  • 18% retrabalho administrativo

Depois​

  • 0% falha por rede
  • Tempo médio de venda: 2,5 minutos
  • 3% retrabalho
  • Aumento de conversão em regiões remotas

Problema Realista: Conflito

Cenário:

  1. Vendedor A edita cliente offline
  2. Backoffice edita cliente online
  3. Quando sincroniza → conflito

Resolução com Versionamento​

Modelo:

{
  "id": 10,
  "name": "Cliente X",
  "version": 5
}

Se versão divergir:

Servidor responde:

{
  "error": "VersionConflict",
  "serverVersion": 6
}

Aplicação pode:

  • Fazer merge automático
  • Solicitar resolução manual
  • Aplicar regra LWW

Outro Cenário: App de Checklist Industrial

Técnicos realizam inspeções em fábricas subterrâneas.

Sem offline:

  • Inspeção interrompida
  • Dados anotados em papel
  • Erros de transcrição

Com offline:

  • Checklist armazenado localmente
  • Fotos armazenadas localmente
  • Sync posterior

Resultado:

  • 100% das inspeções registradas digitalmente
  • Eliminação de papel
  • Redução de erro humano

Onde Você Consegue “Ver” o Resultado

Você percebe resultado em:

  1. Continuidade da UX
  2. Ausência de erro de rede
  3. Indicador “pendente de sincronização”
  4. Sincronização automática posterior
  5. Métricas de queda de erro

Teste Prático Controlado

Você pode simular:

  1. Criar app simples
  2. Implementar IndexedDB + outbox
  3. Desligar rede no DevTools
  4. Criar registros
  5. Ligar rede
  6. Observar sincronização automática

Esse experimento mostra claramente:

  • Persistência local funcionando
  • Sistema resiliente
  • Consistência eventual