The quarterly business review has a slide called "AI initiatives." It lists an AI SDR the marketing team trialed in the spring, a forecasting add-on the CRO bought after a bad quarter, a customer health score the CS team built in a spreadsheet, and a chatbot on the pricing page. Each was justified on its own. Asked what the four have done for revenue, the room goes quiet.
Look closer and the problem is not any single tool. The AI SDR books meetings into a queue nobody works for two days. The forecasting add-on reads deal stages that reps update once a month. The health score cannot see product usage, so lost renewals still show green. Four reasonable purchases, wired to nothing, add up to an engine no faster or more accurate than it was a year ago.
MIT's NANDA initiative, in its 2025 report "The GenAI Divide," based on interviews with representatives from 52 organizations, surveys of 153 senior leaders and a review of over 300 publicly disclosed AI initiatives, found that about 95% of enterprise generative AI pilots deliver little to no measurable impact on profit and loss. More than half of generative AI budgets go to sales and marketing tools, yet the strongest returns came from back-office automation. The money flows toward revenue; the results do not.
McKinsey's State of AI 2025 survey of 1,993 respondents tells the same story from the other side. Eighty-eight percent of organizations report regular AI use in at least one business function, but only about a third have begun to scale it across the enterprise, only 23% are scaling AI agents anywhere, and just 39% report any impact on enterprise-level EBIT. Adoption is universal; systems that change the numbers are rare.
Inside the sales team, Salesforce's 2024 State of Sales report, a survey of 5,500 sales professionals in 27 countries, found reps spend 70% of their time on non-selling tasks, and only 35% completely trust their organization's data. Another standalone tool rarely fixes that. Deciding which systems the engine needs, how they depend on each other, and which to build first does.
Diagnosis: why revenue teams end up with tools instead of systems
Most companies between $3M and $30M ARR do not lack software. They lack a map. Four patterns explain why.
Tools are bought by symptom, not by system
A slow quarter produces a forecasting purchase. A churn scare produces a health score. A pipeline gap produces an outbound tool. Each purchase answers the loudest complaint of the moment, so the stack is shaped by when problems became visible rather than by what they cost. The most expensive leak is often the quietest, such as inbound leads waiting a day for a first touch, and it never gets a budget line.
Systems are built before the systems they depend on
A forecast is only as good as the pipeline underneath it. A renewal play is only as good as the churn signals that trigger it. A board report is only as good as every system that feeds it. A forecasting tool bought before deal hygiene is fixed produces a confident number from stale stages, and the board learns to distrust both. Gartner's State of Sales Operations research found that only 45% of sales leaders and sellers had high confidence in their organization's forecast accuracy, and only 47% believed their organization's data was high quality (Gartner, 2020). Those two numbers are related.
The domains do not share a definition of the customer
Marketing tracks leads, sales tracks opportunities, customer success tracks accounts, and finance tracks invoices. Each domain buys tools that fit its own object, so each tool sees a different slice of the same customer. Gartner estimates that poor data quality costs organizations at least $12.9 million a year on average (Gartner, 2020). In a revenue engine, much of it sits at the seams, where one team's output is another's input and nobody has defined what passes between them.
Nobody owns the seams
Revenue leaks most at the handoffs: lead to rep, SDR to AE, AE to onboarding, onboarding to renewal. Every function owns its side of each handoff and nobody owns the handoff itself. Tools bought by one function inherit that blind spot, so every function looks well equipped while the customer falls through the gaps.
The framework: the Nine Systems Framework
The Nine Systems Framework describes a fully built revenue engine as nine discrete systems in four domains. Each system has one job, answers one recurring question, and produces an output that at least one other system depends on. A system means working software running on your own data inside your own stack, not a licence or a process document.
| Domain | System | The question it answers | Depends on |
|---|---|---|---|
| GTM Operations | Speed-to-Lead | Did every qualified inbound lead get a response while it was still warm? | Clean lead capture and routing rules |
| Handoff Orchestrator | Did every lead and deal move between teams with its context and on time? | Speed-to-Lead; agreed stage definitions | |
| Signal-Based Outbound Engine | Which accounts are showing buying intent right now, and who should act? | A trusted account record and ideal customer profile | |
| Sales Operations | Pipeline Hygiene Sentinel | Which deals are stale, mis-staged or missing what they need to close? | Handoff Orchestrator; consistent deal stages |
| Forecast Assistant | What will we actually close this quarter, and why does it differ from the call? | Pipeline Hygiene Sentinel | |
| CS Operations | Churn Signal Watchtower | Which customers are showing early signs of leaving? | Usage, support and relationship data joined to the account |
| Renewal Radar | Which renewals and expansions need action, by whom and by when? | Churn Signal Watchtower | |
| Revenue Intelligence | Board Report Engine | What does the board need to see this quarter, built from live data? | Every system above |
| Revenue Answers | What is the answer to the question a leader just asked, without waiting for an analyst? | Every system above |
The dependencies form three chains and a roof. The acquisition chain runs from Speed-to-Lead through the Handoff Orchestrator into the pipeline, with the Signal-Based Outbound Engine feeding the same pipeline from the outbound side. The sales chain runs from the Pipeline Hygiene Sentinel to the Forecast Assistant, because a forecast built on unhygienic pipeline is a guess with a decimal point. The retention chain runs from the Churn Signal Watchtower to Renewal Radar, because a renewal play that starts without early warning starts too late. Revenue intelligence is the roof: the Board Report Engine and Revenue Answers read from every other system and are only as accurate as the weakest one beneath them.
Three rules follow from the map. First, build a system only when what it depends on is good enough, or build the dependency first. Second, build where the most money is leaking, not where the most noise is, which is why every engagement starts with a diagnosis rather than a catalog. Third, build one system at a time, test it on your own history, and re-measure before choosing the next.
The map does not prescribe a fixed order; a company losing most of its revenue to churn should not start with inbound response time. But it suggests a typical starting point. Upstream leaks compound: a lead lost in the first hour never becomes pipeline or renewal. So when the diagnosis shows leaks of similar size in several domains, the acquisition chain usually comes first, the sales chain second, the retention chain alongside or just after, and the intelligence roof last. This is a suggested starting point, not a benchmark, and the diagnosis overrides it whenever the numbers say otherwise.
A worked example
Illustrative example, with made-up round numbers: a $12M ARR company asks for a forecasting system because it missed its last two quarterly calls. The diagnosis finds that about a third of open opportunities have not changed stage in 60 days, and that inbound demo requests wait a median of 20 hours for a first response. A Forecast Assistant built on that pipeline would forecast stale deals precisely. The map points the other way: the Pipeline Hygiene Sentinel first, so the forecast reads real deals, and Speed-to-Lead alongside it, because slow response is draining the top of the same pipeline. The forecast comes third, on data it can trust. Your figures will differ; the logic will not.
Implementation: six steps from map to first system
The first four steps are read-only.
Place your current stack on the map
For each of the nine systems, write down what exists today: a working system, a tool that partly does the job, a manual process, or nothing. Be strict: a dashboard someone checks when they remember is a manual process. Check: every one of the nine rows has a status and a named owner, even if the owner is "nobody."
Price the leak behind each gap
For every row that is not a working system, estimate what the gap costs each year: leads that go cold, deals that slip, renewals that lapse, hours spent on manual reports. A rough range with a stated confidence level is enough. Check: each gap carries a dollar estimate and the evidence behind it.
Check the dependencies
For the most expensive gaps, look at the "depends on" column. If the dependency is weak, the honest first build is the dependency. Most teams skip this step. Check: the shortlist names, for each candidate system, whether its inputs are ready.
Choose one system
Pick the system that closes the largest leak whose dependencies are ready. Write down what it must do, which data it touches, and what correct looks like. The diagnose-before-you-build playbook walks through this read-only diagnosis in more detail. Check: one system is chosen, with a written definition of success.
Build and test it on your own history
Build it inside your existing stack and run it against past cases before it touches live data. We hold every system to the same bar: tested on around 20 of the client's own past cases, with 85 percent agreement and no uncaught unsafe action, or it does not ship. Check: the test results are written down, case by case, and the system cleared the bar before going live.
Re-measure, then return to the map
After a full cycle, re-price the leak the system was built to close. Then return to step two, because closing one leak changes the size or readiness of the next. Check: the before-and-after figure is reported, and the next system is chosen from fresh numbers rather than the original list.
Workflow: how a system moves from diagnosis to production
Every system follows the same path into the engine. A suggested workflow:
What happens: a read-only review of the CRM, marketing automation, product and support data places the company on the nine-system map and prices each gap in dollars.
System role: replace opinions with a ranked list of leaks and the systems that close them.
Owner: the CRO or founder sponsors it; RevOps provides access and context.
What happens: the ranked list is checked against the dependency map, and one system is chosen because it closes the largest leak whose inputs are ready.
System role: prevent building a system on data it cannot trust.
Owner: the revenue leadership team agrees the order; finance agrees the leak estimates.
What happens: the system is built inside the existing stack and tested against the company's own past cases before it goes live.
System role: show, on real history, that the system makes the right call often enough to trust in production.
Owner: the engineers building it, with a named operating owner on the client side who signs off the test.
What happens: the system runs in production, its results are reported each quarter against the leak it was built to close, and the map is updated.
System role: keep the map a living plan, not a one-time recommendation.
Owner: the operating owner reports results; RevOps keeps the map current.
The board narrative
Boards need three statements, not nine systems.
We stopped buying AI tools one problem at a time. We now plan our revenue engine as nine systems in four domains, know which of them we have and which we lack, and have put a dollar figure on each gap.
The systems depend on each other. Building in the right order means each new system works on data it can trust, so our spending goes into results rather than into another pilot that nobody uses after the trial.
Each system was tested on our own history before it went live, and each quarter we report the leak it was built to close, before and after. The map shows which system comes next and why.
Cross-domain: how the nine systems connect
The domains are a way to organize ownership, not walls. In GTM Operations, Speed-to-Lead, the Handoff Orchestrator and the Signal-Based Outbound Engine decide how much of the demand you pay for becomes pipeline. In Sales Operations, the Pipeline Hygiene Sentinel and the Forecast Assistant decide whether that pipeline is real and how much of it will close. In CS Operations, the Churn Signal Watchtower and Renewal Radar decide how much of the revenue you won you keep and grow. In Revenue Intelligence, the Board Report Engine and Revenue Answers turn everything above into decisions.
The seams matter most. The Handoff Orchestrator connects marketing to sales and sales to onboarding. The Churn Signal Watchtower should feed context back to the Signal-Based Outbound Engine, so the team stops prospecting look-alikes of customers who are leaving. A system that improves one domain usually improves another's inputs, which is why good sequencing compounds.
If you are deciding who should build these systems, the GTM engineer vs. RevOps manager vs. growth engineer decision tree covers the hiring side. If you are deciding how, this is the core of forward-deployed engineering for revenue teams: engineers working inside your stack, one system at a time, each proven on your own data. MIT's research points in the same direction: external partnerships had about twice the success rate of internal builds (MIT NANDA, 2025). See all nine systems in one place.
Sources: MIT NANDA, The GenAI Divide: State of AI in Business 2025 (2025; report copy hosted by Valtao). McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation (2025; 1,993 respondents). Salesforce, State of Sales, 6th edition (July 2024; 5,500 sales professionals in 27 countries). Gartner, State of Sales Operations Survey (February 2020), and data quality research (2020). The Nine Systems Framework, its dependency map, the suggested sequencing and the worked example are VANDFORT's framework, suggested starting points and illustrative figures, not benchmarks.
