Uma conta de 600 funcionários baixa um material técnico. Vale a pena seguir o caminho dela, porque cada parada mostra o ponto exato em que uma das funções deixa de olhar.

Dia 0: A automação soma pontos por cargo, tamanho e engajamento. A conta passa de 70, vira MQL, entra na fila. Marketing Ops registra mais um no volume da semana e a conta sai do painel dessa função.

Dia 1: O roteamento distribui por território. A conta cai com um AE que trabalha outro segmento. Sales Ops mede tempo de resposta e cobertura de fila, e nenhuma das duas métricas enxerga adequação.

Dia 4: O AE abre a conta, avalia e não trabalha. Não recusa formalmente, porque recusar exige justificar. A conta envelhece na fila. Nesse momento ela deixa de existir como sinal em qualquer sistema: não é recusa, é pipeline não trabalhado, o que Sales Ops lê como disciplina de rotina.

Dia 30: A rotina de limpeza devolve a conta para nutrição. Marketing Ops recebe de volta um registro sem motivo associado e recoloca a conta na próxima campanha, com o mesmo score que já tinha.

Dia 90 e dia 150: O ciclo se repete duas vezes, com campanha nova e mesmo desfecho.

Mês 7: A mesma conta chega por indicação de um cliente, fecha em seis semanas, e o CS herda nome, valor, data e produto contratado, sem saber que ela circulou três vezes antes.

Por que o vazamento não piora nenhum indicador

Este é o ponto que torna o problema difícil de enxergar. Nenhuma das três funções registrou queda.

Marketing Ops contou três MQLs dentro do critério da automação, com custo por lead estável. Sales Ops manteve a taxa de conversão sobre o que o time efetivamente trabalhou, porque a conta não trabalhada nunca entrou nesse denominador. CS ganhou uma conta nova com onboarding dentro do prazo.

O custo real foi de sete meses e três campanhas pagas sobre uma conta que já estava no perfil desde o dia zero. Esse custo não tem linha em nenhum painel, porque cada indicador é calculado dentro da própria faixa, e o intervalo entre as faixas fica fora dos três denominadores.

A previsão é o único lugar onde a soma aparece, e ali o dado já chegou agregado. A Pavilion, no CRO Survival Guide, descreve exatamente esse efeito ao observar que o que parece um problema de pipeline costuma ser uma série de entradas desalinhadas chegando à previsão.

Os três pontos cegos entre as funções

O percurso acima expõe três lacunas específicas, e nenhuma delas pertence a uma das funções isoladamente.

A não-ação não gera dado

Recusa formal gera registro. A conta que o AE abre, avalia e abandona não gera nada. Como recusar exige justificar e não recusar não custa nada, o comportamento racional do vendedor produz o pior resultado possível para a operação, que é a ausência de sinal.

A correção é operacional antes de ser cultural. Toda conta em fila precisa de prazo e de desfecho obrigatório, com uma lista curta de motivos. Sem prazo, a não-ação permanece invisível.

O score não conhece a capacidade

A pontuação de Marketing Ops mede adequação da conta. O território e a carteira de Sales Ops determinam quem recebe. As duas regras são construídas separadamente e se encontram no roteamento, sem que ninguém verifique a colisão.

Uma conta de alto score que cai num território sem cobertura é um custo de aquisição já pago que fica parado. Marketing Ops não vê o território, Sales Ops não vê o score.

A promessa da venda não atravessa

Quando a oportunidade fecha, o CRM entrega ao CS nome, valor, data e produto. Fica de fora o escopo combinado na conversa técnica, o prazo de primeiro resultado mencionado na negociação e a métrica que o cliente usa internamente para julgar a compra.

O efeito aparece meses depois, na análise de churn, onde cancelamento por expectativa desalinhada entra como problema de produto. O detalhe operacional dessas passagens está em como deve ser uma passagem de oportunidades estruturada.

O que o mercado resolve com organograma

A resposta padrão para esses três pontos cegos é criar uma função que olhe entre as faixas.

A Pavilion, no texto sobre como implementar RevOps no HubSpot, formula a pergunta com precisão: quem fica encarregado de procurar gargalos operacionais entre departamentos. A resposta que o texto dá é RevOps.

A HubSpot, no texto sobre estratégia de revenue operations, delimita as faixas. Sales Ops tem escopo estreito por desenho, com pipeline, quota, higiene de CRM, previsão e capacitação, reportando à organização comercial. Marketing Ops é a função paralela, dona de campanha, lead scoring, automação e atribuição, otimizada para volume de MQL e custo por lead. RevOps aparece como a unificação das duas, mais operações de CS, com responsabilidade sobre o ciclo de vida completo.

A Salesforce, no guia What Is Revenue Operations, corta pelo horizonte. Operações de vendas entram no meio do ciclo de receita, e operações de receita cobrem a jornada inteira, do desenvolvimento do produto à cobrança.

As três leituras descrevem bem a divisão de responsabilidade. Nenhuma delas resolve os três pontos cegos, porque criar uma quarta caixa no organograma não faz a não-ação virar dado, não faz o score conhecer a capacidade, e não faz a promessa da venda atravessar para o CS. O que RevOps precisa entregar além do desenho está em RevOps na prática.

A própria HubSpot registra o sinal de que o desenho não basta: quando vendas e marketing já estão alinhados e a empresa ainda vê dado inconsistente, passagem quebrada depois da venda e receita imprevisível, o texto recomenda a migração de Sales Ops para RevOps. A operação sente algo diferente, porque é possível ter as três caixas e o mesmo vazamento.

O que precisa ser compartilhado para o silo cair

Coordenar três funções por reunião custa uma reunião por semana e funciona enquanto a reunião existir. O que sustenta coordenação sem reunião é um conjunto de coisas que as três funções leem e escrevem no mesmo lugar. São sete, e cada uma fecha um tipo específico de vazamento.

A entidade: Conta é a unidade compartilhada. Enquanto marketing opera lead, vendas opera oportunidade e o CS opera assinatura, com identificadores distintos, a mesma empresa existe três vezes e nenhuma das funções consegue afirmar que fala da mesma coisa. Normalizar a entidade é anterior a qualquer indicador, porque sem isso a reconciliação de números vira trabalho semanal permanente.

A definição do indicador: MQL, SQL, aceite, ativação e churn calculados uma vez, com versão e data. Duas fórmulas com o mesmo nome descrevem duas operações. Com a versão gravada em cada registro, uma queda de conversão passa a ter resposta, porque é possível separar mudança de performance de mudança de definição.

A meta: A meta compartilhada da frente, com a contribuição declarada de cada função, em vez da soma de três metas de faixa. Quando Marketing Ops responde por volume e Sales Ops responde por win rate, as duas podem bater a própria meta enquanto a frente perde. A contribuição declarada torna visível qual função precisa mudar quando o número da frente não fecha.

O objetivo do Ciclo: O que a execução está perseguindo neste período, com critério de sucesso e critério de saída definidos antes de começar. Sem isso, cada função interpreta a prioridade pela própria fila, e a prioridade real passa a ser quem pediu por último.

A hipótese: O que a operação está testando, quem propôs, e o que precisaria ser verdade para funcionar. Sem registro, três funções testam em paralelo sobre a mesma base e nenhuma aprende com a outra. Uma hipótese que falha e não fica documentada volta como campanha paga no trimestre seguinte.

O risco: Concentração de pipeline em poucas contas, dependência de uma fonte de origem, movimento de preço de concorrente, território sem cobertura. Cada um com dono, gatilho e severidade. Risco que existe só na percepção de quem está perto some quando essa pessoa muda de time.

A ação cruzada: Uma ação que nasce em marketing e termina em vendas, com dono em cada etapa e status único. Enquanto a ação vive em três ferramentas, a passagem depende de alguém avisar, e a operação inteira herda o tempo de resposta do canal de mensagem.

O sétimo item é o retorno. O que o Ciclo ensina precisa alterar a definição vigente, e não apenas aparecer na retrospectiva. Sem esse fechamento, os seis itens anteriores envelhecem juntos.

A diferença entre essa camada e o resto do stack

Um leitor de RevOps levanta a objeção certa neste ponto: parte disso já existe em ferramenta que a empresa tem. Vale separar o que cada uma resolve.

O data warehouse normaliza o dado e não guarda a decisão. Ele responde qual foi o número, e não responde qual regra produziu o número nem quem alterou a regra.

O dashboard lê e não escreve. O indicador que aparece nele não abre trabalho, e a distância entre ver o número e agir sobre ele continua sendo uma reunião.

A ferramenta de tarefa escreve e não guarda a definição. A ação existe no board sem a hipótese que a justifica, e a revisão trimestral encontra execução sem premissa associada.

O CRM guarda bem o estado corrente do negócio, e sobrescreve o critério na edição seguinte, sem histórico de versão.

Os quatro são necessários e nenhum deles é o lugar onde definição, execução e aprendizado coexistem no mesmo modelo. A camada que falta lê e escreve nos três ao mesmo tempo: a definição vigente com versão, a ação que nasce dela com origem rastreável, e o retorno que altera a próxima versão.

A mesma conta, com a infraestrutura no lugar

Vale rodar o percurso do início outra vez, agora com os sete itens compartilhados.

Dia 0: A conta de 600 funcionários passa de 70 no score. O score é calculado sobre a definição vigente de ICP, que tem versão e dono, e a Iniciativa a que essa conta pertence declara qual segmento está sendo perseguido neste Ciclo.

Dia 1: O roteamento consulta território e capacidade no mesmo registro. A conta cai num território sem cobertura, e isso entra como item de decisão com responsável, em vez de virar atribuição silenciosa.

Dia 4: A conta tem prazo de desfecho. O AE avalia e marca o motivo numa lista de cinco opções mutuamente exclusivas. A não-ação deixa de ser gratuita, porque o prazo vence e o registro exige desfecho.

Dia 11: O motivo agregado mostra três contas do mesmo segmento paradas pelo mesmo motivo. A hipótese que sustentava esse segmento é revisada dentro do Ciclo aberto, com a fonte de origem ajustada e a definição de aceite atualizada para a versão seguinte.

O sétimo mês deixa de existir nesse percurso, porque a decisão sobre a conta acontece no dia 11, e não por indicação meio ano depois. O ganho não é de automação, é de tempo entre o sinal e a correção.

Quem responde pelo quê

A infraestrutura compartilhada não elimina a divisão de responsabilidade, ela muda o que cada função responde.

A definição tem dono único: Um responsável pelo critério de MQL, de SQL e de cada estágio, com versão e data. Quando a definição tem dois donos, ela é renegociada no meio do aceite, e a versão que vale passa a depender de quem fala por último.

A execução dentro da faixa continua distribuída: Sales Ops responde por pipeline e quota, Marketing Ops responde por campanha e score, e cada uma presta contas do próprio indicador dentro da mesma Iniciativa.

O retorno do intervalo tem destino nomeado: Motivo da não-ação, colisão entre score e território, e promessa que o CS herda. Um campo de exceção só permanece limpo quando algo a jusante o consome e devolve consequência para quem preenche.

Na Strataflow os sete itens vivem na mesma estrutura. O Workspace concentra a entidade normalizada, a definição vigente e a camada de dados, dentro da camada de Organização. As Iniciativas carregam meta, objetivo e hipótese da frente, e distribuem a execução entre as funções. Os Ciclos executam com critério de entrada, de saída e de sucesso definidos antes de começar. A camada de Operação mantém playbook e ação com a origem da decisão, e a camada de Orquestração recebe risco, motivo de recusa e recomendação como fila de decisão com severidade e responsável, com o GTM Agent apontando o próximo movimento de maior impacto.

Sales Ops continua no CRM, Marketing Ops continua na automação, e o CS continua na ferramenta de conta. A coordenação passa a ter um lugar próprio, em vez de depender de alguém reconciliar número depois do fechamento.

Perguntas frequentes

Qual a diferença entre RevOps e Sales Ops?

Sales Ops tem escopo estreito por desenho, com pipeline, quota, higiene de CRM, previsão e capacitação do time comercial, reportando à organização de vendas. RevOps cobre o ciclo de receita inteiro, do primeiro toque de marketing à renovação, com definição de dado e critério de passagem compartilhados entre as funções.

O que Marketing Ops faz que RevOps não faz?

Marketing Ops opera execução de campanha, lead scoring, automação e atribuição, otimizando indicadores próprios como volume de MQL e custo por lead. RevOps governa a regra que essas entradas precisam respeitar para que continuem válidas nas outras faixas.

Por que o vazamento entre as três funções é difícil de detectar?

Porque cada indicador é calculado dentro da própria faixa. A conta não trabalhada não entra no denominador de conversão de vendas, o lead devolvido sem motivo volta para a base de marketing com o mesmo score, e a soma só aparece na previsão, já agregada.

O que precisa ser compartilhado entre Marketing Ops, Sales Ops e CS?

Sete itens: a entidade normalizada, a definição de cada indicador com versão, a meta da frente com contribuição declarada por função, o objetivo do Ciclo com critério de sucesso, a hipótese em teste, o risco com dono e gatilho, e a ação que atravessa mais de uma função com status único.

Um data warehouse resolve o silo entre as funções?

O warehouse normaliza o dado e não guarda a decisão que produziu o número, nem a regra que mudou ao longo do tempo. Ele é necessário e insuficiente, porque o silo se sustenta na ausência de um lugar onde definição, execução e aprendizado convivem no mesmo modelo.

Criar uma área de RevOps resolve o problema?

Criar a caixa resolve o reporte. O intervalo continua sem dono enquanto a não-ação não gerar registro, o score não conhecer a capacidade do território, e a promessa da venda não atravessar para o CS.