Agente de IA para SDR: como automatizar a pré-qualificação de atendimento

Gestores de atendimento e comercial me procuram com a mão já levantada: o lead chegou no WhatsApp, no form ou no chat do site, e o closer está afogado em reunião sem fit. Quando a gente desenha um agente de IA para SDR, o job não é caçar lista: é, pois, automatizar a pré-qualificação de atendimento de quem já pediu conversa. Percebi, em diagnósticos, que o mercado brasileiro chama de SDR qualquer modelo colado ao canal. No entanto, se a peça só conversa e nenhum campo de BANT/FIT, score ou etapa muda no CRM, não é SDR — é chatbot no mesmo canal.

Este texto, portanto, é how-to de implantação inbound: intenção, critério, writeback, handoff e recusa. Em outras palavras, recorto o que fica fora — definição geral de agente, cadência fria e tutorial de plataforma de mensagens. Em suma, escrevo para quem já decidiu pré-qualificar e precisa do desenho, não do slogan.

O que um agente de IA faz (e não faz) no papel de SDR de atendimento

O rótulo “SDR de IA” virou atalho de proposta. Por isso eu começo pelo job, não pela vitrine. No atendimento inbound, o papel é estreito e auditável: capturar quem já chegou, aplicar o critério comercial, gravar a ficha e só então marcar o closer — ou recusar. Quem busca a definição geral, fora deste recorte de pré-vendas, encontra em o que é um agente de IA. Aqui aplico a mesma distinção à fila comercial que nasce no atendimento.

Não é um chatbot com nome de vendedor

Chatbot e agente não são o mesmo objeto com branding diferente. Chamar de agente de IA para SDR um fluxo que só completa a frase e diz “vou te passar para o comercial” é o erro mais caro que eu vejo em RFP. Contudo, o primeiro conversa: responde, coleta e direciona. Assim, já o segundo conclui um objetivo — ficha BANT/FIT preenchida, score no CRM, reunião com identificador ou recusa com motivo. Por isso, quando implementei diagnósticos em operações brasileiras, percebi o mesmo deslize: o slide diz “SDR”, o fluxo só gera parágrafo.

Além disso, a analogia que uso com o time é simples. Recepcionista anota o recado; pré-vendas pergunta o que importa, grava a ficha e só marca o closer se a ficha fecha. Além disso, sem o comprovante no sistema, não houve pré-qualificação de atendimento. Todavia, o mercado insiste em fundir os dois porque o canal é o mesmo e o modelo parece inteligente. Eu recuso, portanto, essa fusão. Por conseguinte, a primeira pergunta que faço em kickoff não é qual modelo usar, e sim o que muda no CRM quando a conversa termina.

Texto plausível não prova tarefa. Por exemplo, ainda, um menu bem desenhado continua útil para intenção curta. Porém menu não vira SDR porque ganhou um parágrafo eloquente no final. Dessa forma, a diferença operacional — chatbot versus agente que executa — está no texto de o que é um agente de IA para atendimento (chatbot vs agente); não redefino o vocabulário aqui. Afinal, aplico o teste ao papel comercial.

Três modos, um teste no CRM

O job é pré-qualificar quem já chegou — não prospectar lista

Inbound é o recorte deste artigo. Lead já levantou a mão: form, WhatsApp, chat do site, ligação. Portanto o agente não caça cadência, não raspa perfil e não finge ser humano numa caixa de entrada fria. Assim, quando a gente desenha a pré-qualificação de atendimento, o volume que importa é o que já pediu conversa e está esfriando na fila. Por isso, percebi que a SERP mistura os dois mundos — sequenciador de e-mail e triagem de atendimento — e o comprador sai comparando preço de produto errado. No entanto, o modo de falha de cada um é outro. No entanto, outbound autônomo queima reputação e reunião vazia; inbound mal desenhado queima o closer com “SQL” que era suporte ou estudante. Por isso eu recorto: este how-to para no transbordo para o comercial. Além disso, cadência fria fica para outro texto.

Também recorto o go-live de quinze minutos. Semanas para o piloto começar, resultado mensurável em 60 a 90 dias: é o prazo que eu aceito em contrato de implementação. Dessa forma, o job fica honesto. Ou seja, o SDR de IA no atendimento pergunta, grava e decide rota. Não substitui o time. Tampouco fecha a venda.

O closer continua fechando; o agente recusa o que não é SQL

Fechar continua humano. Em seguida, recomendo essa linha no primeiro workshop, antes de qualquer script. Afinal, o closer herda discovery, comitê, objeção e proposta; o agente de IA para SDR herda volume repetível de triagem. Aliás, na prática, recusar o que não é SQL é tão importante quanto agendar o que é. Contudo, descobri, em filas que “não queriam perder lead”, que reunião sem fit ensina o comercial a sabotar o projeto na terceira semana. Por outro lado, recusa educada com motivo no CRM protege agenda e reputação. Assim, o híbrido que eu defendo é simples: o agente escala juízo só quando o critério fecha; abaixo disso, nurture ou N2 de atendimento. Em suma, o closer não deveria receber “talvez”.

Contrato SAL — o que marketing e vendas aceitam como SQL — entra no desenho, não no slide posterior. Por isso, hubSpot trata SQL como conversa, não como formulário preenchido; eu levo isso para o piloto. Ademais, desqualificar deixa de ser falha e passa a ser feature. Por conseguinte, o indicador que o comprador deveria olhar não é “reuniões marcadas”. No entanto, é SQL que o closer aceita na primeira conversa.

Como o agente captura intenção e aplica BANT ou FIT

Intenção vem antes do interrogatório. Além disso, quando a gente desenha o agente de IA para SDR, o primeiro passo do turno não é perguntar budget: é classificar o que o lead pediu. Orçamento, demo, “vocês atendem X?Por exemplo, ”, suporte disfarçado de venda, spam. Dessa forma, confiança baixa ou “quero gente” vira transbordo, não improviso. Em seguida entra o gate de ICP. Em seguida, só depois — e fora de ordem — o layer 1 de BANT ou FIT, em conversa de três a oito minutos. Afinal, mEDDIC e GPCT ficam para o closer. Dessa forma, o volume não estrangula e o discovery humano não vira checklist no primeiro “oi”.

Intenção primeiro (orçamento, demo, suporte disfarçado, fora de ICP)

Classificar intenção parece trivial até o primeiro áudio de quarenta segundos. Lead raramente fala “MQL inbound de produto Y”: escreve “quanto custa”, manda print do anúncio, mistura reclamação de boleto com pedido de proposta. Quando implementei essa camada, o erro típico foi treinar o classificador no vocabulário interno e medir acerto no laboratório. No entanto, o laboratório não contém ironia, dois assuntos no mesmo balão nem cliente antigo fingindo ser lead novo. Por isso eu leio CRM antes de qualificar. Se já é conta, oportunidade aberta ou ticket de suporte, a rota não é “SQL novo” — é dono da conta ou N2 de atendimento.

FIT de ICP (porte, segmento, geografia, produto) é o portão, não a conversa. Fora do ICP, o agente desqualifica com motivo escrito e encerra educado, ou manda para nurture. Também recuso a política de “agenda para não perder”. Assim, o closer deixa de herdar volume que o comercial nunca fecharia. Por exemplo, estudante, parceiro caçando material e empresa de outro país, quando o critério é Brasil, saem da fila comercial no mesmo turno. Em suma, intenção errada tratada como venda é o atalho que infla MQL e queima gente.

BANT em conversa, não em interrogatório (Budget, Authority, Need, Timeline)

BANT nasceu na IBM e o guia da HubSpot sobre BANT, atualizado em 31 de julho de 2025, ainda descreve o método como conversa no início do ciclo, não como formulário de doze campos. Budget, Authority, Need, Timeline. Recomendo extrair em linguagem natural, fora de ordem, ganhando o direito de perguntar. Percebi que oito perguntas seguidas na primeira fala matam o lead brasileiro no WhatsApp. No entanto, campo vazio no CRM também mata o closer. Por isso o scorecard que eu gravo usa o vocabulário da HubSpot: Qualified, Partially known, Unknown — em dropdown, não em nota livre.

Autoridade, no mesmo guia, é comitê, não uma pessoa. Budget é padrão de gasto, não só o número que o lead chuta no chat. Need precisa ser dor amarrada a produto, não “quero inovar”. Timeline vira data ou gatilho (“troca de sistema em outubro”), não “quando der”. Além disso, o agente jamais promete desconto, SLA ou escopo que não está na tool. Guardrail lista o que ele não assina. Dessa forma, BANT vira layer 1 extraível em três a oito minutos e gravável em campo. Ou seja, triagem, não discovery de AE.

Scorecard no CRM: Qualified, Partially known, Unknown

Score sem regra versionada vira opinião do modelo. Quando a gente desenha o limiar, o dono é o head comercial, não o estagiário de marketing. Um recorte operacional que eu uso em piloto — e trato como exemplo, não como norma de mercado — é SQL só com Need preenchido, FIT positivo e pelo menos um de Budget, Authority ou Timeline em Qualified. Abaixo disso, MQL para nurture ou descarte. Todavia, copiar o limiar de outra empresa sem baseline é chute. Por isso o critério entra no repositório de política, com data e autor, igual a uma regra de preço.

Completude dos quatro campos (ou do subset combinado) mede writeback, não eloquência. Ainda, Partially known é estado legítimo: o closer herda o buraco, não uma ficha maquiada. Por conseguinte, o agente não inventa budget para “fechar o card”. Log de cada pontuação — valor, regra, versão — serve ao piloto e, mais adiante, ao titular que pedir revisão. Assim, o score deixa de ser mistério no painel do fornecedor.

O que fica para o closer: MEDDIC e GPCT não cabem no primeiro “oi”

Layer 2 é call humana. O guia de qualificação da HubSpot, atualizado em 24 de junho de 2026, organiza o mapa: BANT para estágio inicial e ciclo curto; MEDDIC para enterprise e transformação (Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion, origem Jack Napoli na PTC); CHAMP quando a dor vem primeiro; GPCTBA/C&I para conversa consultiva. Eu recuso MEDDIC no primeiro “vi o anúncio”. Estrangula volume. Também recuso BANT até o close em deal de comitê: perde nuance. Portanto o agente faz layer 1; o closer faz layer 2. SAL, no mesmo guia, é o contrato entre marketing e vendas — ICP, contato válido, intent, sem oportunidade aberta. SQL, pois, pede conversa, não só form.

Em suma, a tabela é o mapa que eu levo ao workshop. Copiar GPCT completo para o agente inbound é o atalho que parece maduro e reduz conversa a zero. Por outro lado, deixar o closer reperguntar BANT inteiro no handoff é o outro extremo. Recomendo o meio: layer 1 gravado; layer 2 humano.

A arquitetura que separa SDR de texto: canal, orquestrador, CRM

Arquitetura de SDR inbound cabe em quatro caixas, sem nome de modelo. Canal entrega o envelope. Orquestrador aplica política, RAG comercial, tools e guardrails. CRM de registro — HubSpot, Pipedrive, Salesforce, RD Station ou equivalente brasileiro — guarda campos e IDs. Agenda, fila do closer, N2 ou nurture recebem a rota. Quando a gente desenha um agente de IA para SDR, o cérebro não mora no aplicativo de mensagens. Mora, portanto, na política versionada e no contrato das funções.

A pesquisa State of Sales 2026 da Salesforce, anúncio de 3 de fevereiro de 2026, com 4.050 profissionais em 22 países inclusive o Brasil, encontrou 51% dos líderes com IA dizendo que sistemas desconectados atrasam iniciativas. De acordo com o relatório, stand-alone agents without comprehensive customer context tend to fail: essa frase é o argumento do writeback. Não uso os 87% de adoção nem os 54% que já usaram agents como prova de SQL inbound. Trato como clima de mercado. O que transfere é, pois, higiene de dado.

O ciclo intenção, BANT, writeback e rota

O canal só entrega a mensagem (WhatsApp, site, form, telefone)

WhatsApp, chat do site, form e voz mudam o envelope: identificador, mídia, expectativa de tempo. Nenhum deles é o cérebro. Recomendo runtime único com adaptadores, não um “SDR” isolado por aplicativo. Percebi que empresa trata cada canal como projeto e multiplica política; a regra de FIT envelhece em velocidades diferentes. No entanto, o lead que preencheu form às 22h e mandou WhatsApp às 22h12 precisa da mesma ficha, não de dois MQLs. Por isso o orquestrador resolve identidade antes de conversar. Telefone entrega áudio; form entrega campo; site entrega sessão. Canal, portanto, não qualifica.

Detalhe de plataforma de mensagens não cabe neste how-to: o canal continua sendo transporte. Também recuso tutorial de API extraoficial neste texto. Dessa forma, o comprador não sai daqui montando fiação. Sai com o recorte: canal transporta; orquestrador decide.

Identidade e memória: lead novo ou ficha existente

Memória curta é o fio da conversa; memória longa é a ficha no CRM. Sem a segunda, o agente trata cliente como MQL e o closer herda constrangimento. Quando implementei essa resolução, o trade-off apareceu cedo: match agressivo por telefone junta duas empresas do mesmo grupo; match tímido duplica lead. Por isso eu prefiro chave composta — telefone mais domínio de e-mail, com revisão humana no empate. Ademais, conta com oportunidade aberta não vira “SQL novo”: rota para o dono. Ticket de suporte aberto no mesmo identificador também não vira demo. Assim, a pré-qualificação de atendimento respeita o contexto que o comercial já tem.

Thread sem CRM vira amnésia na próxima sessão. CRM sem o retorno da tool vira ficha genérica. Portanto eu gravo intenção, entidades, score, motivo e o ID que a função devolveu. Enquanto isso, o closer que recebe o caso não deveria pedir CNPJ e budget de novo. Ao mesmo tempo, memória demais sem finalidade é lixo e risco. Em suma, memória boa reduz retrabalho; não acumula áudio sem proveito.

Tools de catálogo fechado — o modelo não “entra” no Pipedrive sozinho

Function calling é a cerca, não o slogan. O modelo escolhe, entre funções pré-definidas, qual chamar e com quais parâmetros. Jamais navega no Pipedrive, no HubSpot ou no Salesforce como um usuário. Guardrail lista o que ele não faz: inventar preço, dar desconto, marcar reunião fora do FIT, fingir que é humano, pedir CPF se nome e canal bastam. Além disso, parâmetro errado é um modo de falha tão real quanto a alucinação de texto. Por conseguinte, log de cada chamada deixa de ser enfeite.

Catálogo que eu fecho no piloto — e recorto se o CRM do cliente não tiver o endpoint — cabe em nove funções.

• criar_ou_atualizar_lead resolve identidade e devolve o ID da ficha.
• A tool gravar_bant escreve Budget, Authority, Need e Timeline no vocabulário Qualified / Partially known / Unknown.
• Na sequência, gravar_score persiste o número ou o rótulo e a versão da regra.
• Por último, gravar_motivo_desqualificacao grava o porquê, em campo, não no Slack.
• anexar_transcript sobe o fio como atividade.
• criar_atividade registra o toque.
• mover_etapa muda o funil só depois do score.
• agendar_reuniao chama calendário e devolve o ID do evento.
• notificar_closer avisa a fila humana com o pacote, não com um “lead quente” vazio.

Todavia, abrir o catálogo para “o modelo decide o objeto no CRM” é o atalho que gera lead duplicado e etapa invertida. Por outro lado, recusar writeback para ir rápido no piloto só adia o teste que importa. Dessa forma, o catálogo começa pequeno, com contrato claro, tempo limite e tratamento de erro. Posteriormente, a operação amplia o que já tem dono.

O contrato de cada tool e o ID que ela devolve

Tool sem contrato é prompt com efeito colateral. Quando a gente desenha a interface, cada função declara entrada, saída, idempotência e o que acontece no timeout. criar_ou_atualizar_lead exige identificador de canal (telefone ou e-mail) e devolve, por exemplo, lead 8821 — um ID real, consultável no CRM. gravar_bant exige o ID da ficha e os quatro campos; recusa payload com texto livre no lugar do dropdown. agendar_reuniao só dispara se FIT passou e o score é SQL; devolve meeting às 19h, com UID de calendário, ou erro honesto se a agenda do closer está cheia. mover_etapa devolve o nome da etapa — “Meeting scheduled”, “Unqualified”, “Nurture” — nunca um “ok” genérico. Só então o agente confirma ao lead. Frase do tipo “já marquei sua reunião” sem ID é chatbot, mesmo quando o slide estampa SDR de IA. Ou seja, sem ID não houve tarefa.

Idempotência evita o clássico: o modelo chama duas vezes e criam-se dois deals. Timeout de três segundos no CRM não autoriza o agente a inventar sucesso. Permissão negada vira transbordo, não retry infinito. Percebi que o trade-off entre “confirmar rápido” e “confirmar certo” aparece toda sexta-feira, quando o Pipedrive do cliente está lento. Recomendo a ordem: tool, ID, texto. Invertida, o lead recebe promessa e o closer abre ficha vazia. Assim, o comprovante existe fora do chat. Em conclusão, se o gerente não consegue abrir o registro 8821 e ver score, BANT e atividade, a tarefa não aconteceu.

Writeback: score, campos e transcript com ID, ou a tarefa não aconteceu

Writeback é o teste que eu uso para desqualificar demo. A ferramenta devolve identificador; o agente responde depois. Resumo em texto no Slack não é CRM. Nota no card sem dropdown de BANT não é completude. Relatório de “leads quentes” que mora só no painel do fornecedor desaparece no churn do contrato. Por isso a ficha de registro é a do cliente, não a do implementador.

O case público mais limpo do ciclo — e rotulo como vendor, canal website, não WhatsApp de PME — está na página da Salesforce sobre Piper, o SDR inbound da Qualified no Salesforce.com, de 29 de julho de 2026: o agente cria ou atualiza lead, anexa transcript como activity, aplica routing e agenda no calendário. Go-live em abril de 2026, configuração da ordem de 30 dias, em CRM maduro. Números de conversão e de reuniões por semana nessa página são claim do próprio case; não são meta do leitor. Em outras palavras, o que eu copio é o mecanismo: intent, qualify, writeback, calendar. Não copio, portanto, o prazo de gigante com Salesforce limpo.

Auditoria semanal de amostra fecha o desenho. Toda conversa do piloto precisa de ID de lead ou de atividade. Falta de ID é bug, não “lead que só conversou”. Ainda, etapa movida sem score é o outro bug. Dessa forma, writeback rate vira métrica de comprador, não detalhe de TI.

RAG comercial, política versionada e o que o orquestrador recusa

Política comercial não sai da completude do modelo. Sai de artigo versionado: ICP, tabela de recusa, o que o produto faz e o que jamais promete. RAG recupera o trecho; o modelo não completa desconto. Quando a tabela de escopo muda e a base não, o assistente mente com fluência — o mesmo modo de falha do SAC, agora na pré-venda. Por isso dono de conteúdo comercial entra no desenho. Ademais, o orquestrador recusa ação fora do catálogo. Pedido de “me dá um preço especial” sem tool de desconto vira transbordo ou recusa, nunca chute. Confiança baixa na intenção também. Pedido explícito de humano, sempre.

Log de cada recusa, cada tool e cada transbordo serve à operação, ao piloto e ao artigo 20. Sem esse loop, existe texto, não SDR executado. Portanto a arquitetura que eu defendo é chata de propósito: envelope, política, função, ID, rota. Em suma, eloquência sem writeback continua sendo chatbot no mesmo canal.

Handoff para o closer (e a recusa do lead falso-qualificado)

Handoff é o momento em que o projeto ganha ou perde o comercial. Quando a gente desenha o agente de IA para SDR, a fila humana não recebe um “lead quente” no grupo. Recebe transcript, campos, score, o que faltou e o próximo passo. Sem isso, o closer pede os mesmos dados e o SQL vira fake. Recusar o falso-qualificado — lead que pressiona por reunião com FIT ou BANT falho — é o antídoto à vaidade de agenda. Recomendo tratar recusa como feature de produto, não como falha do modelo.

O que a fila humana precisa receber (transcript, motivo, o que faltou)

Pacote mínimo que eu coloco no SLA do closer: transcrição do fio, os quatro campos (ou o subset combinado) com o estado Qualified / Partially known / Unknown, o score e a versão da regra, o motivo se desqualificou, o ID da ficha, o ID da reunião se houver, e a frase “o que falta perguntar”. Quando implementei transbordo só com resumo gerado, o closer ignorou o texto e recomeçou do zero. No entanto, resumo sem campo é literatura. Por isso o card no CRM é a fonte; o aviso no Slack é ponte. Também peço SLA de aceite: o closer aceita ou recusa o SQL em horas combinadas, com motivo. Sem esse contrato, o fake SQL não aparece no relatório — só no humor do time.

Ouvir cinco calls do piloto vale mais do que dashboard no primeiro mês. Continuidade é princípio, não cifra de outro artigo. Dessa forma, o closer deixa de repregunta o CNPJ que o agente já gravou. Assim, handoff com contexto vira métrica: percentual de transbordos em que a primeira fala humana não repete BANT. Em suma, fila sem dossiê é retrabalho caro.

Agenda só com FIT — reunião sem critério é vanity

Volume de reunião é o indicador que a SERP ensina e que queima closer. Agenda sem FIT, sem Need e sem lembrete vira no-show e sabotagem. Percebi que operação otimiza “slots preenchidos” e descobre, na semana três, que o comercial recusa metade na abertura. Por outro lado, marcar menos e acertar mais sustenta o projeto. Por isso agendar_reuniao no catálogo exige o gate: FIT positivo e limiar de SQL. Calendário devolve ICS, UID e horário no fuso do closer. Lembrete entra no desenho, não como “fase dois”. Motivo de no-show volta para o CRM. Show rate — reuniões realizadas sobre agendadas — é o número que eu coloco ao lado de SQL aceito.

Copiar meta de gigante com site de milhares de visitas por dia é o outro erro. Case Piper, já rotulado, ilustra o ciclo em website enterprise; não é benchmark de PME com Pipedrive sujo. Todavia, ignorar calendário e deixar o closer “ver o lead depois” também mata velocidade. Recomendo o meio: agenda automática só quando o critério fecha. Ou seja, reunião é consequência do score, não o objetivo do agente.

Recusar o lead que pressiona por reunião

Lead insistente não autoriza fake SQL. Se FIT ou BANT falhou e a pessoa pede “só um papo de quinze minutos”, o agente não marca. Oferece conteúdo, retorno numa data, ou humano só se a política mandar. Quando a gente desenha essa recusa, o tom é educado e o motivo é específico: fora de geografia, porte abaixo, dor que o produto não cobre, sem autoridade e sem prazo. Inventar “vamos agendar mesmo assim” ensina o mercado interno que o critério é enfeite. Além disso, a recusa vai para o campo gravar_motivo_desqualificacao. Sem campo, ninguém calibra o score depois.

Política de “quero gente agora” é outro trilho. Pedido explícito de humano escala, mesmo com score baixo — experiência e marca, não só conversão. Contudo, escala para N2 ou para um SDR humano de exceção, não para a agenda do closer enterprise. Assim, o comercial deixa de herdar briga. Em conclusão, recusar é o trabalho sujo que o chatbot nunca faz porque foi treinado para agradar.

Quando transbordar para N2 de atendimento em vez de comercial

Nem todo inbound é venda. Boleto, senha, atraso de entrega e reclamação de N1 disfarçada de “quero falar com vendas” são atendimento. Rota comercial nesse caso gera SQL lixo e cliente irritado duas vezes. Por isso a intenção “suporte” e a ficha com ticket aberto pesam mais que a palavra “proposta” no primeiro balão. Também peso sentimento alto: quem já xingou não deveria ganhar um closer pedindo budget. Transbordo para N2 leva transcript, o que a tool já tentou e o motivo. Fila comercial nem vê o card.

Conta existente pede o dono, não um SDR de captação. Oportunidade aberta pede o AE da opp. Parceiro e imprensa saem por rota própria. Dessa forma, o agente de atendimento e o SDR de IA compartilham canal e se separam na intenção. Ainda, o contrato entre os dois times entra no kickoff: quem é dono de cada rota. Sem dono, o lead fica no limbo e os dois times reclamam do modelo. Portanto o desenho de handoff começa pelo mapa de intenções, não pelo calendário.

Quais métricas um comprador deve acompanhar no piloto

Comprador sério não mede conversa encerrada. Mede qualidade que o closer aceita. Quando a gente desenha o piloto de um agente de IA para SDR, o painel cabe em uma tela: time-to-first-touch, SQL aceito, fake SQL, show rate e writeback rate. Volume de mensagens, sozinho, não cabe. Baseline antes do go-live é obrigatório — sem ela, qualquer “sucesso” vira slide. Recomendo capturar o estado atual na semana 0, não na semana 8.

O scorecard que o closer aceita

Time-to-first-touch e a janela de minutos (MIT 2007, rotular o ano)

Janela de minutos é o job do agente 24/7. O PDF do MIT Lead Response Management Study (2007), de James Oldroyd e Dave Elkington — três anos de dados, seis empresas, mais de 15 mil leads web e mais de 100 mil tentativas de ligação — não mede close rate. A chance de contatar um lead em 5 minutos versus 30 minutos cai 100 vezes. Qualificar — entrar no processo de vendas ou marcar conversa, conforme a definição de cada empresa — cai 21 vezes nas mesmas janelas.

Já o contato despenca mais de 10 vezes na primeira hora; a qualificação, mais de 6 vezes. Após 20 horas, discagens adicionais prejudicam. Eu rotulo o ano e o canal: 2007, form web mais telefone. Não vendo, portanto, 21 vezes como KPI de WhatsApp em 2026. O mecanismo que transfere é outro: intenção esfria em minutos. Por isso o agente existe fora do horário comercial. Contar time-to-first-touch só em horário de expediente, pois, esconde o ganho noturno e falseia o piloto.

Percentual de inbound tocado em menos de cinco minutos é o recorte operacional da mesma âncora. Todavia, prometer o multiplicador do estudo como cláusula contratual é desonesto. Assim, eu meço velocidade com ID no CRM — primeira atividade timestamped — e deixo o 21 vezes no slide de contexto, datado.

O gap humano fora de hora (Drift 2017)

Gap entre a janela clássica e o que o time humano entrega é estrutural, não preguiça. A Lead Response Survey da Drift, publicada por Dave Gerhardt em 27 de fevereiro de 2017, fez secret shopper em 433 empresas B2B SaaS — forms, demo, sales inquiry. Sete por cento (32 de 433) responderam em cinco minutos. Cinquenta e cinco por cento não responderam em cinco dias úteis. As dez mais rápidas usavam live chat; só 14% das 433 usavam live chat. Ano 2017, amostra SaaS, canal form. Não extraio “quarenta e sete horas” deste texto porque o número não está lá. O que eu levo ao piloto é o diagnóstico: fila, fuso e form sem dono atrasam o toque. Agente 24/7 ataca exatamente esse furo. Fora de hora, o humano não compete. Dentro do horário, o humano continua no juízo.

SQL aceito pelo closer vs “reunião marcada”

Reunião marcada é vaidade se o closer recusa na abertura. SQL, no vocabulário HubSpot já citado, pede conversa e aceite comercial, não form. MQL para SQL do agente só conta quando o closer marca aceite — ou quando o contrato SAL define o critério objetivo e o comercial não devolve. Marketing sozinho não pode batizar SQL. Quando implementei painel que misturava os dois, o slide de “conversão” subia e o win caía. No entanto, o comercial já sabia. Por isso eu separei: agendadas, realizadas, aceitas como SQL, viradas em oportunidade. Otimizar o primeiro número contra o último é o erro clássico. Dessa forma, o piloto decide se o limiar está largo ou estreito. Apertar o score quando o closer devolve lixo; não “gerar mais reunião”.

SQL para oportunidade e win fecham a cadeia. Híbrido — IA no volume, humano no juízo — é a tese que eu defendo sem copiar multiplicador de guia não auditado. Em suma, reunião que não vira opp é custo de agenda, não prova de agente.

Fake MQL, show rate e writeback rate

Fake MQL e fake SQL são o percentual que o closer recusa na primeira conversa: não tinha budget, era estudante, era suporte, era fora do país. Se a recusa passa da faixa combinada no piloto, o score está largo. Show rate pede lembrete, ICS e motivo de no-show no CRM; agenda sem confirmação infla o numerador. Writeback rate é o percentual de conversas com ID de lead ou atividade no CRM. Sem isso, não é agente. Completude BANT/FIT — percentual de SQLs com os campos preenchidos em dropdown, não em nota — é o teste de writeback que o comercial entende. Taxa de FIT, no portão de ICP, evita inflar MQL. Handoff com contexto, já descrito, fecha a lista.

Mapa da semana 0: como não trapacear as métricas

Tabela abaixo é o mapa que eu uso na semana 0, antes de qualquer go-live. Sem os quatro números de baseline — time-to-first-touch atual, percentual sem resposta, lixo que o closer já recusa e completude de campos — o piloto não tem contraste.

Portanto eu recuso go-live “para ver o que acontece” sem esses quatro números no papel. Completude de campos hoje, não a que o fornecedor promete depois, é o denominador honesto.

O que as pesquisas globais medem — e o que elas não prometem

Adoção não é ROI de pré-qualificação de atendimento no Brasil. Na State of Sales 2026, 87% das organizações de vendas usam alguma forma de IA; 54% dos sellers já usaram agents; high performers são 1,7 vezes mais propensos a usar agents de prospecting. Survey duplo-anônimo, 4.050 profissionais, campo agosto–setembro de 2025, 22 países inclusive o Brasil, anúncio em 3 de fevereiro de 2026. Cinquenta e um por cento dos líderes com IA apontam sistemas desconectados — esse é o número que eu amarro ao writeback. Expectativas de corte de tempo de research e de rascunho de e-mail no mesmo relatório são expectativa, não resultado medido; não as uso como meta. Quote interno de volume de leads da Salesforce também não transfere para PME.

Piper, já linkado, declara conversão e reuniões por semana no próprio site da Salesforce: vendor-stated, canal website, CRM maduro. MIT 21 vezes é 2007, form e telefone, seis empresas. Nenhum dos três substitui SQL aceito, fake SQL e writeback rate da sua fila. Além disso, 74% dos líderes na mesma pesquisa focam data cleansing; high performers priorizam higiene mais do que underperformers. Eu levo esse recorte para o kickoff: o piloto de SDR de IA falha quando o CRM é um cemitério de campos. Em conclusão, compre métrica de closer. Não compre slide de adoção global.

Como implantar em 60 a 90 dias (sem painel self-serve)

Prazo que eu aceito alinha à implementação contratada: piloto em semanas, resultado mensurável em 60 a 90 dias. Não é quinze minutos. Não é cinco minutos sem código. Quando a gente desenha um agente de IA para SDR de verdade, o trabalho sujo vem antes do modelo — ICP, campo, SAL, baseline, jurídico na mesa. Login e prompt sozinhos não sustentam. Recomendo um segmento, um canal, um closer piloto. Alargar depois do contraste, nunca antes.

O calendário de 60 a 90 dias

Semanas 0–2: ICP, campos no CRM, baseline, dono da exceção

Diagnóstico comercial, não escolha de modelo. Volume inbound por canal — WhatsApp, site, form, telefone — e por intenção: orçamento, demo, suporte, vazio. Definição escrita de ICP e de SQL, com dono: head comercial. Campos que vão existir de verdade: Budget, Authority, Need, Timeline (ou equivalentes FIT), score, motivo de desqualificação, origem, dono, next step. Se o campo não existe, o writeback não existe. Integrações: o CRM que o cliente já usa, calendário, fila. Sem CRM de registro, o projeto não começa. Baseline das métricas da seção anterior. DPO ou jurídico na mesa: finalidade do score, aviso de IA, retenção do transcript. Detalhe longo de conformidade fica no guia específico; aqui, a presença na semana 1. Percebi que pular o jurídico para “ir rápido” só empurra o parecer para a véspera do go-live, quando o catálogo já está errado.

Dono da exceção é nome e horário, não um grupo órfão. Quem aceita o SQL, quem recusa o fake, quem atualiza a política quando o produto muda. Sem esses nomes, o piloto vira WhatsApp no vácuo. Também recorto escopo: um produto, uma geografia, um funil. Três funis no dia um é o atalho que explode o RAG. Dessa forma, as duas primeiras semanas produzem documento, não demo. Em suma, papel antes de prompt.

Contrato SAL: o que o closer aceita e o que devolve

SAL é o contrato que o comercial assina com tinta, não o slide de marketing. Contato válido, intent suficiente e ICP entram no mesmo papel. Impede o fluxo — opp aberta, conta do time de customer success, suporte. Motivos enumerados de devolução pelo closer: fora de porte, sem dor, sem prazo, estudante, já cliente, ticket. Quando implementei piloto sem essa lista, o closer devolvia “lixo” sem taxonomia e ninguém calibrava o score. No entanto, lista demais na semana 0 também trava. Por isso eu começo com cinco motivos de recusa e abro depois. SLA de aceite em horas combinadas entra no mesmo papel. Round-robin, território ou dono fixo do piloto: uma regra só. Misturar as três no dia um gera lead sem dono.

Trade-off visível: SAL apertado reduz volume e protege o closer; SAL largo enche a agenda e mata o projeto. Recomendo começar apertado. É mais barato alargar o limiar na semana 6 do que reconquistar um comercial que já odiou o agente. Assim, o contrato SAL vira o teste de aceite do piloto, não um PDF esquecido.

Semanas 2–4: um canal, um segmento, tools e guardrails

Recorte brutal. Um segmento, um canal, um closer. Catálogo fechado das nove funções, ou o subset que o CRM realmente expõe. Modelo não navega: chama função. Guardrails escritos: jamais inventar preço, jamais desconto, jamais reunião fora do FIT, jamais fingir humano, jamais pedir dado que nome e canal não exigem. Script de qualificação em conversa — perguntas abertas, ordem variável, earn the right — não árvore de botão só. Handoff com o pacote da seção anterior. Política de recusa e de “quero gente agora”. Identificar-se como assistente de IA na primeira interação útil. Timeout, retry e o que fazer quando o CRM devolve 429. Mapeamento de etapa: qual valor de score move para qual estágio, e qual usuário de integração assina a atividade para o comercial não achar que “o robô” bagunçou o funil.

Trade-off de canal: form web chega com campo e pouco contexto; WhatsApp chega com áudio e intenção misturada. Começar pelo form é mais fácil de auditar; começar pelo WhatsApp é mais fiel ao volume brasileiro. Eu escolho pelo volume real do cliente, não pelo que é mais fácil de integrar. Por outro lado, dois canais no mesmo piloto dobram política e escondem o bug. Portanto um canal. Posteriormente o segundo.

Script conversacional, recusa e “quero gente agora”

Script não é árvore. É política de conversa: o que perguntar, o que nunca perguntar no primeiro turno, como recusar, como se identificar. Quando a gente desenha o texto, o agente se apresenta como assistente de IA da empresa, diz o que pode fazer e oferece gente no mesmo fôlego. Também varia a ordem de BANT conforme a intenção — quem pede demo ganha Need e Timeline antes de Budget; quem pede preço ganha Budget com cuidado, sem interrogatório. Recusa traz alternativa concreta: material, data de retorno, N2. Pedido de humano escala na hora, mesmo que o score fosse seguir. Percebi que esconder a IA “para não perder conversão” queima marca e complica o artigo 20. Por isso transparência entra no script, não no rodapé jurídico.

Teste de regressão do script usa dez conversas reais anonimizadas, não prompt de laboratório. Cinco deveriam virar SQL, três recusa, duas N2. Se o modelo agenda as dez, o guardrail falhou. Dessa forma, as semanas 2 a 4 produzem catálogo, script e bateria de teste. Não produzem “SDR no ar para o time inteiro”.

Semanas 4–8: piloto em produção, humano em paralelo

Fatia real de inbound, não sandbox eterno. Humano revisa amostra diária: falso positivo (SQL que o closer recusa) e falso negativo (lead bom que o agente nurtureou). Calibrar limiar: se o closer devolve lixo, apertar o score. Auditoria de writeback: toda conversa com ID. Lembrete de reunião e registro de no-show. Fila para o titular que pedir revisão da recusa — controle operacional, não teatro. Percentual do volume no agente começa pequeno, da ordem de um segmento, e só cresce se writeback rate e fake SQL cabem na faixa. Quando o CRM oscila, o piloto pausa writeback de escrita e mantém leitura; não inventa sucesso. Enquanto isso, o closer piloto conversa com o dono do critério toda semana. Sem essa reunião, o score vira relíquia.

Também meço o que o baseline prometeu: time-to-first-touch, completude, aceite. Ainda não alargo canal. Ainda não abro o segundo produto. Por conseguinte, as semanas 4 a 8 doem porque a operação vê o lixo que o processo antigo escondia. Isso é ganho de diagnóstico, não falha do modelo. Em suma, produção com humano em paralelo é o teste; laboratório não é.

Semanas 8–12: calibrar o score e operação assistida

Resultado mensurável mora aqui. Comparar versus baseline: time-to-first-touch, fake SQL, show rate, SQL para oportunidade. Só então alargar canal ou segmento. Operação assistida: dono de critério comercial, dono de campo CRM, atualização de RAG de produto, relatório mensal, revisão de amostra. Login e prompt sozinhos não sustentam porque a tabela de preço muda, o ICP muda, o closer sai de férias. Case Piper, já rotulado, falou em cerca de 30 dias de configuração com CRM maduro e governança — piso enterprise, não teto de PME sem Pipedrive limpo. “SDR no ar em quinze minutos” é sinal de projeto incompleto: falta ICP, falta campo, falta SAL, falta closer alinhado. Eu recuso esse atalho.

Alargar o piloto é tentador quando o slide de velocidade fica bonito. Todavia, velocidade sem SQL aceito é o mesmo vanity da reunião. Recomendo um critério explícito de promoção: writeback rate acima do combinado, fake SQL abaixo do combinado, closer piloto disposto a receber o segundo segmento. Sem os três, o projeto permanece no recorte. Assim, 60 a 90 dias deixam de ser marketing e passam a ser calendário de implementação. Por fim, o próximo passo de quem quer esse desenho — diagnóstico, implementação e operação assistida, sem painel para ligar sozinho — é a lista de espera, não um trial de fim de semana.

Erros que queimam o closer e o projeto

Projeto de agente de IA para SDR morre mais por erro de desenho do que por modelo fraco. Quatro atalhos se repetem: batizar chatbot de SDR, pontuar sem gravar, otimizar reunião e ligar sem ICP. Também entram MEDDIC no primeiro “oi”, esconder que é IA e atalho de API extraoficial. Eu recuso os sete no diagnóstico. Closer queimado não volta a confiar no funil.

Batizar o chatbot de SDR

LLM no WhatsApp que tira dúvida e diz “vou te passar para o comercial” sem gravar BANT nem score não é SDR. É chatbot no mesmo canal. O teste continua o da abertura: se nenhum campo de BANT/FIT, score ou etapa muda no CRM, o nome comercial é irrelevante. Quando implementei RFPs, o slide mais caro era exatamente esse — persona com nome próprio, zero writeback. No entanto, o canal bonito esconde a ficha vazia. Por isso eu desqualifico demo que só conversa. Ainda, menu com parágrafo eloquente no final continua menu. Dessa forma, o comprador para de comparar preço de árvore com preço de agente. Em suma, rótulo não executa tarefa.

Pontuar sem gravar no CRM

Score que mora na conversa e some no painel do fornecedor é teatro. Closer abre o CRM e vê ficha vazia; o relatório de “leads quentes” não sobrevive ao churn do contrato. Percebi que esse erro vem disfarçado de “integração em breve”. Todavia, piloto sem campo não testa o job. Por isso gravar_bant, gravar_score e anexar_transcript entram no recorte da semana 2, não numa fase posterior. Nota livre no card também não conta: o closer não filtra “Unknown” numa prosa. Por conseguinte, completude só vale em dropdown. Assim, pontuar sem persistir é o irmão gêmeo de batizar chatbot. Os dois queimam o comercial da mesma forma: retrabalho na abertura da call.

Otimizar volume de reunião

Reunião sem fit é o vanity que a categoria ensina. Digital Applied, num guia de 2026 que eu trato como opinião do autor e não como estatística, argumenta que volume de meeting sem qualidade queima receita; o espírito vale mesmo sem copiar cifra. A investigação da TechCrunch sobre a 11x, em 24 de março de 2025, é o recorte de due diligence que eu levo à mesa — e rotulo com cuidado. Trata-se, portanto, de SDR outbound autônomo (Alice), não de pré-qualificação de atendimento inbound.

ZoomInfo no texto: piloto de um mês, produto pior que SDR humano, logo usado sem permissão, empresa nega ser cliente. Airtable: trial curto, nunca em produção. Ex-funcionários falam de churn alto nos early customers; a 11x rebate com outra métrica de retenção. Eu não generalizo “IA SDR é fraude”. Generalizo o aviso: não comprar volume de reunião sem SQL aceito e sem referência que renovou. Inbound deste artigo não é Alice. Ainda assim, o closer brasileiro sabota o projeto na semana 3 quando a agenda enche de lixo. Por isso eu otimizo aceite, não slot.

MEDDIC no primeiro “oi” e BANT como formulário

Framework de AE em volume inbound estrangula o lead. MEDDIC completo no “vi o anúncio” pede métrica, economic buyer e decision process de quem ainda está testando se a empresa existe. BANT em oito perguntas seguidas, no outro extremo, parece operação madura e soa como interrogatório. HubSpot, no guia de BANT já linkado, pede ganhar o direito de perguntar e variar a ordem. Quando a gente desenha o script, layer 1 cabe em três a oito minutos; layer 2 fica na call. Também recuso “BANT until close” em deal de comitê: o closer precisa de GPCT ou MEDDIC de verdade, não de quatro dropdowns. Dessa forma, os dois erros — framework pesado cedo demais e checklist cedo demais — saem do piloto. Recomendo conversa curta, campo gravado, discovery humana depois.

Ligar o agente sem ICP (e copiar case de gigante)

Sem critério, o agente escala o caos. Volume baixo, venda só por indicação e ICP inexistente são sinais de “quando não usar” que até landings de produto acertam no diagnóstico. Salesforce, na pesquisa já citada, resume o modo de falha: agente stand-alone sem contexto de cliente tende a falhar. Copiar Piper — dezenas de reuniões por semana num site com tráfego de gigante — como meta de PME com form de vinte leads/mês é o outro atalho.

Eu cito o case para o ciclo writeback mais agenda, rotulado, canal website. Recuso a cifra como objetivo. Recuso, ainda assim, go-live sem baseline. Sem time-to-first-touch atual e sem percentual de lixo que o closer já recebe, o slide de “melhorou” não tem denominador. Por outro lado, esperar ICP perfeito para sempre é paralisia. ICP escrito, versionado, dono comercial: suficiente para o recorte. Depois o piloto ensina. Em suma, critério antes de modelo; case de gigante como mecanismo, não como meta.

Esconder que é IA — e atalho de API extraoficial

Transparência não é aviso no rodapé. Identificar que é assistente de IA na primeira interação útil, oferecer gente no mesmo fôlego, gravar o critério do score. Quem esconde o modelo — “o prospect não percebe” — escolhe risco de marca e complica revisão. Opinion Box, já tratado no texto de atendimento, mostrou rejeição brasileira a resposta automática; uma frase de tom basta: o cliente quer saber com quem fala.

API extraoficial de WhatsApp, vendida como atalho sem custo de plataforma, é desqualificação: não use. Sem tutorial e sem nome de biblioteca. O projeto de pré-qualificação de atendimento inbound, portanto, não começa pela fiação clandestina. Começa pelo CRM de registro, pelo ICP e pelo closer que vai aceitar o SQL. Medir só volume de conversas, o erro número dez da lista, fecha o pacote: sem SQL aceito, sem show, sem win, o dashboard mente. Portanto eu recuso os atalhos em bloco. Closer queimado, pois, custa mais do que o piloto atrasado.

Conclusão

Score que recusa reunião é decisão automatizada que afeta interesse do titular. O artigo 20 da Lei 13.709/2018 (redação da Lei 13.853/2019) garante o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado — perfil pessoal, profissional, de consumo, de crédito, de personalidade. Parágrafo 1º pede informações claras sobre critérios e procedimentos, observados segredos comercial e industrial. Parágrafo 3º foi vetado: a lei não exige expressamente revisão por pessoa natural, diferente do regulamento europeu. Na prática de SDR, eu identifico que é IA, gravo o critério do score e mantenho caminho humano de revisão como controle operacional, não como obrigação mal citada. Checklist jurídico completo está no guia de LGPD para agentes em empresas.

O ciclo em uma linha — e o próximo passo

Um agente de IA para SDR não é chatbot com nome de vendedor. É o ciclo que eu recortei neste how-to: intenção de quem já chegou, BANT ou FIT em conversa curta, writeback com ID, rota para o closer ou recusa do lead falso-qualificado. Layer 1 no agente; layer 2 no humano. Métrica de comprador é SQL aceito, não reunião marcada. Piloto em semanas, resultado em 60 a 90 dias. Se a peça só conversa e o CRM não muda, a tarefa não aconteceu.

Se o canal já for WhatsApp, o texto seguinte é o de como implantar o agente no WhatsApp da empresa. Quem quer diagnóstico, implementação e operação assistida de um Funcionário de IA no papel de SDR — serviço contratado que executa a pré-qualificação de atendimento de verdade, para crescer sem necessariamente expandir o quadro — encontra a lista de espera da BayAI. Em conclusão, compre execução com comprovante no CRM. Não compre um parágrafo no mesmo canal.

Perguntas frequentes