Quando o admin de Salesforce se torna RevOps sem perceber
A diferença não está no crachá, está no tipo de pergunta que você é chamado para responder
Muitos admins de Salesforce assumem responsabilidades de RevOps antes de qualquer mudança formal de cargo. O que define essa virada não é o organograma, mas se você está resolvendo problema de receita ou apenas mantendo o sistema funcionando.
Todo mundo que já foi "o único admin de Salesforce" da empresa conhece esse filme. Você entra para dar suporte a um sistema, começar arrumando campo aqui, Flow ali, e num certo ponto a empresa inteira te trata como se você fosse dono do funil de receita. Ciclo de vida de lead, roteamento, atribuição, integração com contact center, dashboard de conversão, arquitetura de dados. Ninguém te promoveu para isso, mas o trabalho chegou.
Essa é uma dúvida clássica de quem carrega o rótulo "admin acidental": em que ponto o trabalho de configurar CRM vira RevOps de fato? A resposta curta é: quando você para de responder "como faço isso no Salesforce" e começa a responder "o que a receita da empresa precisa que o Salesforce faça". Isso é uma virada de escopo, não de ferramenta.
RevOps, na prática de quem já sentou nesse tipo de mesa, não é um cargo com crachá bonito. É a função que junta processo de vendas, dado, tecnologia e métrica de receita debaixo de uma governança só. Quando alguém pergunta "por que estamos perdendo lead nessa etapa do funil" e a resposta passa por desenhar processo, decidir estrutura de dado, construir automação e depois construir o relatório que prova que funcionou, esse alguém está fazendo RevOps, esteja ele no organograma de TI, de Vendas ou de Operações.
O detalhe que muda tudo aqui é a origem do pedido. Admin tradicional recebe ticket: "criar campo X", "ajustar esse Flow", "dar acesso a esse perfil". RevOps recebe problema de negócio sem solução desenhada: "mudar o pipeline de receita", "entender a fricção no funil". A tradução desse problema em arquitetura de CRM, em Record-Triggered Flow, em modelo de dados, em Sharing Rule, em relatório de atribuição é trabalho de arquitetura de negócio, não só de configuração de sistema.
Isso também explica por que tanta gente descobre "sou RevOps" sem nunca ter pedido esse título. Empresa pequena ou média não separa a função em times distintos de SalesOps, MarketingOps e CustomerOps com um RevOps orquestrando por cima, como acontece em operação grande e madura. Ela empilha tudo em quem já entende o sistema, e é assim que um admin que começou dando suporte a 80 usuários acaba desenhando processo de booking, decidindo modelo de atribuição e discutindo arquitetura de integração com contact center.
O ponto de virada real não é sobre estar em TI, Vendas ou Operações no organograma. É se você está sendo chamado para resolver problema de receita usando Salesforce como ferramenta, ou se está sendo chamado para manter o Salesforce funcionando enquanto o problema de receita é resolvido em outro lugar. A primeira situação é RevOps, com ou sem o crachá.
O sinal de arquitetura que ninguém fala
Tem um sintoma técnico bem concreto disso: quando o trabalho vira RevOps, o Salesforce para de ser só CRM e passa a ser plataforma de decisão. Isso significa modelo de dados pensado para atribuição multi-touch, integração validada com contact center antes de qualquer automação de roteamento, e dashboard que sobrevive a mudança de processo sem precisar ser refeito do zero. Se seu dia a dia já inclui decidir isso em vez de só executar pedido, o rótulo do cargo está atrasado em relação ao trabalho real.
Isso importa porque afeta carreira e remuneração diretamente. Quem entrega trabalho de RevOps sendo remunerado e posicionado como "admin de sistema" está subprecificado no mercado, e isso vira problema de retenção tanto para o profissional quanto para a empresa que vai perder essa pessoa assim que ela perceber o gap.
Também importa para quem contrata e desenha estrutura organizacional: empresa que empilha responsabilidade de RevOps em admin sem dar governança, apoio de dado e clareza de reporte está criando um ponto único de falha. Se essa pessoa sai, vai junto o conhecimento de processo, arquitetura e regra de negócio que nunca foi documentado formalmente.
Essa é a realidade de boa parte dos projetos de porte médio que eu vejo: a linha entre "admin de Salesforce" e "RevOps" nunca foi desenhada pelo RH, foi desenhada pelo problema de negócio que apareceu na sua mesa. Minha leitura é que o título importa menos do que a governança em volta do trabalho. Se você está tomando decisão de arquitetura de dado e processo de receita sem revisão formal, o problema não é seu cargo, é a falta de estrutura ao redor dele.
- Documente formalmente o escopo real do seu trabalho: liste decisão de processo, arquitetura de dados e projeto de automação que você toma, não só ticket que você resolve. Isso é munição para conversa de carreira e de salário.
- Se você está nessa posição, comece a tratar reporte e atribuição como produto, não como entregável pontual. Modelo de dados mal pensado para atribuição hoje vira dívida técnica cara de desfazer quando a empresa crescer.
- Se você contrata ou lidera, olhe para quem na sua empresa já faz esse papel informalmente e decida se vale formalizar a função de RevOps com estrutura, orçamento e reporte próprio, em vez de deixar acumulado em cima de quem "também é o admin de Salesforce".
- Acumular esse escopo sem governança formal cria risco de burnout e de decisão de arquitetura tomada sem revisão de pares, o que é perigoso em ambiente regulado como saúde.
- Automação de roteamento e atribuição construída sob pressão de negócio, sem validação de dado antes, tende a virar exceção comercial disfarçada de regra: cada gerente pede um ajuste e ninguém revisita o desenho original.
- Cargo e remuneração que não acompanham o escopo real geram rotatividade. Se a empresa depende de uma pessoa só para manter esse conhecimento vivo, isso é risco de continuidade, não elogio à versatilidade dela.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.