Diagnose the GTM system before buying another tool

A request for a new CRM, automation, dashboard, or AI agent often arrives as if the diagnosis were complete. Leads are leaking, follow up is inconsistent, reporting is slow, so the missing object must be software.

That conclusion skips the commercial system. The visible pain may come from a missing capability, but it may also come from an undefined decision, disputed evidence, an ownerless state change, or an exception nobody closes. New software can make each of those defects run faster.

The job of a GTM diagnosis is not to defend the current stack. It is to identify the restriction before the business encodes it. A founder should approve a tool only when the failed commercial job is explicit and the team can show why the existing system cannot perform it.

Definition: a tool gap is a bounded execution gap

Definition: A GTM tool gap exists when a required commercial decision and its operating contracts are already defined, but the current stack cannot execute the job reliably within the constraints of the business.

The phrase "we need a better tool" is not yet a gap. It is a hypothesis.

A diagnosis tests that hypothesis against six contracts: decision, evidence, state, authority, exception, and learning. Together, they show whether the restriction sits in Truth, Playbook, Architecture, Operator, or in the actual capability of the software.

This is what a GTM engineering firm should clarify before recommending a platform. Commercial capacity comes from a runnable system, not from the number of products connected to it.

Start with the failed commercial job

Do not begin with a feature list. Begin with one event where the business failed to convert intent into owned work.

For example, a founder may hear: "We need an AI agent because qualified inquiries are not followed up." That sentence bundles several different failures. The team may not agree on what qualified means. The qualifying evidence may live in messages that never reach the CRM. A lead may change status without creating an accountable task. Sales may reject the lead without a reason code. Nobody may review the accumulated rejection evidence.

An agent cannot resolve those disagreements by inference. It will inherit them.

Name the job in operational language instead:

"When a qualified commercial event is recorded, assign the next action to an accountable person, with the evidence needed to act, an expiry condition, and a return path for rejection."

Now the team can inspect the current path. Follow several real records from source to outcome. Compare what people say happens with timestamps, fields, messages, tasks, and decisions in the systems of record. The point is not to produce a perfect diagram. The point is to expose where information stops, where work waits, and which decision happens by default.

Test the six contracts before the capability

1. Decision contract

Write the decision the system must support. Who should act next? Should this opportunity route, wait, nurture, or close? A vague goal such as "improve follow up" cannot determine a useful configuration.

2. Evidence contract

List the minimum facts required for that decision, their source, freshness, and unknown state. If marketing and sales use different definitions of qualified, the restriction is in Truth before it is in automation. The Truth layer must make the claim inspectable.

3. State contract

Define the state before the event, the event that permits transition, and the resulting state. "Send a notification" is not a state change. "Accepted by sales with a due next action" is.

4. Authority contract

Name who may make the decision and who owns the result after it. Software permissions do not create decision rights. If two teams can silently override each other, a new interface will only hide the dispute.

5. Exception contract

Specify what happens when evidence is missing, ownership is unavailable, an integration fails, or the lead is rejected. A happy path without an exception queue is a demo, not Architecture.

6. Learning contract

Define which outcome returns to the Playbook. Rejection reasons, overrides, delays, and reopened opportunities should change a rule, a definition, or a workflow. Without review cadence, the system records failure but does not learn from it.

These contracts do not need a large transformation program. One page and a handful of real records are enough to reveal whether the purchase request has a stable job behind it.

Classify the gap instead of blaming the stack

Once the six contracts are visible, classify the first broken layer.

A Truth gap exists when the evidence is missing, disputed, stale, or impossible to inspect. Repair definitions and capture before buying intelligence.

A Playbook gap exists when the team cannot state the rule or when every operator uses private judgment for a supposedly repeatable case. Make judgment visible before automating it.

An Architecture gap exists when the rule is clear but systems cannot carry state, ownership, or exceptions across boundaries. This may justify integration, workflow redesign, or a new platform.

An Operator gap exists when the designed system has no owner, review cadence, or maintenance path. Buying another tool does not supply operating discipline.

A tool gap remains only after those layers are sufficiently defined and the current stack still lacks a necessary capability. At that point, selection becomes easier because the request can name required inputs, outputs, permissions, failure behavior, and verification.

This classification is not anti software. It protects good software from being commissioned against an undefined job.

Decision rule

Use this rule for every commercial tool request:

1. Choose one failed commercial job, not an entire department.

2. Trace real records through the current work and information flow.

3. Write the six contracts without referring to a vendor feature.

4. Identify the first contract that cannot be executed.

5. If the contract itself is unclear, repair the GTM layer and defer selection.

6. If the contract is clear and the current stack cannot execute it, write a bounded capability brief and evaluate tools against that brief.

7. Reject any option that cannot expose its state, owner, exception path, and output for verification.

A practical capability brief should fit on one page. It should say what triggers the job, which evidence enters, which decision occurs, who has authority, what state changes, how exceptions surface, and how outcomes return to the Playbook. Features belong after that contract, not before it.

What this changes for the founder

The founder no longer has to choose between "buy the tool" and "do nothing." The real options are clearer: repair Truth, codify the Playbook, connect the Architecture, install an Operator cadence, or procure a bounded capability.

That sequence also changes vendor conversations. A polished demonstration becomes less persuasive than proof that the product can carry the business's actual state transition, preserve authority, surface failure, and produce inspectable evidence.

If your team cannot agree on which contract is broken, a GTM diagnosis can map the restriction before another platform becomes part of the problem.

FAQ

Does this mean the current tool must always be kept?

No. The diagnosis can support replacement, consolidation, integration, or removal. It simply requires the team to prove the commercial job before selecting the mechanism.

Can a founder run the diagnosis without process mining software?

Yes. Start with a small set of real records, system timestamps, messages, tasks, and operator interviews. Process mining can strengthen the evidence when event data and complexity justify it, but it is not a prerequisite for seeing the first broken contract.

What if several contracts fail at once?

Fix the earliest failure that makes later work unreliable. If qualification evidence is disputed, redesigning routing first will encode the dispute. If evidence is sound but accepted work has no owner, repair authority and state before adding intelligence.

Diagnostique o sistema de GTM antes de comprar outra ferramenta

Um pedido por CRM novo, automação, dashboard ou agente de IA costuma chegar como se o diagnóstico já estivesse pronto. Os leads estão escapando, o acompanhamento varia, o relatório demora, então só pode estar faltando software.

Essa conclusão pula o sistema comercial. A dor visível pode vir de uma capacidade técnica ausente. Também pode nascer de uma decisão mal definida, evidência contestada, mudança de estado sem dono ou exceção que ninguém encerra. Uma ferramenta nova consegue apenas acelerar cada um desses defeitos.

O papel do diagnóstico de GTM não é defender a pilha atual. É localizar a restrição antes que o negócio a transforme em configuração. O fundador deveria aprovar uma ferramenta quando o trabalho comercial que falhou estiver explícito e a equipe conseguir demonstrar por que o sistema atual não dá conta dele.

Definição: lacuna de ferramenta é uma falha delimitada de execução

Definição: Existe uma lacuna de ferramenta em GTM quando a decisão comercial necessária e seus contratos operacionais já estão definidos, mas a pilha atual não consegue executar esse trabalho de forma confiável dentro das restrições do negócio.

A frase "precisamos de uma ferramenta melhor" ainda não descreve uma lacuna. Ela apresenta uma hipótese.

O diagnóstico testa essa hipótese por meio de seis contratos: decisão, evidência, estado, autoridade, exceção e aprendizado. Juntos, eles mostram se a restrição está em Verdade, Playbook, Arquitetura, Operador ou na capacidade real do software.

É isso que uma firma de engenharia de GTM precisa esclarecer antes de recomendar uma plataforma. Capacidade comercial nasce de um sistema executável, não da quantidade de produtos conectados.

Comece pelo trabalho comercial que falhou

Não abra uma lista de funcionalidades. Escolha um evento no qual o negócio deixou de transformar intenção em trabalho com dono.

Um fundador pode ouvir, por exemplo: "Precisamos de um agente de IA porque ninguém acompanha os contatos qualificados." A frase mistura falhas diferentes. Talvez marketing e vendas discordem sobre o significado de qualificado. A evidência pode estar em conversas que nunca chegam ao CRM. O lead muda de etapa, mas nenhuma próxima ação é atribuída. Vendas rejeita o contato sem registrar motivo. Ninguém revisa o conjunto dessas rejeições.

Um agente não resolve essas divergências por inferência. Ele as herda.

Descreva o trabalho em linguagem operacional:

"Quando um evento comercial qualificado for registrado, atribua a próxima ação a uma pessoa responsável, entregue a evidência necessária, defina uma condição de vencimento e preserve um caminho de retorno para rejeição."

Agora é possível inspecionar o caminho atual. Acompanhe alguns registros reais desde a origem até o desfecho. Compare o processo contado pela equipe com horários, campos, mensagens, tarefas e decisões presentes nos sistemas oficiais. O objetivo não é criar um diagrama perfeito. É enxergar onde a informação para, onde o trabalho espera e qual decisão acontece por omissão.

Teste os seis contratos antes da capacidade

1. Contrato de decisão

Escreva a decisão que o sistema precisa sustentar. Quem age agora? A oportunidade deve ser encaminhada, aguardar, entrar em nutrição ou ser encerrada? Um objetivo vago como "melhorar o acompanhamento" não orienta uma configuração útil.

2. Contrato de evidência

Liste os fatos mínimos para decidir, a origem deles, sua validade e o estado desconhecido. Se marketing e vendas usam definições diferentes de qualificação, a restrição está em Verdade antes de chegar à automação. A camada de Verdade precisa tornar a afirmação verificável.

3. Contrato de estado

Defina o estado anterior, o evento que autoriza a transição e o novo estado. "Enviar uma notificação" não é mudança de estado. "Aceito por vendas com próxima ação e prazo" é.

4. Contrato de autoridade

Determine quem pode decidir e quem responde pelo resultado depois da decisão. Permissões de software não criam direitos decisórios. Quando duas equipes conseguem sobrescrever uma à outra em silêncio, a interface nova só esconde a disputa.

5. Contrato de exceção

Descreva o que ocorre quando falta evidência, a pessoa responsável não está disponível, uma integração falha ou o lead é rejeitado. Um caminho feliz sem fila de exceções é demonstração, não Arquitetura.

6. Contrato de aprendizado

Defina qual resultado volta para o Playbook. Motivos de rejeição, alterações manuais, atrasos e oportunidades reabertas devem modificar uma regra, uma definição ou um fluxo. Sem cadência de revisão, o sistema registra o fracasso, mas não aprende com ele.

Esses contratos não exigem um grande programa de transformação. Uma página e alguns registros reais bastam para revelar se existe um trabalho estável por trás do pedido de compra.

Classifique a lacuna sem culpar a pilha

Com os seis contratos visíveis, identifique a primeira camada quebrada.

Há uma lacuna de Verdade quando a evidência falta, é contestada, está vencida ou não pode ser inspecionada. Corrija definições e captura antes de comprar inteligência.

Há uma lacuna de Playbook quando a equipe não consegue declarar a regra ou cada pessoa usa um julgamento privado para um caso que deveria ser repetível. Torne o julgamento visível antes de automatizá-lo.

Há uma lacuna de Arquitetura quando a regra está clara, mas os sistemas não conseguem transportar estado, dono ou exceções entre fronteiras. Isso pode justificar integração, redesenho do fluxo ou uma plataforma nova.

Há uma lacuna de Operador quando o sistema desenhado não tem dono, cadência de revisão nem caminho de manutenção. Comprar outra ferramenta não instala disciplina operacional.

A lacuna de ferramenta permanece apenas depois que essas camadas estão suficientemente definidas e a pilha atual ainda não possui uma capacidade necessária. Nesse momento, a escolha fica mais simples, pois o pedido consegue nomear entradas, saídas, permissões, comportamento em falhas e forma de verificação.

Essa classificação não é contra software. Ela evita que um bom software seja contratado para um trabalho indefinido.

Regra de decisão

Use esta regra para cada solicitação de ferramenta comercial:

1. Escolha um trabalho comercial que falhou, não um departamento inteiro.

2. Siga registros reais pelo fluxo atual de trabalho e informação.

3. Escreva os seis contratos sem citar funcionalidades de fornecedor.

4. Localize o primeiro contrato que não pode ser executado.

5. Se o próprio contrato estiver nebuloso, repare a camada de GTM e adie a seleção.

6. Se o contrato estiver claro e a pilha atual não puder executá-lo, escreva um briefing delimitado de capacidade e compare as ferramentas com ele.

7. Descarte qualquer opção que não exponha estado, dono, caminho de exceção e saída verificável.

Um bom briefing de capacidade cabe em uma página. Ele informa o gatilho do trabalho, as evidências de entrada, a decisão tomada, a autoridade, a mudança de estado, a exposição das exceções e o retorno dos resultados ao Playbook. A lista de funcionalidades vem depois desse contrato.

O que muda para o fundador

O fundador deixa de escolher entre "comprar a ferramenta" e "não fazer nada". As alternativas ficam mais precisas: reparar Verdade, codificar o Playbook, conectar a Arquitetura, instalar uma cadência de Operador ou contratar uma capacidade delimitada.

A sequência também melhora a conversa com fornecedores. Uma demonstração bonita perde força diante da prova de que o produto carrega a mudança de estado real do negócio, preserva autoridade, expõe falhas e produz evidência verificável.

Se sua equipe não consegue concordar sobre qual contrato está quebrado, um diagnóstico de GTM pode mapear a restrição antes que outra plataforma passe a fazer parte do problema.

Perguntas frequentes

Isso significa que a ferramenta atual sempre deve ser mantida?

Não. O diagnóstico pode sustentar substituição, consolidação, integração ou remoção. Ele apenas exige que a equipe prove o trabalho comercial antes de escolher o mecanismo.

O fundador consegue fazer o diagnóstico sem software de mineração de processos?

Sim. Comece com um conjunto pequeno de registros reais, horários dos sistemas, mensagens, tarefas e entrevistas com quem opera o fluxo. A mineração de processos pode fortalecer a evidência quando houver dados de eventos e complexidade suficientes, mas não é requisito para encontrar o primeiro contrato quebrado.

E se vários contratos falharem ao mesmo tempo?

Corrija a primeira falha que torna o restante pouco confiável. Se a evidência de qualificação é contestada, redesenhar o roteamento primeiro apenas codifica a disputa. Se a evidência está íntegra, mas o trabalho aceito não tem dono, repare autoridade e estado antes de adicionar inteligência.