Agentes de IA no RevOps: o que já roda na operação comercial

Agente de IA no RevOps é um sistema que olha o contexto de um lead, de um registro ou de uma tarefa e decide o próximo passo sozinho, dentro de regras que alguém definiu. A diferença para a automação comum está nessa decisão: a automação executa a mesma regra toda vez ("se o formulário chegou, crie o negócio"); o agente lê o que aconteceu e escolhe o que fazer em seguida, inclusive chamar uma pessoa.

Eu cuido da operação comercial da Vinteo, e hoje quatro agentes trabalham nela junto com o time. Este texto conta o que cada um faz, o teste que deu errado no caminho e as regras que ficaram.

Onde o agente entra na operação de receita

O agente vale a pena onde o trabalho é repetitivo, depende de ler alguma coisa antes de agir e custa caro quando ninguém faz. Na operação da Vinteo, isso aparece em quatro lugares:

• Qualificação e agendamento: conversar com o lead, descobrir se ele tem perfil e marcar a reunião com o closer.
• Tempo de resposta: perceber que um lead está esperando demais e avisar quem precisa agir.
• Qualidade do que o time registra: ler a anotação que o SDR deixou e dizer quando ela não serve para o próximo passo.
• Registro da call: transcrever a conversa e levar para o CRM o que foi dito, sem o vendedor digitar.
• A construção da própria operação: mexer no CRM, nas automações e no site com um agente que trabalha junto com o time.

Nenhum desses substitui o que o RevOps faz de base. Agente em cima de processo confuso e dado sujo só erra mais rápido. O que a IA precisa para funcionar está em RevOps e inteligência artificial.

Os vigilantes: agentes que cuidam do lead enquanto o time vende

Chamamos de vigilantes os agentes que acompanham o funil e avisam quando alguma coisa saiu do combinado. Temos dois tipos rodando.

O que lê a observação do SDR

Todo lead que passa pelo SDR ganha uma observação antes de ir para o closer. Quando essa observação é genérica ("cliente interessado", "pediu contato"), o closer entra na reunião sem saber o que foi conversado e começa do zero. O vigilante lê o que foi escrito e avisa o SDR quando a observação não diz nada que ajude a próxima conversa.

A primeira versão dele foi um teste que deu errado. Ela conferia se o campo da observação estava preenchido, e não o que estava escrito nele. Resultado: avisava quase todo lead, inclusive os que tinham uma anotação boa em outro lugar, e aviso que chega para tudo vira ruído que o time aprende a ignorar. Tiramos do ar e aprimoramos: o sinal passou a ser o conteúdo da anotação. A lição que ficou vale para qualquer agente: ele precisa olhar o sinal certo, e campo preenchido quase nunca é o sinal certo.

O que avisa que o lead está atrasando

O segundo vigilante olha o relógio. Quando um lead de inbound passa do prazo de resposta sem ser atendido (no nosso caso, 30 minutos), ele avisa três pessoas ao mesmo tempo: o próprio SDR, que é quem precisa agir; o coordenador, que distribui a fila; e o ops, que enxerga se o atraso é um caso isolado ou um gargalo do processo. É assim que o lead response time cai: lead que espera esfria, e o prazo combinado entre marketing e vendas só existe se alguém cobra (é o que chamamos de SLA entre marketing e vendas).

O SDR AI: um agente que qualifica e marca a reunião sozinho

O SDR AI roda com lead de verdade desde julho. Ele chega ao lead pelo e-mail marketing e pelas réguas de lifecycle, conversa e tenta descobrir duas coisas: o faturamento da empresa e o cargo de quem está do outro lado. Se as duas respostas colocam o lead dentro do nosso ICP, ele tenta marcar a reunião direto na agenda do closer.

O humano entra em dois momentos. O primeiro é a própria reunião, que continua sendo do closer. O segundo é quando o SDR AI decide que não deve seguir sozinho e pede uma pessoa na conversa. Fora isso, a qualificação é dele do começo ao fim.

A parte que mais importa é como ele melhora: o SDR AI aprende com o resultado das reuniões que marcou. O que aconteceu na reunião volta para ele, e é assim que a qualificação fica mais precisa com o tempo.

O agente que transcreve a call e atualiza o CRM

Vendedor que sai de uma call e ainda precisa preencher o CRM preenche pela metade, ou no fim do dia, de memória. O agente de transcrição tira essa tarefa dele. Ele funciona dentro do nosso CRM próprio: grava a call na máquina de quem está conversando, transcreve e preenche no registro do negócio os campos que o time definiu, sem ninguém digitar.

Foi a WeCare, empresa parceira da Vinteo, que me deu a ideia: eles já usam um agente assim no CRM deles. Hoje ele funciona no nosso também. Ele resolve pelo outro lado o mesmo problema do vigilante da observação: em vez de cobrar uma anotação melhor do vendedor, escreve a partir do que foi dito na call.

O agente que constrói a operação com a gente

O terceiro agente não fala com lead. Ele trabalha com o time de operação: mexe no nosso CRM próprio, monta automação no n8n e sobe mudança no site. Usamos o Claude para isso, e o que faz dar certo são as regras que ele segue.

• Lê antes de escrever. Antes de mudar qualquer coisa, ele abre o arquivo ou o registro como está hoje. Mudança feita em cima de uma cópia velha desfaz o trabalho de outra pessoa sem ninguém perceber.
• Mostra o fluxograma antes de construir. Nenhuma automação nasce sem que alguém veja o desenho e aprove. Mudar o desenho sai muito mais barato do que desfazer uma automação que já gravou dado errado no CRM.
• Nada vai para produção sem um humano aprovar. O agente prepara, testa e mostra. Quem liga é uma pessoa.
• Senha e chave nunca ficam em arquivo. Ele usa a credencial na hora e descarta.

Files and folders: o hotel que transforma qualquer LLM em agente

Esse agente não depende de um modelo específico. Se amanhã o Claude der lugar a outro LLM, ele continua trabalhando do mesmo jeito, porque o que transforma o LLM em agente é a forma como o conhecimento da empresa foi organizado para ele ler. A gente organiza tudo em pastas e arquivos de texto (files and folders) e explica a estrutura com uma analogia: um hotel.

O saguão, o mapa do andar e o quarto

Quem chega num hotel não abre todas as portas até achar o próprio quarto. Pergunta no saguão em que andar ele fica, lê o mapa do andar e vai direto à porta. A pasta da operação funciona igual, em três níveis:

• Saguão: a raiz da pasta, com o arquivo de instruções e o mapa geral. Diz em que andar mora cada assunto.
• Mapa do andar: um arquivo dentro de cada pasta de categoria (projetos, automações, a empresa, eventos). Diz quais quartos existem ali e o que tem em cada um.
• Quarto: a ficha ou o arquivo do projeto, com o dado em si: o que é, em que pé está, qual é o próximo passo e o que não pode ser tocado.

Cada nível diz só o suficiente para o agente escolher o próximo. Ele não precisa ler a empresa inteira para responder uma pergunta, e isso ataca os dois erros mais comuns de IA com dado de empresa: ler coisa demais e se perder no meio, ou ler de menos e completar o resto por conta própria.

AGENTS.md e CLAUDE.md: um contrato para qualquer LLM

O arquivo do saguão se chama AGENTS.md. É uma convenção aberta: um arquivo em markdown, na raiz da pasta, que explica ao agente como trabalhar ali. Parte das ferramentas procura o AGENTS.md, e o Claude Code procura o CLAUDE.md. O nosso CLAUDE.md tem poucas linhas e manda ler o AGENTS.md antes de tocar em qualquer arquivo. Com isso existe um contrato só, e o mesmo hotel serve para Claude, Codex, Cursor, Gemini ou o próximo modelo que aparecer.

As regras do hotel

A estrutura funciona porque o próprio arquivo de instruções diz ao agente como se comportar dentro dela:

• Um fato mora num lugar só. Se a mesma informação aparece em dois arquivos, um deles vai envelhecer errado. No outro lugar fica um link.
• Não achou? Suba uma pasta. O agente lê o mapa do andar de cima e, se precisar, sobe de novo. Chegou ao saguão sem achar, ele diz que a informação não está mapeada e pergunta. Não inventa.
• Ficha vazia também é resposta. Toda ficha tem uma seção com o que ainda não foi dito. Se a pergunta cai ali, a resposta certa é "isso ainda não foi informado".
• A ficha guarda a consulta, não o número. Número que muda todo dia, como receita e meta do mês, fica no sistema. A ficha diz onde e como conferir.
• Quem termina registra. Ao acabar uma tarefa, o agente atualiza em que pé o projeto está, qual é o próximo passo e o histórico. Não existe script que faça isso por ele: se ele não escrever, o próximo agente começa sem saber o que aconteceu.
• O que não pode ser tocado está escrito. Cada projeto tem um campo com o que só muda com a confirmação de uma pessoa.

Começamos em 18 de agosto. Hoje o hotel tem 37 projetos, 10 mapas de andar e 22 fichas de contexto, e o histórico passa de 900 registros, cada um escrito no fim de uma tarefa.

As regras que ficaram

Juntando os quatro casos, estas são as regras que usamos para colocar um agente novo na operação:

1. Olhe o sinal certo. O que o agente lê decide se ele ajuda ou atrapalha. Conteúdo vale mais que campo preenchido.
2. Avise quem age e quem cobra. Aviso que chega só para uma pessoa se perde fácil. Quando o coordenador e o ops também recebem, o atraso deixa de ser problema de um e vira coisa que se corrige no processo.
3. Deixe o humano onde a decisão é dele, e dê ao agente um jeito de pedir ajuda.
4. Ensine com resultado. O que aconteceu depois da ação do agente é o que mostra se ele acertou.
5. Dê ao agente um mapa, não a pasta inteira. Organizado em níveis, qualquer LLM acha o que precisa sem ler tudo.
6. Teste pequeno e esteja pronto para tirar do ar. O primeiro vigilante saiu do ar no teste, e foi o que ensinou a olhar o sinal certo.

Perguntas Frequentes