What Happens in the Diagnose Phase of a GTM Infrastructure Engagement?
The pipeline looks fine. The dashboard is green, meetings are getting booked, spend creeps up a little every month, and the number still misses. Someone asks why, and the room goes quiet, because no one can point to the exact place the revenue is leaking. That gap, between a system that looks healthy and a number that keeps missing, is the reason the Diagnose phase exists.
A GTM Diagnose is an end-to-end audit of your existing GTM infrastructure that produces a prioritized action plan. It maps how a signal becomes revenue across your whole system, from the first touch to renewal, and marks every place a stage leaks.
This post walks that phase. What a Diagnose assesses, how it differs from the audit you may already have run, and what you walk away holding. By the end you should recognize the seams where revenue commonly leaks, and understand that a Diagnose is a low-risk way to find yours. If you read the five-phase overview, Diagnose is the phase that comes first, and the one you can run entirely on its own.
What is the Diagnose phase of a GTM infrastructure engagement?
A GTM Diagnose is an end-to-end audit of your existing GTM infrastructure that produces a prioritized action plan. It is the first phase of a typical engagement, before Architect turns the findings into a blueprint and long before Build makes anything real. Its job is narrow and specific: work out where your go-to-market is actually breaking down, and rank what to fix.
The Diagnose does not start with a proposal about what to build. It starts with your system as it stands today, the tools already in place, the records already flowing, the handoffs already happening, and reads them for where revenue escapes. The output is not a strategy deck. It is a short, ranked list of the fixes that will move the number most, in the order they are worth doing.
Diagnose comes in two forms. It is the standalone entry point, an audit you can buy on its own, and it is also Phase 1 of a full Diagnose through Transfer build. Either way you keep the findings, and either way you keep the keys.
What does a GTM Diagnose assess?
A Diagnose assesses your GTM through three lenses, applied across the entire funnel rather than only the path to a booked meeting. The three lenses are data flow, tool stack, and signal gaps.
Data flow is where records break or duplicate as they move between systems, so the same account exists three times and none of the three is right. Tool stack is what each tool actually owns, and where two of them overlap or a seam between them owns nothing. Signal gaps are the signals you should be acting on but never capture, so a ready-to-buy account looks identical to a cold one.
The part a lighter audit rarely reaches is the far end. A Diagnose reads the post-pipeline stretch with the same care as the top of the funnel: deal progression, closed-won handoff, expansion, renewal, and whether any of it is measured. The finding I run into most often is qualification built on firmographics alone, with no behavioral signal, so sales chases accounts that fit on paper and never convert. Another common one is revenue that is never traced back to its source, so no one can say which motion actually worked. These are not opinions. They are specific, locatable seams in a specific system.
The leak map
Put those three lenses across the whole system and you get a map of where revenue leaks. The diagram below is that map. The pipeline runs along the bottom as the quiet background, from a collapsed top of funnel through the five post-pipeline stages to the prioritized action plan the phase produces. The leaks, marked in the foreground, are the finding.
Read the map from the bottom up. The revenue system runs quietly along the spine, from a collapsed top of funnel through the five post-pipeline stages to the prioritized action plan the phase produces. Most of the value sits in that post-pipeline stretch, which is exactly the part a lighter audit tends to leave alone. The orange callouts are the leaks: a signal gap at the front, a handoff drop where a closed deal loses its owner, a stretch with no revenue trace at the back. A Diagnose is the work of finding those, naming them, and putting them in order.
What is a GTM audit / RevOps audit, and how is a Diagnose different?
A GTM audit, sometimes called a RevOps audit, is a structured review of your revenue operations: your funnel, your tooling, your data, and where they are underperforming. A Diagnose is that audit, run end to end and pointed at one output, a ranked plan of what to fix.
The difference is how far past the form it goes. A typical audit is scoped to capture and conversion, the path to a booked meeting, and that is genuinely useful work. A Diagnose can carry the same rigor through deal progression, expansion, renewal, and attribution, the stages where revenue is actually won, kept, and grown. Going past the form is sometimes in scope and rarely the default, so if the post-pipeline stretch is where you suspect the leak, it is worth asking for explicitly.
That difference in scope is the same line that separates a GTM engineer from an architect. I wrote about where one role ends and the other begins rather than relitigate it here, but for a Diagnose the practical version is simple: decide up front whether you want the top of the funnel checked or the whole revenue system read.
What do you get at the end of a Diagnose?
You get a prioritized action plan. Not a sixty-page report that documents everything and decides nothing, and not a list of generic best practices. A ranked set of specific fixes, each tied to the stage it repairs and the revenue it is likely to move, in the order they are worth doing.
Every GTM has more problems than a single quarter can absorb. A plan that lists twenty of them equally is just a longer way of saying you are on your own.
So the prioritization is the deliverable. A good Diagnose is opinionated. It says here is the one that is costing you the most, here is the cheap fix that unblocks three others, and here is what to leave alone for now. Decision-ready, so the next conversation is about doing the work, not about what the work is.
Can I start with just a Diagnose?
Yes. The Diagnose is the entry point, and it stands on its own. You can buy the audit, get the prioritized action plan, and stop there, taking the plan to your own team to execute. If it turns into a full Architect through Transfer build, the Diagnose becomes Phase 1 and nothing is repeated. Either way the findings are yours to keep, which is the whole posture of the engagement.
How much does a Diagnose cost, and how do I start?
A Diagnose is priced per scope, set after a short intro call, because the right depth depends on how much of the system you want read. The standalone Diagnose is the low-commitment way to start working together: a bounded piece of work with a concrete deliverable, not a retainer or a long build you have to approve on faith.
The shape is consistent. A scoping call to agree what the audit covers and how deep it goes. A fixed-scope audit window where the system is mapped through the three lenses. Then the prioritized action plan, walked through with you rather than emailed over. If the plan is all you need, that is a complete engagement. If you want the fixes built, the plan is already the blueprint’s first draft.
Diagnose finds the problem. Architect decides the system, Build makes it real, Activate turns it into a revenue engine, and Transfer hands you the keys. It is also the one phase you can run entirely on its own, which is why it is the right place to start if you are not yet sure the whole system needs rebuilding.