Higiene de pipeline em que o financeiro confia: o playbook de um Gerente de RevOps

Sexta à tarde. Reunião de forecast. O CFO abre o board, joga um filtro nele (close date mais antigo que hoje, estágio igual a Commit), e a tela enche. Quarenta e sete opps. Seis delas acima de US$ 100 mil. A câmera do CRO desliga. A liderança de vendas começa a digitar no chat lateral. A sala fica em silêncio, e você sabe exatamente o que vem a seguir, porque você é o Gerente de RevOps e isto agora é problema seu.

Você já viu esse filme. As opps não eram falsas no último trimestre. Elas ficaram reais, e aí ninguém as moveu. Os reps pararam de tocar nos close dates. Os gerentes pararam de pressionar. Em algum momento, "Commit" virou um estacionamento, e o estacionamento virou o forecast. O CFO sabe que isso está acontecendo. Ele só precisava de três filtros para provar.

A higiene de pipeline é a disciplina que previne exatamente esse momento. Não uma limpeza trimestral. Não um projeto. Um hábito semanal, aplicado da mesma forma toda semana, com regras que todos conseguem ver. Este playbook percorre as quatro peças que reconquistam a confiança do CFO: critérios de saída de estágio com evidência real, a regra dos 14 dias para deals parados, disciplina de close date e os três relatórios do Salesforce que o financeiro de fato abre na segunda de manhã.

Critérios de saída de estágio: substantivo + verbo + evidência

A maioria das definições de estágio é inútil. "Discovery: o rep qualificou a oportunidade." Qualificou como? Diz quem? Mora onde? Você não consegue auditar sentimentos, e o CFO não vai aceitar sua palavra.

Cada saída de estágio precisa de três coisas: um substantivo (o artefato que tem que existir), um verbo (o que o rep fez para criar ou anexá-lo) e uma evidência (o campo, arquivo ou registro onde ele mora no CRM). Sem artefato, sem avanço. Essa é a regra. Os reps não podem convencer uma opp a entrar no próximo estágio na conversa. Eles têm que produzir algo.

Aqui está como isso fica na prática:

Discovery → Working: um resumo de chamada de qualificação (substantivo) registrado (verbo) no registro da opp com participantes, dor confirmada, faixa de orçamento e prazo de decisão (evidência: registro de atividade obrigatório na opp).
Working → Proposal: um plano de ação mútuo assinado (substantivo) anexado (verbo) ao registro da opp (evidência: arquivo na lista relacionada de Files, com data e ambas as assinaturas).
Proposal → Negotiation: um redline ou resposta a proposta por escrito (substantivo) recebido do comprador (verbo) e carregado na opp (evidência: anexo de e-mail ou documento, datado nos últimos 14 dias).
Negotiation → Commit: um sim verbal do economic buyer (substantivo) confirmado por escrito (verbo). Até um e-mail de uma linha "estamos prontos, faltando só o papel" conta (evidência: e-mail registrado, nome do comprador batendo com o campo EconomicBuyer).

Note o que não está nesta lista: otimismo do rep, intuição do gerente, "eles estão muito empolgados". Isso não move estágios. Artefatos movem estágios. O motivo de isso importar para o financeiro é que cada artefato é algo que o CFO pode auditar depois. Quando um deal escorrega, você consegue puxar a opp, olhar o que foi anexado em cada estágio e responder à única pergunta que importa: o critério de saída algum dia foi real?

Se a resposta é não, se o deal avançou para Commit sem uma confirmação do comprador por escrito, você tem um problema de processo, não um problema de forecasting. E problemas de processo têm conserto.

A regra dos 14 dias para deals parados

Um deal que ninguém tocou em duas semanas não é um deal. É uma esperança.

A regra dos 14 dias para deals parados é simples: qualquer opp sem atividade registrada (chamada, e-mail, reunião, nota) em 14 dias é sinalizada automaticamente. A flag é um campo na opp, IsStale__c, que vira true automaticamente. Opps paradas aparecem no dashboard de segunda do rep com um banner vermelho e uma ação forçada: atualizar o close date, registrar um toque ou mover o estágio. Escolha uma.

Por que 14 dias, não 30? Porque o momentum decai rápido. Uma vez que um comprador passa duas semanas sem ouvir de um rep, o rep não é mais a voz mais recente na cabeça dele. Um concorrente é, ou a política interna deles é, ou o projeto simplesmente caiu na lista de prioridades. Os dados sobre velocidade de deals B2B são consistentes aqui: opps que ficam em silêncio por 30+ dias fecham a menos da metade da taxa de opps com toques semanais. Quando você sinaliza aos 30, você já perdeu o deal em tudo menos no nome.

A escada de escalonamento funciona assim:

14 dias parado: flag no dashboard do rep, ação obrigatória nesta semana.
21 dias parado: a opp aparece na fila de revisão de segunda do gerente. O gerente tem que decidir: isto é real, ou estamos mentindo para nós mesmos?
28 dias parado: rebaixamento automático de um estágio, ou close-lost por padrão. O gerente pode sobrepor, mas a sobreposição é registrada com um código de motivo.

O rebaixamento automático é a parte que o financeiro adora. Ele remove o incentivo do rep de deixar peso morto em Commit só porque o botão de close-lost é desconfortável. O sistema faz a coisa desagradável dentro de um cronograma, e o rep pode objetar com evidência, mas o ônus da prova virou.

Um padrão para ficar de olho: reps burlando a regra ao registrar um e-mail de uma linha "passando para ver" a cada 13 dias. O conserto é exigir que a atividade tenha um corpo significativo. Melhor ainda, acompanhe respostas únicas do comprador, não toques únicos do rep. Um toque sem resposta é meio toque.

Disciplina de close date

O campo close date é o campo mais mentido do seu CRM. É também o campo em que o CFO menos confia, com razão. Todo trimestre, centenas de opps escorregam do trimestre atual para o seguinte, muitas vezes na última semana, muitas vezes sem ninguém anotar por quê.

Aqui está a disciplina que conserta isso:

Antecipar sem um motivo escrito = rebaixamento. Se um rep move um close date para antes, ele tem que preencher um campo CloseDateChangeReason. Sem motivo, sem salvar: torne obrigatório por validation rule. Antecipações sem rastro de papel costumam ser pensamento mágico, e pensamento mágico é a matéria-prima de um trimestre perdido.

Empurrar para frente mais de duas vezes num único trimestre = sobreposição só por gerente. O primeiro escorregão é um escorregão. O segundo é um padrão. O terceiro é um rep que perdeu o controle do deal, e só um gerente deveria ter permissão de estender o prazo. A validation rule trava o campo; o gerente destrava com uma justificativa escrita registrada na opp.

Acompanhe a idade do close date. Esta é a métrica subestimada. CloseDateAge__c = dias desde que o close date foi editado pela última vez. Uma opp com um close date que não é tocado há 60 dias quase certamente vai escorregar. O rep parou de prestar atenção nele, o que significa que parou de trabalhar de trás para frente a partir dele. Faça aflorar close dates envelhecidos no dashboard do gerente ao lado de opps envelhecidas.

Close dates envelhecidos são a razão número um pela qual CFOs perdem a confiança no pipeline. Quando o mesmo close date fica numa opp por um trimestre inteiro e aí magicamente "se move" três dias antes do forecast de fim de trimestre, o financeiro sabe que o rep não estava de fato gerenciando o deal. Estava gerenciando o relatório.

O post-mortem forense do "trimestre perdido"

Quando um trimestre erra, você não pode pular a autópsia. A autópsia é o que te dá o direito de fazer forecast do próximo trimestre.

Aqui está o forense. Puxe cada opp que estava em Commit no Dia 1 do trimestre e não fechou. Para cada uma, preencha cinco colunas:

Em que estágio ela morreu? Escorregou de volta para Working? Empurrou para o próximo trimestre? Close-lost?
O critério de saída algum dia foi real? Vá olhar os artefatos. Havia um MAP assinado anexado quando avançou para Proposal? Havia um sim por escrito do comprador quando chegou a Commit? Metade das vezes, a resposta é não, o que significa que o deal nunca foi Commit, o sistema só estava deixando os reps dizerem que era.
O close date algum dia se moveu? Se sim, quando, em quanto, e um motivo foi registrado? Padrão de escorregões geralmente prevê a eventual perda.
O rep sinalizou risco? Cheque o campo de risco do deal, as notas de 1:1 do gerente, as notas da reunião de forecast. Se o risco foi sinalizado e ignorado, é um problema de gestão. Se o risco nunca foi sinalizado, é um problema de coaching.
Onde o deal de fato quebrou? Champion saiu? Procurement empacou? Concorrente ganhou no preço? Mudança de prioridade interna? Use uma lista fechada de códigos de motivo, sem texto livre, para conseguir pivotar os dados depois.

Construa como um brief de uma página. Topo da página: ARR total de Commit no Dia 1, total fechado, gap. Abaixo disso: uma tabela de cada deal perdido com as cinco colunas. Rodapé da página: três padrões e três consertos para o próximo trimestre.

Compartilhe com a liderança de vendas e com o financeiro. Mesmo brief, mesmos números, mesma semana. O motivo de isso importar é a confiança. O CFO não precisa de um forecast perfeito. Ele precisa saber que, quando você está errado, você consegue explicar por quê, e que a explicação vai melhorar o próximo forecast. Forenses transformam erros em precisão que compõe ao longo do tempo.

Um trimestre perdido sem post-mortem é um trimestre perdido que você vai repetir.

Por que CFOs desconfiam do pipeline (e como reconquistar isso)

CFOs veem o pipeline como uma camada de ficção de vendas sobre o livro-razão. Bookings caem no razão. Pipeline mora no CRM. Os dois nunca batem, e o CFO já foi queimado vezes suficientes por forecasts em forma de taco de hóquei que erram por 30% para assumir o pior.

Você reconquista a confiança com uma coisa: consistência chata. Mesmas definições toda semana. Mesmos cortes toda semana. Mesmos relatórios toda semana. Sem dashboards-surpresa, sem novas métricas no meio do trimestre, sem "mudamos a metodologia este mês". Mudanças de metodologia parecem truque de mágica para um CFO, mesmo quando são melhorias, porque toda mudança de metodologia também é uma oportunidade de esconder um erro.

A outra coisa que o financeiro quer ver é uma matemática de coverage honesta. O livro-texto diz que você precisa de 3x a 4x de pipeline coverage ponderada para atingir sua meta de bookings. Times saudáveis rodam a 3x a 4x. Quando você vê um time rodando a 5x ou 6x, isso não é força. É um sinal amarelo, geralmente significando que o pipeline é meio falso, cheio de opps fantasmas que nunca vão fechar, e o time está compensando empilhando mais pipeline ruim. A regra dos 5x é um número de autoengano. Mostre ao seu CFO dessa forma: "Estamos a 5,2x de coverage, o que significa que nosso pipeline qualificado provavelmente está 30% inflado. Aqui está o plano de limpeza."

Chamar seu próprio pipeline de fraco, por escrito, antes que o CFO tenha que chamá-lo de fraco, é a jogada de maior confiança que você pode fazer. Eles vão lembrar disso. Vão fazer forecast com os seus números no próximo trimestre sem fazer três perguntas de acompanhamento, e esse é o momento em que você de fato conquistou a cadeira.

Os três relatórios do Salesforce que o financeiro de fato abre

Um Gerente de RevOps que sobrevive à mesa do CFO tem três relatórios marcados como favoritos, enviados toda segunda às 8h e fixados no topo do dashboard do time de financeiro. Esses não são relatórios sofisticados. São os chatos, que contam a verdade.

Relatório 1: pipeline coverage por trimestre

Um relatório matricial simples:

Linhas: meta de bookings por trimestre (atual + 2 seguintes).
Colunas: pipeline ponderado (Valor × Probabilidade), pipeline não ponderado (só Valor), índice de coverage.
Formatação condicional: 3x ou abaixo = vermelho, 3x a 4x = verde, 4x a 5x = amarelo, 5x+ = vermelho (a cor de alerta de autoengano).
Filtro: estágio maior ou igual a Working, close date no trimestre.

O motivo de o financeiro amar este relatório: é uma tela só, é colorido e pune tanto a sub-coverage quanto a sobre-coverage. O CFO consegue abri-lo num celular e saber se deve se preocupar.

Relatório 2: opps envelhecidas por estágio

Um relatório-resumo agrupado por estágio, com um corte de idade de 30 dias:

Filtro: estágio = (Discovery, Working, Proposal, Negotiation, Commit), dias no estágio atual > 30.
Colunas: contagem de opps, soma de ARR, média de dias no estágio, dono.
Ordenação: ARR decrescente.

Este é o relatório que faz aflorar o pipeline falso. Quando você vê US$ 4M de ARR sentados em Working por 60+ dias, isso não é pipeline. É uma pilha de opps que os reps não têm coragem de marcar como close-lost. Opps envelhecidas são o indicador antecedente de um erro de forecast seis semanas antes de ele acontecer, e são o alvo de limpeza de pipeline mais barato no board.

Relatório 3: escorregão de close date

Um relatório customizado sobre OpportunityFieldHistory (ou um campo customizado rastreado se você não tem o field history habilitado):

Filtro: opps em que o close date se moveu mais de 30 dias nos últimos 90 dias.
Agrupar por: rep, depois código de motivo.
Colunas: nome da opp, close date original, novo close date, dias escorregados, motivo.

O financeiro abre este relatório antes da QBR. Ele diz a eles, por rep, quem está gerenciando close dates como compromissos e quem está gerenciando como sugestões. Também diz a eles quais códigos de motivo são dominantes. Se 60% dos escorregões são "champion saiu", é um problema de discovery. Se 60% são "revisão jurídica", é um problema de engajamento do procurement. Cada padrão aponta para um conserto diferente.

Esses três relatórios deveriam caber num único dashboard do Salesforce. Intitule-o "Defensabilidade do Forecast". Compartilhe com o financeiro, o CRO e cada gerente de vendas. Depois nunca mude. A consistência chata é o ponto.

A disciplina semanal

Aqui está como uma semana de higiene de pipeline de fato fica para um Gerente de RevOps:

Segunda 8h: os três relatórios são enviados automaticamente ao financeiro, ao CRO e aos gerentes de vendas. Você os escaneia em busca de mudanças desde a semana passada.
Segunda 9h: os dashboards dos reps atualizam com flags de parado, close dates envelhecidos e itens de ação forçada. Os reps os limpam antes do 1:1 com o gerente.
Terça: 1:1s dos gerentes. Os gerentes percorrem os escalonamentos de flag de parado, decisões de sobreposição registradas com códigos de motivo.
Quarta: reunião de forecast. Coverage do trimestre atual, escorregões e progresso de post-mortem em quaisquer deals que viraram close-lost na semana anterior.
Quinta: dia de limpeza. O time de RevOps trabalha em quaisquer flags de qualidade de dados dos relatórios (campos faltando, links quebrados, mudanças de dono).
Sexta: travamento do forecast. O número que vai para o financeiro é o número dos relatórios, sem ajustes manuais, sem adições de última hora.

Mesma semana, toda semana. Mesmos relatórios. Mesmas definições. O CFO não precisa de um forecast perfeito: ele precisa de um defensável. A defensabilidade vem de regras que todos conseguem ver, aplicadas da mesma forma toda semana, com evidência que todos conseguem auditar.

Esse é o trabalho inteiro, e é a diferença entre um Gerente de RevOps que sobrevive ao próximo trimestre perdido e um que não.

Playbooks de RevOps