⚙️ Processar

Caixas para passos, setas para fluxo, swimlanes (cliente / operador / sistema) para responsável. Sem decisão losango, sem evento círculo. Cliente PME lê.

BPMN puro fica acadêmico — dono não lê. Notação simples vira material de validação com o cliente.

Whimsical/Miro/Excalidraw · 3 swimlanes max · 8-15 caixas · revisão presencial.

Cada caixa é uma ação concreta com responsável e duração medida. Não "atender cliente" (raso). Não "abre WhatsApp 3s" (ultra-fino).

Granularidade errada quebra o mapa — fica abstrato demais ou minucioso demais pra agente entender.

Ação concreta · responsável único por caixa · tempo médio anotado.

Desenha primeiro o caminho feliz (80%). Depois cataloga exceções (20%) como branches. Não tenta caber tudo num mapa só.

Cliente entende o feliz. Operador valida as exceções. Os dois materiais juntos formam a base do agente.

Caminho principal · branches separados · catálogo de exceção numerado.

Mapeia primeiro como o processo realmente acontece HOJE (as-is), depois desenha como ficará COM IA (to-be). Cliente assina os dois.

Pular as-is e ir direto pro to-be é o que cria projeto desconectado da realidade do cliente.

As-is é fato · to-be é proposta · cliente compara visualmente.

Para cada caixa do mapa, anote o volume mensal (quantas vezes acontece). Mostra onde dói mais — onde está o gargalo.

Define onde a IA entra primeiro. Caixa de baixa volumetria = baixo ROI, mesmo se for "interessante".

Volume mensal · tempo médio · custo total · ponto de automação.

Imprime o mapa, senta com o operador, percorre caixa por caixa: "isso é assim mesmo?". Operador corrige, anota exceções.

Mapa não validado pelo operador = mapa fictício. Agente vai colidir com realidade no deploy.

Validação presencial · revisão papel · operador acrescenta · v2 final assinado.

Conhecimento operacional não escrito em manual nenhum. "Cliente X sempre paga 7 dias atrasado", "produto Y nunca vende em jul", "Sr. Roberto não atende após 18h".

Tácito ignorado vira sabotagem em deploy. Operador sabota agente que viola regras que ele aplica há anos.

RT-01 a RT-NN · cada regra catalogada · responsável + contexto + ação.

Sessão dedicada com operador. Você pergunta "e quando acontece X?" "e quando o cliente faz Y?". Captura as exceções uma por uma.

Operador nunca senta sozinho pra escrever regras. Tem que ser sessão dirigida pelo implementador.

Pergunta direcionada · gravador · template de RT pronto · iteração na semana seguinte.

Tácito se organiza em 4-5 categorias: regras por cliente, regras por produto/SKU, regras por horário/data, regras de pagamento, regras de exceção.

Categoria guia a extração — sem ela você esquece de perguntar sobre 1-2 dimensões inteiras.

5 categorias padrão · checklist por categoria · review iterativo.

Exporta histórico do WhatsApp dos últimos 90 dias. Lê 50-100 conversas. Identifica padrões repetidos que viram regras.

Operador esquece de citar regra na sessão — mas a regra está aplicada no histórico. Dado revela tácito esquecido.

Export WhatsApp · análise manual ou com LLM · padrões viram RT.

Lista de termos internos: "pedido coringa", "cliente top", "bonificação", "devolução parcial". Cada termo com definição operacional.

Agente sem glossário responde fora do vocabulário da empresa. Cliente recebe "linguagem estranha".

20-50 termos · definição operacional · sinônimos · uso no system prompt.

Operador lê cada RT escrita por você e confirma: "sim, é assim" ou "não, é diferente, é X". RT só vira definitiva após confirmação.

Sua interpretação ≠ regra operacional. Confirmação evita que agente vire ficção.

Lista impressa · revisão linha por linha · ajuste imediato.

Cada cenário do agente tem: entrada (o que cliente disse) · processo (passos) · critério (quando aplica) · saída (resposta) · exemplos (3-5) · regras aplicáveis (RT-XX).

Sem estrutura, playbook vira monólogo. Estruturado, é mapa-fonte do system prompt da fase I.

6 campos · 1 cenário = 1 linha · revisão em planilha.

Para o processo escolhido, lista 8-15 cenários que cobrem 80% do volume. Cada um vira linha do playbook.

Tentar cobrir 100% torna playbook intratável. 80% é alcançável e suficiente pro MVP.

Pareto 80/20 · análise de histórico · ordenação por volume.

Os 20% restantes que o agente NÃO trata sozinho — escalam para humano. Lista de gatilhos de escalação.

Define HITL antes do prompt. Agente sem escalação clara vai inventar resposta ou recusar atendimento.

Gatilhos explícitos · template de escalação · responsável humano.

Para cada cenário, 3-5 exemplos REAIS (do histórico do WhatsApp) com entrada do cliente + resposta ideal do operador.

Few-shot real é o melhor "fine-tuning sem fine-tune". Agente aprende o tom da empresa.

Exemplo > descrição · dado real anonimizado · revisão pelo operador.

Define tom (formal/casual), uso de emoji, gírias permitidas, saudação, tratamento (você/senhor), nome do agente.

Tom errado quebra confiança. Cliente percebe "isso não é o vendedor da Polaris" e abandona.

Persona consistente · alinhada à marca · validada por amostragem.

Playbook não é SOP fechado. É documento vivo que atualiza com aprendizado pós-deploy. Versionar cada atualização.

Realidade muda. Cliente novo aparece. Regra tácita nova surge. Playbook precisa absorver.

Versionamento · changelog · revisão mensal na manutenção.

3 padrões: IA na 1ª linha (recebe tudo, escala exceções), IA na triagem (categoriza, encaminha), IA no fim (resume, registra).

Padrão errado quebra adoção. 1ª linha exige mais robustez; triagem é mais segura pra começar.

3 padrões canônicos · escolha por risco · iniciar com triagem.

N1 Observação · N2 Sugestão · N3 Execução com gate · N4 Autônomo com auditoria. Cada cenário é classificado por risco e recebe um nível.

HITL é o que separa projeto sério de "deploya e reza". Define responsabilidade legal e operacional.

4 níveis canônicos · risco × volume · iniciar conservador.

Lista explícita de gatilhos: pedido > R$ X, cliente inadimplente, palavra-chave "cancelar/reclamar", baixa confiança do modelo, exceção catalogada.

Sem gatilhos, agente inventa ou trava. Lista explícita garante previsibilidade.

Gatilhos quantitativos + qualitativos · roteamento · canal de handoff.

Quando o agente não sabe responder, não inventa. Diz "vou encaminhar para um atendente" e cria ticket. Sempre tem caminho de saída.

Fallback claro é o que evita o pior cenário — alucinação que custa pedido errado.

Frase de fallback · ticket automático · notificação humano.

Documenta as integrações necessárias: WhatsApp Cloud API, Bling/Omie REST, Supabase pgvector, NF-e via Bling, PIX via Asaas. Cada uma com escopo e credenciais.

Integração não validada em P vira surpresa em A. "API X não tem endpoint Y" descoberto em deploy é caro.

Lista de APIs · escopo de cada · credenciais provisionadas · 1 chamada real testada.

Relatório de Impacto à Proteção de Dados enxuto (1-2 páginas) para microempresa: que dado coleta, base legal, retenção, direitos do titular.

LGPD não é opcional. RIPD enxuto cumpre ANPD 2/2022 e protege cliente em caso de incidente.

Template enxuto · base legal · retenção · direitos do titular · revisão anual.

Reunião presencial de 60-90 min com dono e champion. Você apresenta mapa, regras, playbook, design HITL. Eles revisam, corrigem, aprovam.

Validação por escrito não pega nuance. Presencial gera correção viva e compromisso.

60-90 min · ambos presentes · 3 cenários walkthrough · ajuste registrado.

Você simula 3-5 conversas reais usando o playbook: "imagina que o cliente Bar do Zé manda essa mensagem — agente responde X com base na RT-07".

Walkthrough captura ajustes que leitura de playbook não pega. Dono ouve a resposta e vê o que falta.

Simulação concreta · 5 cenários · ajuste em tempo real.

Cada ajuste solicitado vira correção no playbook no mesmo dia. V2 enviado para cliente em 24h.

Adiar correção é convite a esquecer. Cliente quer ver "executei o que pediu".

Mesmo dia · V2 em 24h · changelog explícito.

Conversas individuais com operadores afetados pelo projeto. Cada um sabe seu novo papel: champion · revisor · supervisor.

Pessoas sem clareza de novo papel sabotam projeto. Conversas no dia zero blindam contra resistência.

Conversa individual · novo papel claro · zero demissão.

Faz 1 chamada real para cada API: GET produto no Bling, GET cliente no Omie, GET conversa no WhatsApp. Comprova credenciais e escopo.

"API funciona" no papel ≠ na realidade. Bug de credencial em deploy custa 2-3 dias.

1 chamada real por API · log do retorno · screenshot.

Cliente assina termo de aprovação do Pacote de Contexto. Sem assinatura, não entra em I — porque mudanças posteriores no contexto custam muito.

Escopo fechado por assinatura. Mudança depois = aditivo contratual, não trabalho de boa vontade.

ZapSign / DocuSign · 1 página · escopo congelado.

(1) Mapa as-is/to-be · (2) Catálogo de regras tácitas (RT-01..NN) · (3) Glossário de termos · (4) Playbook estruturado · (5) Plano de integrações + RIPD.

Os 5 documentos juntos = input completo pra fase I. Faltando qualquer um, agente sai com falha estrutural.

5 documentos · pasta padrão · controle de versão · cliente recebe cópia.

(1) Pacote completo · (2) Aprovação assinada · (3) Integrações validadas em chamada real · (4) RIPD pronto · (5) Conversas de reposicionamento concluídas.

Avançar pra I sem isso é tentativa-e-erro de 8 semanas em vez de execução de 4.

5 itens checados · revisão antes de mudar fase · documentação.

/cliente/01-diagnostico · /02-pacote-contexto · /03-instrucao · /04-deploy · /05-manutencao. Estrutura igual em todos os clientes.

Cliente 5+ vira impossível sem padrão. Padrão também ajuda colega na consultoria a continuar seu trabalho.

Estrutura idêntica · drive compartilhado · backup local.

Cada atualização do Pacote ganha versão e changelog. V1 = inicial. V2 = pós validação. V3+ = manutenção mensal.

Auditoria interna do cliente ou ANPD pode pedir histórico. Versão protege.

Semver simples · changelog escrito · arquivo do antigo preservado.

Briefing para você mesmo (ou colega de consultoria): "este Pacote tem 18 RTs, 8 cenários happy, 4 escalações, integrações com Bling+WABA". Pronto pra system prompt.

Briefing escrito força síntese — você descobre se algo está faltando antes de gastar 2 dias em I.

1 página · síntese executiva · gaps explícitos.

Fase P leva 2-3 semanas em PME média. 1 semana só funciona em micro com 1 processo simples. Esticar além de 4 perde momentum.

Subestimar P quebra cronograma do projeto inteiro. Cliente expecta entrega rápida, mas qualidade exige tempo.

2-3 semanas norm · 4 max · comunicar cronograma claro ao cliente.