# Análise Nicho 19 — Extrator de Pedidos de Venda em PDF/WhatsApp para Lançamento Direto no ERP

## Veredito

A solução única resolve bem apenas um dos quatro canvases (o [0], que é a dor-núcleo literal: pedido chega despadronizado, alguém imprime e digita no ERP). O canvas [1] (autorização de convênios) foi capturado por regex e pede um produto tecnicamente oposto — ali o dado de entrada JÁ é uma planilha padronizada; o gargalo é operar portais de terceiros sem API e ficar caçando status, o que é RPA + polling, não visão computacional. Os canvases [2] e [3] são duplicata do mesmo autor e não pedem extração nenhuma: pedem decisão de aprovação sobre pedidos que já entram estruturados no sistema — dor legítima, mas fina demais (1 empresa, score 8) para virar produto próprio, então entra como módulo do painel do extrator.

Resultado: 2 aplicações independentes.

## Contagens

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

Duplicatas: [2] e [3] são o mesmo canvas do mesmo autor (Marcelo Neves) com projectIds diferentes → 1 empresa. Empresas únicas no grupo: 3.

---

## App 1 — `extrator-pedidos-erp` — Extrator & Lançador de Pedidos de Venda no ERP

**Dor:** pedidos de clientes chegam em PDF, foto de WhatsApp, e-mail e planilhas fora de padrão; ninguém consegue importar direto, então imprime-se e digita item a item no ERP — lento, caro e com erro de quantidade/código. Junto disso, quem já recebe pedido estruturado gasta o dia aprovando um a um sem critério explícito.

**Canvases:** [0] (FIT, Petronioinfo), [2] e [3] (ADJACENTE absorvido, Marcelo Neves) — 3 canvases, 2 empresas.

Sobre a absorção de [2]/[3]: a dor deles ("aprovar pedidos 1 a 1, reduzir tempo de aprovação e acompanhar volume") acontece exatamente na tela onde o extrator já obriga um humano a conferir o pedido antes de mandar pro ERP. Em vez de um app de "aprovação inteligente" com 1 empresa por trás, vira a régua de confiança e auto-aprovação desse mesmo painel. O que não se deve fazer é o que o canvas pede literalmente — treinar um modelo que aprende a aprovar/rejeitar de histórico: sem explicação, sem trilha e sem responsável, ninguém coloca isso em produção comercial. A régua é de regras versionadas (cliente, limite de valor, produto, margem, crédito) com o modelo apenas sugerindo e explicando.

**Funcionalidades do MVP:**
1. Entrada multicanal num só inbox: número de WhatsApp dedicado (Evolution/ChatVolt), caixa de e-mail (IMAP) e upload manual no painel — tudo vira um "documento recebido" com remetente identificado.
2. Classificação do arquivo antes de extrair (pedido novo, alteração de pedido, comprovante, ruído) para não gastar visão em anexo de assinatura de e-mail.
3. Extração com Claude Vision contra schema JSON estrito de pedido de venda (cliente, CNPJ, condição de pagamento, itens: código, descrição, quantidade, unidade, preço), com nível de confiança por campo.
4. Normalização e de-para de produto: casamento do texto do cliente com o código do ERP por dicionário aprendido + busca fuzzy/semântica; item sem casamento nunca é inventado, vai para pendência.
5. Painel de revisão lado a lado (imagem original x campos extraídos), com correção inline que realimenta o dicionário de de-para.
6. Régua de auto-aprovação por regras versionadas: pedido acima de X% de confiança, de cliente recorrente, dentro de limite de valor e sem item novo, segue direto; o resto entra em fila priorizada por valor e tempo de espera, com a sugestão e o motivo explícitos.
7. Lançamento no ERP via API com idempotência (mesmo documento nunca gera dois pedidos) e devolução do número do pedido ao remetente pelo mesmo canal.
8. Painel operacional: fila por status, tempo médio documento→ERP, taxa de extração sem toque humano, top itens que sempre falham no de-para.

**Fora do MVP:** negociação de preço/desconto com o cliente pelo WhatsApp; conversa aberta com o cliente (o canal responde só confirmação e pendência); reescrita/cancelamento de pedido já lançado; separação, faturamento e logística; ERPs sem API (esse caso é o App 2); treinamento de modelo próprio de aprovação.

**Contratos que emite:** `doc-extraction-event`, `order-event`
**Contratos que consome:** `customer-360-read` (opcional, para validar cliente/limite de crédito quando o ERP expõe)

**Stack:** n8n (webhooks WhatsApp/IMAP, orquestração, POST no ERP) + Supabase/Postgres com pgvector para o dicionário de de-para de produtos + Claude (Vision para extração, texto para classificação) + Lovable para o painel de revisão e fila + Evolution/ChatVolt no WhatsApp.

---

## App 2 — `robo-portais-convenios` — Robô de Solicitação e Follow-up em Portais sem API

**Dor:** a clínica tem os dados prontos e padronizados, mas alguém precisa entrar manualmente em cada portal de convênio, logar, cadastrar procedimento por procedimento e, todo fim de dia, voltar em todos os portais para descobrir o que foi autorizado, negado ou está pendente. O custo é o tempo de operação de interface, não o entendimento do dado.

**Canvases:** [1] (Llanna) — 1 canvas, 1 empresa.

App com um único canvas por trás, o que a metodologia só permite quando a dor é inequívoca — e é: o processo está descrito ponta a ponta, o operador é identificável (faturamento/autorização de clínicas) e o padrão "portal obrigatório sem API" se repete muito além de convênios (prefeituras, distribuidoras, portais de compras públicas, transportadoras). O motor de RPA que sai daqui é o mesmo que atende o App 1 quando o ERP do cliente não tem API, e é por isso que ele vale como produto separado em vez de virar um nó escondido no extrator.

**Funcionalidades do MVP:**
1. Cadastro de portais com credenciais em cofre (nunca em variável de fluxo), um conjunto por unidade/clínica.
2. Gravação de roteiro por portal: mapa de seletores e passos (login, buscar beneficiário, preencher procedimento, anexar guia, submeter, capturar protocolo).
3. Fila de solicitações a partir de planilha/CSV padronizado ou de `doc-extraction-event`, com validação de campos obrigatórios antes de abrir o navegador.
4. Execução headless com Playwright, uma sessão por portal, com retry e backoff; falha de seletor abre incidente em vez de seguir adiante.
5. Evidência obrigatória por submissão: protocolo capturado + screenshot da tela de confirmação, guardados junto do registro.
6. Varredura de status agendada (fim do dia e sob demanda) em todos os portais, com diff do que mudou desde a última passada.
7. Painel por solicitação (pendente / autorizada / negada / exige documento) com filtro por convênio, e alerta no WhatsApp/e-mail do responsável quando algo é negado ou vence prazo.
8. Trilha de auditoria completa: quem pediu, o que o robô enviou, o que o portal respondeu, quando.

**Fora do MVP:** qualquer juízo clínico sobre o procedimento (o robô transcreve e submete, não decide indicação nem contesta glosa por mérito); recurso automático de negativa; faturamento e conciliação de repasse; resolver captcha ou 2FA de portal que exija — nesses casos o fluxo para e chama o humano; integração TISS via padrão XML (fase 2, quando o convênio suportar, o RPA deixa de ser necessário para ele).

**Contratos que emite:** `portal-task-event` *(novo — submissão em portal externo sem API: portal, referência de credencial, payload enviado, protocolo devolvido, status atual, evidência, timestamps)*
**Contratos que consome:** `doc-extraction-event`

**Stack:** n8n para orquestração e agendamento + Playwright em container próprio para a execução do navegador + Supabase/Postgres para fila, status e evidências (screenshots em storage) + cofre de segredos (Doppler/Infisical ou secrets do Supabase) + Lovable para o painel + Claude apenas para leitura de tela ambígua e normalização de mensagens do portal.

---

## RESUMO JSON

```json
{
  "group_ids": [19],
  "apps": [
    {"id": "extrator-pedidos-erp", "nome": "Extrator & Lançador de Pedidos de Venda no ERP", "dor": "Pedidos chegam em PDF/foto/e-mail fora de padrão e alguém digita item a item no ERP; quem recebe pedido estruturado aprova um a um sem critério explícito", "canvases_indices": [0, 2, 3], "n_canvases": 3, "n_empresas": 2, "funcionalidades_mvp": ["Inbox multicanal (WhatsApp, e-mail IMAP, upload) normalizado em documento recebido", "Classificação do arquivo antes da extração (pedido novo, alteração, comprovante, ruído)", "Extração com Claude Vision contra schema JSON estrito com confiança por campo", "De-para de código de produto por dicionário aprendido + busca fuzzy/semântica, sem inventar item", "Painel de revisão lado a lado (documento x campos) com correção que realimenta o de-para", "Régua de auto-aprovação por regras versionadas (confiança, valor, cliente recorrente, item conhecido) com sugestão explicada", "Lançamento no ERP via API com idempotência e devolução do número do pedido ao remetente", "Painel operacional: fila por status, tempo documento-ERP, taxa sem toque humano, itens que sempre falham"], "fora_mvp": ["Negociação de preço/desconto com o cliente", "Conversa aberta no canal do cliente", "Cancelamento/alteração de pedido já lançado", "Separação, faturamento e logística", "ERPs sem API (escopo do robo-portais-convenios)", "Modelo próprio treinado para aprovar/rejeitar pedidos"], "contratos_emite": ["doc-extraction-event", "order-event"], "contratos_consome": ["customer-360-read"]},
    {"id": "robo-portais-convenios", "nome": "Robô de Solicitação e Follow-up em Portais sem API", "dor": "Dados já padronizados, mas alguém precisa logar em cada portal de convênio, cadastrar procedimento a procedimento e varrer todos os portais todo dia para saber o status", "canvases_indices": [1], "n_canvases": 1, "n_empresas": 1, "funcionalidades_mvp": ["Cadastro de portais com credenciais em cofre, por unidade", "Gravação de roteiro por portal (login, busca, preenchimento, anexo, submissão, captura de protocolo)", "Fila de solicitações a partir de CSV padronizado ou de doc-extraction-event, com validação prévia", "Execução headless em Playwright com retry/backoff; falha de seletor abre incidente", "Evidência obrigatória por submissão: protocolo + screenshot de confirmação", "Varredura de status agendada em todos os portais com diff do que mudou", "Painel por solicitação com alerta ao responsável em negativa ou prazo vencendo", "Trilha de auditoria: quem pediu, o que foi enviado, o que o portal respondeu, quando"], "fora_mvp": ["Qualquer juízo clínico sobre o procedimento", "Recurso automático de negativa", "Faturamento e conciliação de repasse", "Portais com captcha/2FA obrigatório (para no humano)", "Integração TISS via XML"], "contratos_emite": ["portal-task-event"], "contratos_consome": ["doc-extraction-event"]}
  ],
  "reclassificacoes": [],
  "ruido": [],
  "excluir": []
}
```