The deck arrives in week eight. Sixty slides, forty recommendations, a roadmap colored by quarter. The diagnosis is sharp: stage definitions that mean different things to different reps, a lead routing rule nobody can explain, a forecast built on close dates that move every Friday. The leadership team nods through the readout, and the engagement closes.
Six months later the deck lives in a shared drive folder. Three of the forty recommendations were done, the three that needed no one's time. The stage definitions were rewritten in a document and never enforced in the CRM. The routing rule is still unexplained. The forecast still moves every Friday. Nobody did anything wrong. The deck was right, and it was never going to ship.
This is not a RevOps problem alone; it is what happens to most plans that leave the room on paper. Gartner's 2025 CIO and Technology Executive Survey, presented in October 2024 and based on 3,186 CIOs and technology executives plus 1,126 non-IT executives, found that only 48% of digital initiatives meet or exceed their business outcome targets. BCG's 2020 study of digital transformations, combining 70 company cases with a survey of 825 senior executives, found that only 30% met or exceeded their target value and resulted in sustainable change.
The gap sits between deciding and doing. In a 2013 study by the Economist Intelligence Unit and the Project Management Institute, 61% of 587 senior executives said their firms often struggle to bridge the gap between strategy formulation and day-to-day implementation, and on average only 56% of their strategic initiatives had been implemented successfully over the previous three years. A decade of better tools has not closed that gap, because the gap was never about tools.
For a revenue team between $3M and $30M ARR, an unimplemented recommendation is not neutral. It uses a quarter of leadership attention and teaches the team that RevOps change is a document exercise.
Diagnosis: four structural reasons recommendations don't ship
The usual explanations are personal: the consultants were too theoretical, the team was too busy. But the pattern repeats with good consultants and committed teams. Four structural reasons explain it better.
The deliverable is the deck, so nobody owns implementation
If the handover is a document, the engagement is complete when the document is accepted, whether or not anything changes in the CRM. Implementation becomes the client's job, and in this ARR band the client is usually a RevOps team of one or two people already at capacity. In the same Gartner survey, a group of high-performing leaders where business executives are equally responsible and accountable for delivery reached a 71% success rate on digital initiatives, against 48% overall (Gartner, 2024). Success follows whoever owns the outcome, not whoever wrote the plan.
Recommendations are never tested against your own history
"Introduce stage exit criteria" sounds right in every company. Whether it is right in yours depends on things nobody checked: how many of last year's won deals would have failed the new criteria, which reps already work this way, which fields the rule would depend on and how often they are empty. A recommendation that has not been run against your past deals is a hypothesis. When the team tries to implement it and the first twenty deals break the rule for reasons the deck did not anticipate, the recommendation quietly dies.
The consultants leave before adoption
Most of the value in any change program is won or lost after the plan is approved. McKinsey's 2021 survey of 1,034 people who had taken part in transformations found that successful transformations capture about 67% of their potential financial benefits, while all others capture about 37%. Of the value that was lost, about 55% was lost during and after implementation, and about 20% was lost after initiatives had been fully executed (McKinsey, 2021). A recommendations engagement ends exactly where most of the loss begins: at the point where someone has to make the change hold on a Tuesday afternoon in week eleven.
Recommendations are written as behavior, not as systems
"Reps should update next steps and close dates every week" is a request to twelve people. A rule that flags a stale deal and routes it to the right person is a change to one system. Behavior requests compete with selling time, and selling time is already scarce: Salesforce's 2024 State of Sales report, a survey of 5,500 sales professionals, found that reps spend 70% of their time on non-selling tasks (Salesforce, 2024). Every recommendation that adds a manual step loses that competition by default. The ones that survive are the ones somebody turned into software.
The framework: the Ships-or-Slides test
The alternative to a recommendations deck is not "no diagnosis." Diagnosis is necessary; the diagnose-before-you-build playbook makes that case in detail. The alternative is a diagnosis that ends in one scoped system, built and tested on your data, rather than a list of forty things to do. The Ships-or-Slides test is five questions you can ask of any RevOps engagement, including one you are about to buy. A deck answers them in the future tense; a system answers them in the present.
| Question | What a recommendations deck answers | What a working system answers |
|---|---|---|
| What is running on Monday? | A roadmap for what should run eventually | A specific rule, workflow or agent live in your stack |
| Who owns the build? | "Your team," after handover | The people who wrote the specification, until it passes its test |
| Was it tested on our history? | Based on best practice and interviews | Run against your own past cases, with results written down case by case |
| What is the pass bar? | Agreement in the readout meeting | A stated accuracy threshold it must clear before going live |
| How will we know it worked? | A list of suggested metrics | A before-and-after figure on the specific leak it was built to close |
Advice is useful when you have the capacity to build it yourself. Most revenue teams in the $3M to $30M band do not, which is why their decks pile up. Nor is the answer to hire an implementation partner after the strategy firm: splitting diagnosis from build recreates the handover one step later. The same people should diagnose, specify, build and prove, which is the core idea of forward-deployed engineering applied to a revenue team.
A worked example
Illustrative example, with made-up round numbers: a $15M ARR company has a deck from a previous engagement. Recommendation fourteen reads "enforce stage exit criteria and weekly close-date hygiene to improve forecast accuracy." It has been on the roadmap for three quarters. The Ships-or-Slides version starts by pulling 20 closed deals from the last two quarters and asking a narrow question: would a hygiene rule have flagged the deals that slipped, without flagging the ones that closed on time? The first draft flags too many healthy deals because a required field is empty on most records, so the rule switches to activity data. The second draft identifies the right deals in 18 of 20 cases, which clears an 85 percent agreement bar; after confirming no uncaught unsafe action, it goes live as a Pipeline Hygiene Sentinel that posts stale deals to each owner and their manager every Monday. Recommendation fourteen is now a system with an owner and a test record. Your numbers will differ; the sequence will not.
Implementation: turning a stalled deck into running software
If you already have a deck, keep it. These six steps turn it into a build queue.
Sort the recommendations into three piles
Label every recommendation as a decision (leadership must choose something), a behavior (people must act differently), or a system (a rule, workflow or model could do it on data). Many behaviors turn out to be systems written as requests. Check: every recommendation has exactly one label.
Make the decisions first
Systems cannot be built on undecided definitions. If the deck says "align on a qualified lead definition," that is a decision, and it blocks everything downstream. Gartner found that 49% of chief sales officers report their qualified lead definition differs significantly from marketing's (Gartner, 2025). Check: each decision has a date and a named decider, and the outcome is written where the build team can read it.
Price what each system recommendation is worth
For each item in the system pile, estimate what the gap it addresses costs each year, in dollars, with a stated confidence level. Deals that slip, leads that go cold and renewals that lapse all have a price. Check: the system pile is ranked by estimated annual cost, not by how loudly it was argued in the readout.
Write down what correct looks like, then pull the history
Take the top item and define it as a test: given these inputs, the system should make this call. Then pull around 20 real past cases where you already know the right answer. Check: a written definition of correct and a set of past cases exist before anyone builds anything.
Build it inside your stack and test it before it goes live
Build in the tools you already run, then run the system against the historical cases. We hold every system to the same bar: tested on around 20 of the client's own past cases, with at least 85 percent agreement and no uncaught unsafe action, or it does not ship. Check: results are recorded case by case, and the system cleared the bar before touching live data.
Hand it over running, with an owner, then re-measure
Name an operating owner on your side who signs off the test and watches the output. After a full cycle, re-price the leak. Then take the next item from the ranked pile. Check: one system is live with a named owner and a before-and-after figure, and the next one was chosen from fresh numbers.
Workflow: what a system build looks like next to a recommendations deck
The difference between the two models shows up in what each stage produces. A suggested workflow for a build engagement:
What happens: a read-only review of the CRM, marketing automation, product and support data finds where revenue is leaking and prices each leak in dollars. Nothing in your systems is changed.
Deck equivalent: the discovery phase, which usually ends in a presentation.
Owner: the CRO or founder sponsors it; RevOps provides access and context.
What happens: the largest leak whose inputs are ready becomes one system, with a written definition of correct and a set of past cases to test it on.
Deck equivalent: the roadmap, which lists many initiatives and specifies none.
Owner: revenue leadership agrees the choice; the operating owner agrees the definition of correct.
What happens: the system is built inside the existing stack and run against the historical cases until it clears the bar, or it is not shipped.
Deck equivalent: none. This is the stage most recommendations programs never reach.
Owner: the engineers who diagnosed and specified it, so nothing is lost in translation.
What happens: the system runs in production, its result is reported against the leak it was built to close, and the next system is chosen from the updated numbers.
Deck equivalent: a follow-up engagement asking why nothing was implemented.
Owner: the operating owner reports results; RevOps keeps the ranked list current.
The board narrative
Boards that have funded a RevOps engagement before will ask what is different this time. Three statements answer it.
We paid for diagnosis and advice. The diagnosis was sound, but the deliverable was a document, and our team did not have the capacity to turn forty recommendations into working systems while running the business. Most of them were never implemented.
We are paying for one working system at a time, chosen because it closes our most expensive leak. Each one is built inside our existing tools and tested on our own past deals before it goes live, against a pass bar agreed in advance.
Each system has a named owner on our team and a before-and-after figure on the leak it was built to close. We will report that figure each quarter. If a system does not clear its test, it does not ship, and we will tell you that too.
Cross-domain: where software beats slides first
The Ships-or-Slides test applies across the revenue engine, but Sales Operations is where the gap between recommendation and reality is usually widest, because sales recommendations are the ones most often written as behavior requests. Hygiene and forecasting advice asks reps to change habits; the Pipeline Hygiene Sentinel and the Forecast Assistant do the same work without asking. A forecast built on clean pipeline is the most visible proof to a board that something changed.
The same logic runs across the other domains. "Respond to inbound leads faster" becomes Speed-to-Lead. "Fix the SDR-to-AE handoff" becomes the Handoff Orchestrator. "Get ahead of churn" becomes the Churn Signal Watchtower. See all systems in one place.
The wider evidence points the same way. Gartner's 2026 sales research notes that the most effective sales organizations are not simply layering AI onto existing ways of working but redesigning seller workflows (Gartner, 2026). MIT NANDA found that AI solutions bought from or built with specialized partners had about twice the success rate of internal builds (MIT NANDA, 2025). Neither is an argument for more tools. Both argue for someone accountable for making the system work in your environment. If you want to see how a time-boxed, build-first model differs from open-ended advisory work, what Palantir's forward-deployed model gets right and wrong for revenue teams covers the trade-offs, and how we work shows the process step by step.
Sources: Gartner, 2025 CIO and Technology Executive Survey (press release October 22, 2024; 3,186 CIOs and technology executives, 1,126 non-IT executives). BCG, "If Failure Is Not an Option, Why Is Success So Rare?" (October 2020; 70 company cases, 825 senior executives). Economist Intelligence Unit and Project Management Institute, "Why Good Strategies Fail" (2013; 587 senior executives). McKinsey & Company, "Losing from day one: Why even successful transformations fall short" (December 2021; 1,034 respondents). Salesforce, State of Sales, 6th edition (July 2024; 5,500 sales professionals). Gartner, CSO survey (press release May 21, 2025; 243 CSOs and senior sales leaders). Gartner, sales AI research (press release May 20, 2026; 227 CSOs). MIT NANDA, "The GenAI Divide: State of AI in Business 2025," report copy hosted by Valtao, 2025. The opening scene is a generic composite, the Ships-or-Slides test is VANDFORT's framework, and the worked example uses illustrative figures, not client data.
