Quinta-feira, 14h. Uma vendedora abre o Bitrix24 e vê 23 cards na etapa “Seguimento 2”. Ela não sabe quais estão quentes, quais esfriaram, quais o cliente já decidiu internamente e só não comunicou. O card de quem verbalmente disse “vamos fechar” está na mesma fila do que nunca respondeu.
Ela começa a ligar um por um. O CRM não está gerenciando — está arquivando.
Enquanto isso, a automação de “Seguimento 2” disparou e-mail para todos os 23. Inclusive para o cliente que sinalizou fechamento. Ele achou o e-mail estranho, pediu esclarecimentos. A venda atrasou uma semana.
Isso não é falha de automação. É falha de desenho de funil.
—
O que o Bitrix24 permite fazer
O Bitrix24 permite configurar regras de automação em cada etapa do funil — em leads, negócios, orçamentos e processos inteligentes. Quando um card entra numa etapa, as regras disparam: enviam e-mail, criam tarefa, notificam responsável, alteram campos, geram documento.
O mecanismo funciona com precisão. O problema não é o robô.
O problema é a premissa que está no nome da etapa.
Se a etapa foi desenhada como ação do vendedor — “Seguimento 2” — o robô dispara para todo card que o vendedor moveu, independente do que o deal é. Ele executa a lógica que recebeu. Sem discernimento. Sem leitura de maturidade. A força do robô amplifica exatamente o erro de quem o configurou.
—
A pergunta que vem antes da automação
Antes de nomear uma etapa, antes de criar qualquer regra de disparo, há uma pergunta que toda equipe precisa conseguir responder com clareza:
Quando um card entra nessa etapa, o que mudou para o cliente — ou só o que você fez?
Se a resposta for “eu liguei”, “eu enviei proposta”, “eu mandei follow-up” — você não tem uma etapa. Tem um registro de atividade com nome de etapa.
Etapa não é o que você fez. É o que o negócio virou.
—
Os critérios que separam etapa real de etapa de tarefa
Antes de mover um card ou criar uma nova etapa, aplique estes cinco critérios:
- O que mudou concretamente no estado do negócio? Não no que você fez — no que o deal é agora.
- Dois deals nessa etapa têm a mesma maturidade comercial real? Se a resposta é “depende, preciso ler as notas”, a etapa não existe de verdade.
- O nome descreve uma condição do negócio ou uma ação do vendedor? “Proposta aceita” é condição. “Proposta enviada” é ação.
- Uma automação disparada para todos os cards desta etapa faz sentido para qualquer deal aqui? Se seria absurda para algum deles, a etapa está errada.
- Um gestor que nunca viu esse deal entende onde está a negociação só pelo nome da etapa? Se ele precisa abrir o card para entender o contexto, o nome falhou.
—
Quando usar etapas baseadas em estado
Use quando o avanço reflete uma mudança concreta na posição do cliente — não do vendedor.
“Proposta aprovada” — o cliente confirmou interesse formal. “Contrato assinado” — existe documento. “Onboarding iniciado” — o cliente deu o primeiro passo pós-venda. “Aguarda decisão interna” — o cliente comunicou que o processo está em avaliação interna.
Todas descrevem onde o negócio está. Não o que o vendedor fez ontem.
—
Quando NÃO usar
Não construa etapas com base em rotina de follow-up. “Seguimento 1”, “Seguimento 2”, “Seguimento 3” não são estados do negócio — são calendários de tentativa. Essa sequência pode existir como automação de tarefa. Não como estrutura de funil.
Não nomeie etapas com verbos de ação do vendedor. Um deal pode ter proposta enviada e estar morto. Outro pode ter proposta enviada e estar na véspera de fechar. A etapa diz o mesmo para os dois.
Quando o nome da etapa é ação do vendedor, o funil vira diário de bordo. Não mapa de maturidade.
—
Exemplo aplicado
Uma gestora de distribuidora B2B montou o funil assim: “Primeiro Contato”, “Proposta Enviada”, “Aguardando Retorno”, “Seguimento 1”, “Seguimento 2”, “Seguimento 3”.
Em três meses, 80% dos cards empacavam em “Aguardando Retorno”. O relatório de pipeline mostrava volume em todas as etapas — mas não dizia nada sobre o negócio. Quando precisava entender o estágio real de cada deal, ela abria card por card e lia as notas.
O CRM tinha registrado tudo que o vendedor fez. Não sabia nada sobre onde o cliente estava.
Redesenhamos o funil com base em estados do cliente: “Interesse confirmado”, “Proposta em análise”, “Aprovação interna em curso”, “Negociação de condições”, “Fechamento”. Em seis semanas, ela conseguia ler o pipeline em três minutos — sem abrir um único card.
—
Erros que eu vejo o tempo todo
Nomear etapas como atividades internas. “Proposta enviada” não é estado. É registro de ação. O deal pode ficar ali 30 dias sem nenhuma mudança real — e o funil não vai mostrar isso.
Multiplicar etapas para compensar falta de critério. Quanto mais etapas baseadas em tarefa, mais o funil vira ruído. A ilusão de controle aumenta. A leitura de maturidade desaparece. Etapa sem dono vira cemitério de cards.
Automatizar antes de validar a premissa da etapa. Robô em etapa errada não resolve o problema — executa o problema em escala. Automação não conserta processo confuso. Ela o repete com consistência industrial.
Confundir CRM com diário de bordo. O CRM pode ter registrado tudo que o vendedor fez. Isso não significa que ele sabe onde o negócio está. São perguntas diferentes. O funil responde à segunda — não à primeira.
—
Regra de ouro
Etapa não é o que você fez. É o que o negócio virou.
E o corolário operacional: se você desligar todos os robôs vinculados a uma etapa, o nome dela ainda precisa fazer sentido para a equipe. Se não fizer, a automação estava compensando uma premissa errada — não acelerando uma boa.
—
Aplicação prática
Esta semana, abra o funil de negócios no Bitrix24 e leia o nome de cada etapa. Para cada uma, responda em voz alta:
“Quando um card chega aqui, o que mudou no deal — não o que eu fiz?”
Se travar em alguma etapa, é ali que o funil está quebrando. Renomeie com base no estado real do negócio. Depois revise as automações vinculadas — se o nome mudou, a lógica de disparo precisa ser revisada junto.
Não é auditoria de processo. É leitura de premissa. Leva menos de uma hora. Pode mudar o que o CRM diz sobre sua operação.
Se você olhou para o funil e não conseguiu responder a pergunta para mais de duas etapas, o problema não é o Bitrix24 — é o modelo que está dentro dele.
Isso é diagnóstico antes de configuração. É o tipo de trabalho que faço antes de qualquer automação. Se quiser conversar sobre como seu funil está estruturado, fale comigo.
—