Playbook de vendas que o agente de IA lê antes de responder

Um agente de IA de vendas parece inteligente até o momento em que responde algo que ninguém autorizou. Em times B2B com operação enxuta, o problema quase nunca está no modelo: está na ausência de um playbook escrito que o agente possa consultar. Sem esse documento, o robô preenche lacunas com plausibilidade, e plausibilidade em vendas custa margem. Este texto mostra a mecânica de treinar o agente com o playbook da empresa, o que acontece quando isso falta e um roteiro de quatro horas para escrever a primeira versão.

O robô que inventa versus o SDR que sabe o que pode prometer

A diferença entre um agente que ajuda e um agente que cria problema não é tecnológica. É documental. Um SDR humano com três meses de casa sabe que não pode oferecer 20% de desconto sem aprovação do gestor, que não atende empresa com menos de 50 funcionários no segmento industrial e que a integração com ERP só está disponível no plano Enterprise. Esse conhecimento não está na cabeça do modelo: está no playbook da empresa.

Quando o playbook existe e é publicado como texto puro num índice de conhecimento, o agente consulta a resposta antes de gerar a frase. Quando não existe, ele responde com base no que parece razoável para uma empresa de software B2B. E o que parece razoável quase sempre inclui desconto, prazo elástico e escopo maior do que o comercial pode entregar.

O ponto central é que a IA não substitui o critério comercial. Ela executa o critério que foi escrito. Se o critério está na cabeça do fundador e não no papel, o agente não tem como adivinhar. A discussão sobre o que já é realidade em IA de vendas B2B passa por aqui: a parte difícil não é plugar o modelo, é ter a operação documentada.

A mecânica: treze seções fixas e um índice de conhecimento

O playbook que o agente lê não é um PDF de 80 páginas com fotos de time. É um documento estruturado em treze seções fixas, cada uma respondendo a uma pergunta que o agente vai encontrar em conversa. A estrutura fixa importa porque permite versionamento e porque facilita a consulta por embeddings: cada seção vira um bloco de texto independente, indexado com seu próprio vetor.

As treze seções que sustentam a operação são, na prática:

• O que vendemos: descrição do produto ou serviço em linguagem de cliente, não de engenharia.
• Para quem não vendemos: critérios de exclusão explícitos, com exemplos de perfis recusados.
• ICP e sinais de fit: porte, setor, cargo, tecnologia instalada e gatilhos de compra.
• Problema que resolvemos: a dor em palavras do comprador, não do vendedor.
• Alternativas do mercado: como o cliente resolve hoje sem nós, incluindo planilha e estagiário.
• Proposta de valor por persona: sócio, gestor comercial e TI ouvem coisas diferentes.
• Prova social: cases, números, nomes de clientes autorizados e setores atendidos.
• Objeções e respostas: as dez objeções mais frequentes com a resposta aprovada.
• O que podemos prometer: limites de desconto, prazo, escopo e SLA.
• O que não podemos prometer: a lista negra explícita, com o motivo de cada item.
• Processo comercial: etapas do funil, critérios de avanço e quem aprova o quê.
• Rotina do vendedor: cadência, ferramentas, horários e rituais de pipeline.
• Tom de voz e tratamento: como escrever para cada persona, o que evitar.

Cada revisão publicada do playbook vira texto puro, dividido por seção, e entra num índice de conhecimento. O agente não lê o playbook inteiro a cada mensagem: ele consulta o índice por similaridade semântica (embeddings) e recupera os trechos mais próximos da pergunta do lead. Se o lead pergunta sobre prazo de implantação, o agente recupera a seção de escopo e SLA, não a de prova social.

Essa arquitetura tem uma consequência prática importante: seção desatualizada gera resposta desatualizada. Por isso o playbook precisa ser um documento vivo, revisado a cada ciclo comercial. Quem já tentou manter playbook em PDF congelado sabe como isso termina. O artigo sobre como construir um playbook de vendas B2B do zero detalha a parte de conteúdo; aqui o foco é a camada de leitura pela IA.

O caso concreto: desconto que ninguém autorizou

Uma empresa de serviços B2B com 12 vendedores decidiu testar um agente de IA para qualificação no WhatsApp. O time não tinha playbook escrito: as regras viviam na cabeça do head comercial e em mensagens soltas no grupo. O agente foi configurado com o site institucional e um PDF de apresentação comercial de 2024.

Na segunda semana, um lead perguntou se havia desconto para pagamento anual. O agente respondeu que sim, havia 15% de desconto para contrato anual, com condição especial para fechamento no mês. O problema: a política vigente era 8%, e o desconto de 15% havia sido uma promoção pontual de dois anos antes, ainda publicada no PDF antigo. O vendedor só descobriu quando o lead cobrou a promessa na call de fechamento.

O custo não foi só o desconto. Foi a negociação travada, o lead desconfiado e o tempo do gestor explicando o que não podia ser cumprido. Depois do episódio, a empresa escreveu o playbook em três tardes, separou a seção de limites comerciais e configurou o agente para responder "preciso confirmar com o time" sempre que a pergunta tocasse em desconto fora da tabela. Em 30 dias, o volume de respostas fora de política caiu para praticamente zero, segundo relato do próprio gestor.

Esse tipo de erro é previsível quando o agente não tem fonte confiável. O mesmo mecanismo aparece em outras frentes: priorização de leads sem critério documentado, como no ICP Fit Score para priorizar leads com IA, também produz decisão aleatória. O documento é o que transforma intenção em regra.

Por que embeddings e não busca por palavra-chave

Um lead raramente pergunta com as palavras do playbook. Ele escreve "dá para começar mês que vem?" e não "qual o prazo de implantação?". Busca por palavra-chave falha nesse caso; busca por similaridade semântica encontra a seção de prazo porque entende que as duas frases tratam do mesmo assunto.

Na prática, o fluxo é assim: a mensagem do lead é convertida em vetor, o índice devolve os três ou cinco trechos mais próximos, e o modelo gera a resposta condicionado a esses trechos. Se o trecho recuperado não cobre a pergunta, o comportamento correto é o agente dizer que vai verificar, não improvisar. Essa regra de escape precisa estar explícita no prompt de sistema do agente, não só no playbook.

Vale um alerta de governança. O índice de conhecimento contém dados comerciais sensíveis: tabela de desconto, lista de clientes, limites de negociação. O acesso precisa ser controlado, e o log de consulta precisa existir. Quem opera com ética e LGPD no uso de IA em vendas B2B já sabe que dado pessoal de lead não deve entrar no playbook sem base legal e sem política de retenção.

O roteiro de quatro horas para a primeira versão

A primeira versão do playbook não precisa estar perfeita. Precisa existir. O roteiro abaixo foi desenhado para ser executado por uma pessoa, em uma tarde, com o head comercial disponível para 40 minutos de validação no final.

1. Hora 1, o que vendemos e para quem não vendemos. Escreva a descrição em linguagem de cliente e liste cinco perfis que a empresa recusa. A lista de recusa é mais importante que a de aceite, porque é onde o agente costuma errar.
2. Hora 2, objeções e limites comerciais. Levante as dez objeções mais comuns em calls gravadas ou no CRM. Para cada uma, escreva a resposta aprovada. Em seguida, escreva a seção de limites: desconto máximo, prazo mínimo, escopo que não entra.
3. Hora 3, prova social e personas. Selecione três cases com número e autorização de uso. Descreva a proposta de valor para cada persona do comitê de compra, que no B2B raramente é uma só.
4. Hora 4, processo e rotina. Documente as etapas do funil com critério de avanço, a cadência padrão e a rotina diária do vendedor. Valide com o head comercial e publique a versão 1.0.

Quatro horas produzem um documento incompleto, mas utilizável. A partir daí, o playbook entra em ciclo de revisão mensal, e cada revisão publicada atualiza o índice. Times que operam com agente de IA e playbook versionado tendem a relatar menos retrabalho de negociação e onboarding mais rápido de vendedor novo. A relação entre documentação e produtividade do time aparece também em como escalar SDR e BDR em SaaS sem explodir o CAC: sem processo escrito, escalar significa multiplicar improviso.

O que fazer depois da primeira versão

Com o playbook publicado e o agente lendo o índice, o trabalho passa a ser de manutenção e medição. Três métricas ajudam a saber se o agente está ancorado no documento: percentual de respostas que citam trecho recuperado, taxa de perguntas que caem na regra de escape e volume de correções feitas por humano depois da resposta do agente.

Quando a taxa de escape sobe, geralmente é sinal de que o playbook tem lacuna, não de que o modelo piorou. A resposta certa é escrever a seção que falta, não trocar a ferramenta. Esse é o mesmo raciocínio do arranjo em que a IA rascunha e o humano aprova: o documento dá o limite, o humano dá o aval e o agente ganha velocidade dentro de um trilho conhecido.

Conclusão

Agente de IA em vendas B2B não fica confiável por ajuste de prompt. Fica confiável quando a empresa escreve o que pode e o que não pode ser prometido, publica isso como texto consultável e mantém o documento atualizado. As treze seções fixas não são burocracia: são a diferença entre um robô que inventa desconto e um SDR digital que sabe o limite da casa.

O roteiro de quatro horas é o primeiro passo. O segundo é tratar o playbook como produto interno, com dono, versão e ciclo de revisão. Sem isso, o agente volta a improvisar na primeira pergunta que o documento não cobre.