Português

Armadilhas comuns de RevOps: 7 paredes que você vai bater entre 6 e 18 meses (e como atravessá-las)

Você já passou da lua de mel de novo contratado. O CRO sabe seu nome. Sua fila está cheia. Mas algo parece estranho. Vendas está irritada com algo que você não consegue nomear direito. Seus dashboards não estão sendo abertos. O VP fica fazendo a mesma pergunta de forecast três QBRs seguidas, e você fica dando uma resposta em que ele não confia muito.

Bem-vindo à parede. Toda pessoa de RevOps bate nela em algum momento entre o mês 6 e o mês 18. O trabalho que te contratou (limpar bagunças óbvias, entregar as primeiras vitórias rápidas) não te leva a Sênior. A próxima marcha é diferente, e ninguém te entrega o playbook.

Então aqui está. Sete paredes, na ordem em que costumam aparecer, com o sintoma, o número real que prova que está acontecendo e o que fazer esta semana.

Armadilha 1: construir relatórios do Salesforce que ninguém lê

Sintoma. Você entrega um dashboard. O VP te dá um emoji de joinha no Slack. Você se sente bem por umas 48 horas. Depois você checa a contagem de visualizações e está estagnada em 3: você, seu gerente e o job de auto-refresh.

O número real. Rode um relatório de Lightning Usage (ou o equivalente do seu CRM) e puxe as contagens de visualização de cada dashboard que você construiu nos últimos 90 dias. O corte honesto: menos de 5 visualizadores únicos por mês depois da semana 2 significa que está morto. A maioria dos dashboards construídos por ops cai aí. Eu já auditei organizações com mais de 80 dashboards onde os 5 do topo respondiam por 92% de todas as visualizações.

O que de fato dizer. Da próxima vez que alguém disser "você consegue construir um dashboard para X", pergunte: "Me explica a reunião em que você o abriria. Quem mais está na sala? Que decisão muda com base no que ele diz?" Se não conseguirem responder em 30 segundos, o dashboard ainda não existe porque a decisão ainda não existe.

O conserto. Pare de construir até alguém pedir duas vezes. O primeiro pedido é um clima. O segundo pedido, duas semanas depois, é uma necessidade real. Substitua 3 relatórios não lidos por 1 digest semanal no Slack atrelado a uma decisão específica: "A pipeline coverage está em 2,8x entrando no Q3, precisamos dela em 3,5x, aqui estão os 4 segmentos onde estamos curtos." Isso é lido. Isso é encaminhado. Isso te coloca no slide da QBR.

Armadilha 2: customizar demais o CRM (a dívida técnica compõe rápido)

Sintoma. Abra o objeto Opportunity na sua configuração de Salesforce ou HubSpot. Conte os campos customizados. Se a sua reação visceral é "eita", você já sabe. Há 47 campos customizados, 12 record types e uma validation rule de 2024 que ninguém lembra de ter escrito ou pedido.

O número real. Dois cortes. Se você tem mais de 30 campos customizados por objeto, você está em dívida. Se mais de 15% desses campos têm uso abaixo de 5% entre os registros, você está pagando os juros da dívida em vez de quitá-la. Puxe um relatório de utilização de campos (o Salesforce Optimizer faz isso de graça; o HubSpot tem Field Insights). O número te diz tudo.

Por que importa. Cada campo morto é um imposto sobre cada relatório, cada page layout, cada onboarding de novo rep e cada integração que tem que mapear o schema. Um CRM inchado não só parece lento: é o motivo pelo qual seu modelo de forecast não consegue confiar nos dados que entram.

O conserto. Ritual trimestral de limpeza de campos. Puxe o relatório de utilização. Qualquer coisa abaixo de 10% de uso por registro que não foi editada em 90 dias vai para a lista de execução. Anuncie no #revops-changes por duas semanas. Desative, não exclua, e documente a descontinuação num CHANGELOG corrente que você mantém numa página compartilhada do Confluence. Depois de três trimestres disso, a organização fica mais limpa em vez de mais suja, o que por si só te coloca à frente de 80% das pessoas de RevOps.

Armadilha 3: pular o cerimonial de execução para automações mortas

Sintoma. Process Builders, Flows, receitas do Workato e Zaps de 2023 ainda disparando em cada registro. Você abriu um ontem e o campo de descrição dizia "TODO: escrever descrição". Ninguém sabe o que metade deles faz. Ninguém quer desligá-los porque ninguém quer ser o que quebrou alguma coisa.

O número real. Conte os flows ativos na sua organização. Depois conte os flows que foram tocados (editados, depurados ou até abertos) nos últimos 90 dias. O gap costuma ser de 40% a 60%. Essa é a sua superfície de automação morta, e cada um deles é um futuro incidente Sev 1 esperando o edge case certo.

Por que é difícil. Matar automações parece mais arriscado do que construí-las. Construir = vitória visível. Matar = vitória invisível, a menos que algo quebre, caso em que vira uma perda visível. Então a organização acumula flows do jeito que um HD acumula arquivos.

O conserto. Revisão mensal da lista de execução, no calendário, tratada como uma reunião de verdade. Três regras:

  1. Sem dono ativo (pessoa não está mais na empresa, sem substituto designado) → candidato a execução.
  2. Sem edições em 12 meses E sem documentação → candidato a execução.
  3. Os logs mostram <1 execução por mês → candidato a execução.

Desative primeiro, não exclua. Espere 30 dias. Se ninguém gritar, exclua e escreva o funeral no seu CHANGELOG: o que fazia, por que morreu, o que substituiu (se algo). O funeral é o ponto. Ensina a organização que matar coisas é normal, que é como você corta o inchaço na raiz.

Armadilha 4: perseguir precisão de forecast sem consertar a higiene de pipeline

Sintoma. O CRO quer ±5% de precisão de forecast. Você está construindo modelos de pipeline ponderado, incorporando sentimento de chamada dos reps, talvez até pilotando uma ferramenta de forecast com IA. Enquanto isso, 38% das opps abertas no sistema têm um close date no passado. Você está resolvendo o problema errado.

O número real. Puxe o percentual de pipeline aberto em que o close date está mais de 14 dias no passado em relação a hoje. Organizações saudáveis ficam abaixo de 10%. Organizações não saudáveis ficam em 30% a 45%. Um modelo de forecast alimentado por datas paradas é uma calculadora com inputs aleatórios, e nenhuma sofisticação de modelo vai salvá-lo.

A conversa honesta com o CRO. "Não conseguimos atingir ±5% de precisão num pipeline onde 38% das opps estão paradas. A matemática literalmente não fecha. Me dê 6 semanas em higiene, depois 6 semanas no modelo. Se pularmos a etapa de higiene, só vamos estar errados com mais confiança."

O conserto. Higiene primeiro, modelo depois. Entregue um relatório semanal de dados parados atrelado a scorecards de reps: contagem de opps paradas, valor em $ de opps paradas, dias desde a última atividade. Torne-o visível no canal de liderança de vendas. Atrele-o à responsabilização na reunião de forecast: se um rep coloca uma opp em commit e o close date está 3 semanas no passado, essa opp não pode estar em commit. Quando a taxa de paradas cair abaixo de 12%, aí sim fale de modelos. Pipeline coverage em que você confia bate metodologia de forecast em que você não confia.

Armadilha 5: virar o "tira-pedidos" em vez do estrategista

Sintoma. Você abre o Jira na segunda. Quarenta e três tickets. "Adicionar valor de picklist." "Novo relatório para a região 4." "Corrigir erro de digitação na definição de estágio." Agora é sexta. Você entregou 41 deles. Você não moveu um projeto real para frente em seis semanas. Você está exausto e de alguma forma também envergonhado.

O número real. Acompanhe seu tempo por duas semanas (Toggl, Clockify, até uma planilha serve). Se menos de 20% vai para trabalho de projeto e mais de 80% vai para tickets, você foi absorvido. Você não é mais RevOps, é helpdesk de CRM. O impacto na carreira é brutal: vagas de RevOps Sênior são preenchidas por gente que entregou projetos, não por gente que fechou tickets.

Por que acontece. Tickets parecem produtivos. Cada um fecha com um check verde. Eles também são infinitos, porque cada time trata RevOps como seu admin pessoal assim que uma pessoa diz sim a uma coisa.

O conserto. Modelo de office hours. Bloqueie seu calendário. Os tickets são triados duas vezes por semana, em duas janelas de 2 horas (digamos, terça 13h-15h e quinta 13h-15h). Fora dessas janelas, a fila está fechada a menos que algo esteja genuinamente pegando fogo (produção fora do ar, impacto na remuneração, bloqueio de deal). Proteja 2 dias inteiros para trabalho de projeto. Diga ao seu gerente exatamente isto: "Se eu quiser entregar o modelo de territórios e a reconstrução do forecast neste trimestre, preciso de 2 dias protegidos por semana. Aqui está o que não vai ser entregue se eu não os tiver."

A primeira semana parece desconfortável. Na quarta semana, a organização se adapta. Na oitava semana, os solicitantes começam a resolver 30% dos próprios tickets porque o atrito os fez pensar primeiro. Esse é o ponto inteiro.

Armadilha 6: recortar territórios rápido demais

Sintoma. Você recorta territórios no Q2 porque "os dados disseram". Os reps se revoltam. Três top performers ameaçam sair. O CRO reverte a mudança no Q3. Você agora passou seis meses rodando uma mudança que produziu pipeline negativo e queimou capital político que não se recupera fácil.

O número real. Benchmarks internos em organizações de vendas mid-market colocam em 15% a 25% a destruição de pipeline coverage durante uma transição de território, recuperada ao longo de 6 a 9 meses se o corte foi bom e 12+ meses se foi ruim. Esse custo é invisível numa planilha mas catastrófico num deck de board.

Por que acontece. Pessoas de RevOps veem desequilíbrio nos dados (o Rep A tem 2,3x as contas nomeadas do Rep B), e o cérebro de otimização diz "conserta isso". O cérebro de otimização esquece que territórios também são relacionamentos, conversas em andamento, deals meio fechados e o modelo mental de um rep sobre quem ele está trabalhando. Você não está só movendo contas numa planilha, você está cortando dez meses de contexto.

O conserto. Três regras.

  1. Mínimo de doze meses entre recortes significativos. Se você precisa recortar com mais frequência, a lógica de segmentação subjacente está errada, não os territórios.
  2. Pilote antes do rollout global. Teste a nova lógica em um segmento (uma geografia, um vertical de indústria) por um trimestre inteiro. Meça pipeline coverage, velocidade de deals e satisfação dos reps antes de propagar.
  3. Reps na sala. Apresente o corte proposto aos top 3 reps de cada segmento antes de travá-lo. Eles vão pegar os problemas do tipo "a Conta X está em negociação ativa, não mover" que uma planilha não vê.

Um plano de território mais lento que se sustenta por 18 meses bate um rápido que é revertido em 6.

Armadilha 7: não fazer parceria com o financeiro em atribuição

Sintoma. Marketing afirma que originou 60% do pipeline. O financeiro fecha os livros e reporta 22%. O CRO está numa reunião de board tentando explicar os dois números. Você é a pessoa que tem que entrar e limpar a bagunça. Tanto Marketing quanto Financeiro estão tecnicamente "certos" porque estão usando definições diferentes, intervalos de data diferentes e janelas de atribuição diferentes.

O número real. Se o número de pipeline originado do seu CRM não reconcilia com os bookings do Financeiro dentro de 10%, você tem um problema de credibilidade e ainda não sabe. O board sabe, porém, e isso aparece como "não confiamos no número do marketing" em conversas das quais você não participa.

Por que isto importa mais do que parece. Divergências de atribuição são um substituto da confiança entre Marketing e Financeiro, e RevOps fica exatamente no meio. A pessoa de RevOps que conserta isso vira o operador de maior confiança da empresa dentro de um trimestre, porque todo executivo do prédio está silenciosamente irritado com isso há anos.

O conserto. Sync mensal de atribuição com FP&A. Uma hora, no calendário, implacável. A pauta é sempre a mesma:

  1. Reconcilie o número de pipeline originado do mês passado com os bookings. Mostre a matemática.
  2. Trave as definições para o mês seguinte: o que conta como originado por marketing, o que conta como influenciado, qual intervalo de data, qual janela de atribuição.
  3. Aprovem o slide da QBR juntos. Mesmo número, mesmas definições, os dois lados na mesma página antes de qualquer um ver o CRO.

Em dois ciclos, o gap encolhe de 38% para 8%. Em três ciclos, o Financeiro começa a te copiar na preparação de board. Esse é o momento em que você deixa de ser um Gerente de RevOps e começa a ser um operador na trilha de Diretor.

O que essas paredes de fato estão te dizendo

Bater nessas paredes não significa que você é ruim no trabalho. Significa que você está aí há tempo suficiente para enxergar a forma da função.

Os primeiros seis meses recompensam pessoas que conseguem entregar: limpar a bagunça óbvia, construir os dashboards óbvios, fechar os tickets óbvios. Os doze meses seguintes recompensam pessoas que conseguem escolher: escolher o que não construir, o que matar, quais conversas liderar, qual número defender numa sala com o CRO e o CFO.

Os que atravessam param de otimizar para atividade e começam a otimizar para as duas perguntas que um CRO de fato faz: "Qual vai ser o número?" e "O que mudou?". Cada dashboard, cada flow, cada recorte de território, cada discussão de atribuição ou te ajuda a responder essas duas perguntas ou não. Se não ajuda, é ruído, e a fila está cheia de ruído.

Escolha a parede em que você está mais perto agora. Rode o diagnóstico esta semana. Entregue o conserto na semana que vem. Depois volte e leia a próxima.

Saiba mais