# Análise Nicho 18 — Despacho de Ordens de Serviço de Campo, Chamados Pós-Obra & Suporte a ATMs

## Veredito

O despachador proposto resolve os três canvases de operação de campo (assistência pós-obra e manutenção de ATMs), e o ponto que a análise original subestimou é que **metade do ganho está antes do despacho**: triagem que resolve remotamente e evita a visita, que é onde mora o custo dos 900 operadores. Mas o grupo contém uma segunda dor que não é despacho nenhum: dois canvases da mesma empresa pedem uma memória técnica corporativa — o que se aprende no atendimento de campo fica represado na área que atendeu e não vira ação de engenharia, qualidade e comercial. Isso é um produto próprio, com usuário e ritmo diferentes (analítico, não operacional). Nenhum canvas do grupo é ruído ou pertence a outro nicho.

## Contagens

| Categoria | Qtd | Índices |
|---|---|---|
| FIT | 3 | [0], [1], [2] |
| ADJACENTE | 2 | [3], [4] |
| OUTRO_NICHO | 0 | — |
| RUIDO | 0 | — |
| EXCLUIR | 0 | — |

## Classificação canvas a canvas

- **[0] Assistência técnica LD** — FIT. Cliente de construtora aciona a assistência por telefone e acaba falando com o último colaborador com quem teve contato, o que trava o fluxo e atrasa. Dor de intake e roteamento de chamado pós-obra.
- **[1] LD Engenharia** — FIT, mesma autora e mesma empresa do [0] (contar como 1 empresa). Amplia a dor: não existe canal preciso de comunicação com o cliente, especialmente para assistência técnica e garantia de obra, e a mesma falha ocorre entre setores. Mesmo app.
- **[2] e-@sto** — FIT. Parque de ATMs com 900 operadores de campo e custo de manutenção pressionando a sustentabilidade do negócio. O canvas não detalha a solução, mas a dor é eficiência de operação de campo: menos visita desnecessária, melhor alocação, preventiva no lugar certo. É o núcleo do nicho.
- **[3] WCES_Adoção de IA (base de conhecimento)** — ADJACENTE. Informação coletada em atendimentos de assistência técnica, service e comercial fica represada na área que atuou e não gera plano de ação para engenharia, vendas e qualidade — o exemplo dado (problema com redutor em campo que deveria chegar ao desenvolvimento de produto) define bem o produto. Vira o app `memoria-tecnica-campo`.
- **[4] WCES_Adoção de IA — REVISADA** — ADJACENTE, mesmo autor e mesma empresa do [3] (versão revisada do mesmo canvas; contar 2 canvases, 1 empresa). Acrescenta o requisito de captura multimodal — registrar o caso por texto, áudio, foto, vídeo ou e-mail, com transcrição e estruturação automática — porque o registro manual atual é o gargalo. Entra no MVP do mesmo app.

**Fronteira a vigiar no consolidado**: `memoria-tecnica-campo` faz análise de recorrência de falhas, o que encosta no nicho 21 (RNC/SGQ). A separação proposta: a memória técnica captura, estrutura e detecta o padrão; o fluxo formal de não conformidade com CAPA e aprovação é do nicho 21. O ponto de acoplamento entre os dois é o contrato `field-case-event`.

## App 1 — `despacho-os-campo` — Despacho e Suporte de Ordens de Serviço de Campo

**Dor**: chamado de campo entra por qualquer porta (telefone, WhatsApp de quem o cliente conhece), sem registro estruturado nem roteamento por competência; técnico se desloca para problema que se resolveria por telefone; ninguém sabe o status até o cliente cobrar.

**Canvases**: [0], [1], [2] · 3 canvases · 2 empresas

**Funcionalidades do MVP**
1. Canal único de abertura (WhatsApp, formulário e telefone com transcrição) que identifica cliente, contrato, unidade e ativo antes de qualquer coisa.
2. Triagem por IA: classifica tipo de problema e urgência, decide garantia versus cobrável e exige foto e localização quando o tipo pede.
3. Roteiro de resolução remota antes de despachar, com RAG embutido nos manuais e no histórico de casos — visita só quando o roteiro falha (é aqui que o custo cai).
4. Abertura de OS estruturada e despacho por competência do técnico combinada com proximidade e janela de agenda.
5. PWA do técnico: fila do dia, checklist da OS, registro por foto e áudio, peças utilizadas e fechamento com aceite do cliente.
6. Suporte ao técnico em campo pelo WhatsApp, aceitando áudio e devolvendo a instrução do manual do equipamento com citação da fonte.
7. SLA e reincidência: alerta de OS prestes a estourar prazo e de retorno ao mesmo ativo dentro de uma janela configurável.
8. Notificação automática ao cliente a cada mudança de status, eliminando a ligação de cobrança.

**Fora do MVP**: roteirização multiobjetivo com otimização de frota (a v1 usa proximidade e janela de agenda); gestão de estoque e reposição de peças; faturamento da OS; manutenção preditiva por telemetria de sensores do equipamento.

**Contratos** — emite: `service-order-event`, `field-case-event`, `conversation-log`, `handoff-event` · consome: `knowledge-schema`, `customer-360-read`

## App 2 — `memoria-tecnica-campo` — Memória Técnica de Campo e Recorrência de Falhas

**Dor**: o que se aprende no atendimento técnico fica preso na área que atendeu, em e-mails, formulários e na cabeça das pessoas; ninguém acha caso semelhante, ninguém percebe que a mesma falha se repete no mesmo modelo, e engenharia, qualidade e vendas seguem sem saber o que o campo já descobriu.

**Canvases**: [3], [4] · 2 canvases · 1 empresa

**Funcionalidades do MVP**
1. Registro multimodal do caso — texto, áudio, foto, vídeo ou e-mail encaminhado — com transcrição automática, porque digitar é o gargalo atual.
2. Extração estruturada do caso: ativo e modelo, sintoma, causa raiz, solução aplicada, peça envolvida, tempo gasto.
3. Normalização em taxonomia de falhas por família de produto, editável pelo time de qualidade.
4. Busca semântica de casos semelhantes a partir da descrição do problema, com RAG e pgvector próprios, retornando a solução que funcionou e quem a aplicou.
5. Detecção de recorrência: agrupa falhas por modelo, lote, componente e região e dispara alerta quando cruza um limiar configurado.
6. Painel por área com roteamento do insight — engenharia vê padrão de falha de projeto, qualidade vê não conformidade recorrente, comercial vê o que evitar em nova especificação.
7. Ficha consolidada por produto: histórico de falhas, soluções validadas e evolução no tempo, exportável.
8. Curadoria: especialista valida o caso antes de ele virar "solução oficial", com feedback de utilidade em cada consulta.

**Fora do MVP**: fluxo formal de RNC/CAPA com workflow de aprovação (nicho 21); despacho e agenda de técnicos (é o app irmão); integração com PLM e engenharia de produto; tratativa financeira de garantia e ressarcimento.

**Contratos** — emite: `knowledge-schema` · consome: `field-case-event`, `conversation-log`

**Contratos novos propostos**
- `service-order-event`: ciclo de vida canônico da OS (abertura, cliente, ativo, tipo, urgência, técnico designado, deslocamento, status, fechamento, aceite). Permite que ERP, faturamento e BI leiam a operação de campo sem integração ponto a ponto.
- `field-case-event`: caso técnico estruturado de campo (ativo/modelo, sintoma, causa raiz, solução, peça, evidências em foto/áudio, tempo, técnico, resultado). É o que liga o despacho à memória técnica e, mais adiante, ao fluxo de RNC do nicho 21.

## RESUMO JSON

```json
{
  "group_ids": [18],
  "apps": [
    {"id": "despacho-os-campo", "nome": "Despacho e Suporte de Ordens de Servico de Campo", "dor": "Chamado de campo entra por qualquer porta sem registro estruturado nem roteamento por competencia; tecnico se desloca para problema que se resolveria remotamente e ninguem sabe o status ate o cliente cobrar", "canvases_indices": [0, 1, 2], "n_canvases": 3, "n_empresas": 2, "funcionalidades_mvp": ["Canal unico de abertura (WhatsApp, formulario, telefone com transcricao) identificando cliente, contrato e ativo", "Triagem por IA: tipo, urgencia, garantia vs cobravel, foto e localizacao obrigatorias por tipo", "Roteiro de resolucao remota com RAG embutido em manuais e historico, evitando a visita", "Abertura de OS estruturada e despacho por competencia + proximidade + janela de agenda", "PWA do tecnico com fila do dia, checklist, registro por foto/audio, pecas e fechamento com aceite", "Suporte ao tecnico em campo por WhatsApp com resposta do manual por audio e citacao de fonte", "Alertas de SLA prestes a estourar e de reincidencia no mesmo ativo", "Notificacao automatica ao cliente a cada mudanca de status"], "fora_mvp": ["roteirizacao multiobjetivo com otimizacao de frota", "gestao de estoque e reposicao de pecas", "faturamento da OS", "manutencao preditiva por telemetria de sensores"], "contratos_emite": ["service-order-event", "field-case-event", "conversation-log", "handoff-event"], "contratos_consome": ["knowledge-schema", "customer-360-read"]},
    {"id": "memoria-tecnica-campo", "nome": "Memoria Tecnica de Campo e Recorrencia de Falhas", "dor": "O aprendizado do atendimento tecnico fica represado na area que atendeu; ninguem acha caso semelhante nem percebe a falha que se repete, e engenharia, qualidade e vendas nao recebem o que o campo descobriu", "canvases_indices": [3, 4], "n_canvases": 2, "n_empresas": 1, "funcionalidades_mvp": ["Registro multimodal do caso (texto, audio, foto, video, e-mail) com transcricao automatica", "Extracao estruturada: ativo/modelo, sintoma, causa raiz, solucao, peca, tempo", "Normalizacao em taxonomia de falhas por familia de produto, editavel pela qualidade", "Busca semantica de casos semelhantes com RAG e pgvector proprios", "Deteccao de recorrencia por modelo, lote, componente e regiao com alerta por limiar", "Painel por area com roteamento do insight para engenharia, qualidade e comercial", "Ficha consolidada por produto com historico de falhas e solucoes validadas", "Curadoria por especialista antes de virar solucao oficial, com feedback de utilidade"], "fora_mvp": ["fluxo formal de RNC/CAPA com workflow de aprovacao (nicho 21)", "despacho e agenda de tecnicos (app irmao)", "integracao com PLM e engenharia de produto", "tratativa financeira de garantia e ressarcimento"], "contratos_emite": ["knowledge-schema"], "contratos_consome": ["field-case-event", "conversation-log"]}
  ],
  "reclassificacoes": [],
  "ruido": [],
  "excluir": []
}
```