⚡ AutomationsAI|Portal de Cursos →

Verificando acesso...

MÓDULO 3.3

📘 Construção do playbook

Transformar processo + RTs em playbook estruturado de 6 campos. Cenários happy + exceções, few-shot real do histórico, tom de voz, revisão viva.

6
Tópicos
50
Minutos
Aplic.
Nível
Doc
Tipo
1

🧩 Estrutura de 6 campos

Cada cenário do agente vira uma linha do playbook com 6 campos. Estruturado vira mapa-fonte do system prompt da fase I.

Os 6 campos por cenário

  • Entrada: o que o cliente disse / ação que dispara
  • Processo: passos que o agente executa
  • Critério: quando esse cenário aplica
  • Saída: resposta padrão do agente
  • Exemplos: 3-5 reais do histórico
  • Regras: RT-XX aplicáveis

💡 Por que estruturado

Playbook narrativo vira monólogo. Estruturado em planilha, cada linha é um cenário. Você importa direto pro system prompt na fase I.

2

🎯 Cenários do caminho feliz — 80%

Lista 8-15 cenários que cobrem 80% do volume. Ordenados por frequência. Cada um vira linha do playbook.

✓ Cenário bem definido

  • • "Cliente pede cotação de SKU em estoque"
  • • "Cliente confirma pedido via PIX"
  • • "Cliente novo solicita catálogo"
  • • "Cliente pergunta prazo de entrega"

✗ Cenário mal definido

  • • "Cliente faz pedido" (vago)
  • • "Atendimento" (genérico)
  • • "Diversos" (catch-all)
  • • "Outros casos" (preguiça)

📊 Pareto: 80/20

8-15 cenários cobrem 80% do volume. Tentar cobrir 100% torna playbook intratável e bateria de teste infinita. 80% é alcançável e suficiente pro MVP.

3

⚠️ Cenários de exceção — 20% que escalam

Os 20% restantes NÃO viram resposta do agente — viram gatilho de escalação. Lista explícita com pra quem encaminhar.

🚨 Pedido grande (> R$ 5k)

Gatilho: valor > threshold. Encaminhar: gerente comercial. Mensagem padrão: "Estou encaminhando para nosso gerente, ele retorna em até 30 min."

💔 Reclamação séria

Gatilho: palavras "cancelar", "reclamar", "processo", "tribunal". Encaminhar: sócio. Resposta: "Levei sua mensagem para a direção, retorno em 2h útil."

❌ Pedido fora de escopo

Gatilho: produto que empresa não vende. Resposta: "Esse produto não faz parte do nosso catálogo atual. Quer que eu te recomende algum similar?"

⚡ Baixa confiança do modelo

Gatilho: agente não tem certeza. Resposta: "Deixa eu verificar essa informação com o time, retorno em poucos minutos." + escala.

🎚️ HITL definido aqui

Cada exceção tem nível HITL (N1-N4) atribuído. Aqui se define se IA decide e humano audita, ou se humano decide e IA propõe. Detalhes em T3.4.

4

📚 Exemplos few-shot por cenário

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

📖 Exemplo Polaris — Cenário "cotação SKU"

Cliente: Bom dia, quanto tá a cerveja Heineken 600ml?
Resposta: Bom dia, Sr. José! 🍺 Heineken 600ml está R$ 8,90 unidade ou R$ 213 a caixa com 24. Quer fechar quantidade?

✓ Few-shot real anonimizado

  • • Extraído do histórico
  • • Nomes alterados
  • • Captura o tom real
  • • Operador valida

✗ Few-shot inventado

  • • Tom corporativo
  • • Linguagem da consultoria
  • • Sem gírias do setor
  • • Vira chatbot genérico

💡 Few-shot é fine-tuning sem fine-tune

Exemplos reais carregam tom, vocabulário, ritmo da empresa. Agente "aprende" sem precisar treinar modelo. É o 2º maior alavanca de qualidade depois do RAG.

5

🗣️ Tom de voz e persona

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

Exemplo Polaris (distribuidora)

  • • Nome: "Polari"
  • • Tom: casual brasileiro
  • • Emoji: 1-2 por mensagem (🍺 🍻 ✅)
  • • Tratamento: "você" (não "senhor")
  • • Gírias OK: "fechou", "blz", "valeu"
  • • Saudação: "Bom dia, [nome]!" antes 12h

Exemplo Contábil (escritório formal)

  • • Nome: "Beatriz" (humanizado)
  • • Tom: formal-amigável
  • • Emoji: nenhum ou só ✅
  • • Tratamento: "Sr./Sra. [sobrenome]"
  • • Gírias: nenhuma
  • • Saudação: "Prezado(a) Sr./Sra. [Nome]"

⚠️ Tom errado quebra confiança

Cliente Polaris recebendo mensagem formal acha que é golpe. Cliente contábil recebendo "blz, fechou!" perde confiança. Tom é validado por amostragem real com o operador.

6

🔁 Revisão viva, não SOP

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

1

Versionamento semver

v1.0 inicial → v1.1 ajustes pós-validação → v2.0 após 30 dias com aprendizado real. Cada versão tem changelog.

2

Revisão mensal na manutenção

Cada visita mensal de manutenção: 30 min lendo overrides do mês, identificando novas RTs, atualizando cenários. Sai com v.X+1.

3

Changelog explícito

"v1.3: adicionada RT-19 (cliente Glória aceita pedido por SMS). Removida RT-04 (regra obsoleta após mudança de tabela)."

🔄 Realidade muda

Cliente novo aparece. Regra tácita nova surge. Lei muda. Mercado muda. Playbook precisa absorver — caso contrário envelhece e agente vira datado.

📘 Resumo do módulo

6 campos por cenário. Entrada · processo · critério · saída · exemplos · regras. Estruturado vira system prompt na fase I.
8-15 cenários happy (80% do volume). Pareto. Bem definidos, não vagos.
20% restantes = exceções com escalação. Pedido grande, reclamação, fora de escopo, baixa confiança. Lista explícita.
Few-shot real, 3-5 por cenário. Extraído do histórico, anonimizado, validado por operador. Fine-tuning sem fine-tune.
Tom e persona consistentes. Nome do agente · emoji · tratamento · gírias. Validado por amostragem real.
Playbook é vivo, versionado. v1 → v2 → v.X+1. Revisão mensal. Changelog explícito.

Próximo módulo:

3.4 — Design do fluxo com IA · onde IA entra · matriz HITL em 4 níveis · gatilhos de escalonamento · plano de integrações.