GTM engineering: o que a sigla nomeia, e o que muda quando o caminho até o cliente vira software

A sigla, e por que ela não é o Google Tag Manager

GTM engineering é construir como software o caminho que leva alguém de primeiro contato a cliente, em vez de operá-lo na mão. GTM é go-to-market: tudo o que uma empresa faz para chegar ao cliente e vender. A engenharia entra quando esse caminho deixa de ser uma lista de tarefas que alguém lembra de executar e passa a ser um sistema que executa uma regra escrita.

A confusão de sigla é a primeira coisa a tirar do caminho. Quem digita “GTM” numa busca costuma chegar ao Google Tag Manager, que é uma ferramenta de gerenciamento de etiquetas de rastreamento em sites — parente do analytics, e sem relação nenhuma com o que este guia descreve. Os dois convivem no mesmo departamento e falam de coisas diferentes: um serve para medir o que acontece numa página, o outro nomeia o trabalho de construir o caminho comercial inteiro.

O termo veio junto com uma mudança de composição de time. Durante anos, o trabalho de ligar ferramentas de marketing e de vendas coube a quem operava essas ferramentas: alguém do time montava um fluxo dentro do produto que já tinha, e o que não cabia ali era feito à mão, por gente, todo dia. Quando o volume subiu e as ferramentas passaram a ter porta de entrada programável, esse trabalho virou engenharia de verdade — com código, versão, teste e alguém responsável por ele quando quebra.

Quatro coisas que se confundem com isso

GTM engineering não é automação de marketing, não é RevOps, não é growth hacking e não é gestão de tráfego. Os quatro nomes descrevem trabalhos que existem, convivem com este e param em lugares diferentes: um opera a ferramenta, outro cuida do processo e do número, o terceiro testa hipótese de canal e o quarto compra mídia.

A confusão mais cara das quatro é com RevOps, porque as duas descrevem o mesmo funil. A divisão prática é de artefato: RevOps produz a decisão — esta é a etapa, este é o critério, este é o dono — e GTM engineering produz a coisa que executa essa decisão sem depender de alguém lembrar dela. Quando a mesma pessoa faz os dois, o sinal de que está acumulando é o calendário: metade da semana em reunião de processo, metade construindo, e as duas metades atrasando.

As cinco camadas do caminho até o cliente

Todo caminho comercial tem as mesmas cinco camadas, com nomes diferentes em cada empresa: captação, identificação, qualificação, resposta e registro. Elas se constroem uma a uma, e cada uma quebra de um jeito próprio — quase sempre por dado que não existe, e não por ferramenta que falta.

A ordem importa mais do que parece. Times que começam pela resposta — porque é a camada visível, a que o cliente sente — constroem um atendimento rápido em cima de um cadastro duplicado e de um critério que ninguém escreveu. O sistema fica bonito na demonstração e produz o mesmo trabalho de antes, com uma etapa a mais para conferir.

O que um GTM engineer faz, e o que ele não é

Um GTM engineer escreve com quem executa hoje a regra que o sistema vai seguir, liga os sistemas que a empresa já tem, e deixa medição de pé. Ele não é analista de dados, não é desenvolvedor de produto e não é vendedor — embora precise conversar com os três, e o dia dele seja quase todo essa conversa.

Na prática o trabalho tem três matérias, e elas se alternam. A primeira é a regra: sentar com quem faz aquilo hoje e escrever o que essa pessoa decide, incluindo o que ela faz nos casos em que hesita. A segunda é a ligação: fazer o CRM, o canal de mensagem, a base de dados e a ferramenta de campanha trocarem informação sem que alguém copie e cole no meio. A terceira é a medição: deixar visível o que o sistema fez, o que ele errou e o que ele devolveu para gente.

A primeira matéria é a que costuma consumir o prazo, e é a que ninguém orça. Escrever a regra é um trabalho de entrevista: a pessoa que qualifica leads há três anos não sabe dizer o critério dela de cabeça — ela sabe aplicá-lo. O que sai da primeira conversa é sempre incompleto, e a parte que falta é justamente a exceção que faz o sistema errar.

Que processo vira sistema, e qual não vira

Um processo está pronto para virar sistema quando passa em três testes: ele se repete, a decisão dele cabe escrita, e o dado de que ele precisa existe em algum lugar que o sistema alcança. Faltando um dos três, o que se constrói é uma automação que produz trabalho novo — conferir o que ela fez.

1. Ele se repete

   Acontece muitas vezes, do mesmo jeito, e alguém consegue dizer quantas vezes por semana sem pensar muito. Processo que acontece raramente custa mais para construir do que para continuar fazendo à mão — e o que se constrói fica sem uso o tempo suficiente para quebrar em silêncio.

2. A decisão cabe escrita

   Alguém consegue enunciar a regra em frases com “se” e “então”, inclusive a parte desconfortável: o que fazer quando os sinais se contradizem. Se a resposta honesta é “depende, a gente vê na hora”, o processo ainda não está pronto — e a primeira entrega do projeto é escrever essa regra, não programá-la.

3. O dado existe e é alcançável

   A informação que a regra pede está registrada em algum sistema, e esse sistema tem porta de saída. Dado que só existe na cabeça de alguém, ou preso numa ferramenta sem exportação, transforma a construção num projeto de coleta antes de ser um projeto de automação.

O que não vira sistema tem um padrão reconhecível: negociação, exceção cara e julgamento raro. Um desconto fora da tabela, um cliente grande que pede condição especial, uma reclamação que pode virar processo — nos três, o valor está justamente em uma pessoa decidir. O bom sistema não tenta cobrir esses casos: ele os identifica cedo e os entrega a alguém com o contexto inteiro junto.

Como se começa sem trocar tudo

Começa-se por um processo só, escrevendo a regra antes de escolher qualquer ferramenta, e rodando o sistema em espelho — ele decide, registra o que decidiria, e não envia nada — até que as decisões dele batam com as da pessoa que faz aquilo hoje. Só então ele assume.

A ordem inversa é a que produz a maior parte dos projetos abandonados: escolhe-se a plataforma, monta-se o fluxo dentro dela, e a regra vai sendo descoberta enquanto se constrói. O resultado é um sistema que herda os limites da ferramenta como se fossem decisões de negócio — e ninguém consegue mais dizer se aquele critério existe porque a empresa quis ou porque a tela não deixava fazer diferente.

O espelho é o passo que quase nunca é feito e que quase sempre paga o próprio custo. Durante um período curto, o sistema roda em paralelo com a pessoa: recebe os mesmos casos, decide, e grava a decisão sem agir. A comparação entre as duas colunas é o que revela a regra que ninguém contou — e ela aparece sempre, porque é a parte que quem executa não sabe que sabe.

O que medir depois que sobe

Um sistema de GTM se mede por cinco coisas, e nenhuma delas é o número de mensagens enviadas: tempo até a primeira resposta, cobertura do dado, taxa de escape para gente, erro de qualificação e o trabalho manual que deixou de existir. As cinco são comparáveis com o que havia antes, o que é justamente o ponto.

Anote como era antes. A comparação com o mês anterior é a única forma honesta de dizer que o sistema funcionou, e ela precisa ter sido registrada antes de o sistema existir. Projeto que sobe sem essa linha de base vira uma discussão de impressão, e a impressão do time é quase sempre generosa com o que ele acabou de construir.

Onde os projetos param

Quatro coisas param projetos de GTM engineering, e nenhuma delas é técnica: o mesmo dado existindo em três lugares que se contradizem, uma ferramenta sem porta de saída, uma regra que ninguém quis escrever, e o sistema sem dono depois que sobe. As quatro se descobrem no começo, se alguém perguntar.

O dado contraditório é o mais comum. O CRM diz uma coisa, a planilha do time de vendas diz outra, e a ferramenta de campanha tem uma terceira lista. Não existe sistema que resolva isso por cima: enquanto alguém não decidir qual é a fonte da verdade para cada campo, qualquer automação vai propagar a versão errada mais rápido do que a pessoa propagava.

A ferramenta sem saída é a que se descobre tarde. Parte dos sistemas de mercado só entrega o seu dado por exportação manual, ou o entrega em formato que perde o histórico. Isso não impede o projeto, mas muda o desenho dele — e é uma pergunta a fazer antes de assinar qualquer contrato de plataforma, não depois.

A regra que ninguém escreve é a que trava por dentro. Às vezes ela não está escrita porque ninguém sentou para escrever; às vezes porque escrevê-la obrigaria a empresa a tomar uma decisão que ela vem adiando — quem fica com o lead que chega pelo site, por exemplo. O projeto técnico vira, nesse ponto, uma conversa de gestão, e é melhor que isso apareça na primeira semana.

E o sistema sem dono apodrece. Ferramentas mudam as suas portas de entrada, campos são renomeados, alguém desliga uma integração para testar outra coisa. Um caminho construído precisa de alguém avisado quando ele para — e a resposta “o time inteiro cuida” é a mesma coisa que ninguém.

O que se diz por aí e não se confirma

Três afirmações circulam sobre GTM engineering sem apuração que as sustente, e as três empurram na mesma direção: fazer parecer que a parte difícil é a ligação entre as ferramentas. A parte difícil é a regra, e ela é trabalho humano.

Este guia também não traz estatística de mercado, e a ausência é decisão: os números que circulam sobre produtividade de time comercial e sobre ganho de automação não passaram no critério da Kapstan — estudo nomeado, instituição, amostra, data de campo e endereço primário conferido na publicação.

Por onde começar

Comece escolhendo um processo que já é feito na mão todo dia, escreva a regra dele com quem o executa, decida qual sistema é a fonte da verdade de cada campo, rode em espelho antes de deixar agir e defina quem é avisado quando ele parar.

1. Escolha um processo, e que ele seja chato

   O melhor primeiro caso é o mais repetitivo e o menos glamouroso: a conferência que alguém faz antes de ligar, a resposta que se repete, o cadastro que alguém copia de um lugar para outro. Regra madura, volume conhecido, e ninguém defendendo o jeito atual.

2. Escreva a regra com quem executa, e inclua as hesitações

   Uma folha por processo: o que entra, o que se decide, o que sai, e o que fazer quando os sinais se contradizem. A pergunta que rende mais é “em que caso você hesita?” — a resposta é a exceção que faria o sistema errar.

3. Nomeie a fonte da verdade de cada campo

   Telefone, empresa, etapa do funil, dono do contato. Enquanto dois sistemas puderem discordar sobre o mesmo campo sem que exista um vencedor declarado, qualquer automação estará espalhando a versão errada.

4. Rode em espelho antes de deixar agir

   O sistema decide e registra, sem enviar nada, enquanto a pessoa continua fazendo. Compare as duas colunas até elas pararem de divergir. Esse período custa pouco e é o único momento barato de descobrir a regra que faltava.

5. Defina quem é avisado quando ele parar

   Uma pessoa com nome, um canal onde o aviso chega, e o combinado do que fazer no meio-tempo — voltar ao manual, quase sempre. Sistema sem dono não avisa quando quebra: ele simplesmente para de aparecer no relatório.

O vocabulário mínimo

Cinco termos aparecem em toda conversa sobre GTM engineering e quase nunca são definidos por quem os usa. Eles estão aqui com o sentido que este guia lhes dá, e é o mesmo que os outros textos desta série usam.

GTM

Go-to-market: tudo o que a empresa faz para chegar ao cliente e vender — canal, oferta, prospecção, atendimento e o caminho entre eles. Não confundir com o Google Tag Manager, que é uma ferramenta de etiquetas de rastreamento.

Enriquecimento

Completar o registro de um contato com informação que ele não deu — empresa, porte, cargo, endereço — a partir de bases externas ou do seu próprio histórico. Vem sempre incompleto para uma parte dos casos, e o sistema precisa decidir o que fazer com essa parte.

Qualificação

Decidir se um contato merece a conversa, e com que prioridade, contra um critério escrito. Quando o critério não está escrito, cada pessoa qualifica pelo seu, e o sistema herda a média de opiniões que nunca foram comparadas.

Roteamento

A regra de quem atende o quê, em quanto tempo, e o que acontece se ninguém atender. É a parte do sistema que mais quebra em silêncio: o caso fora do previsto para num lugar que ninguém abre.

ICP

O perfil de cliente para o qual você constrói — porte, setor, problema, quem decide. Escrito, ele vira o critério de qualificação; não escrito, ele existe assim mesmo, na cabeça de cada vendedor, em versões diferentes.

Perguntas frequentes