The Mutual Action Plan: Disqualify Earlier and Defend Your Win Rate
You ran a brilliant demo. The champion was nodding. The POC went smoothly - they even said so, unprompted, on the wrap-up call. Then nothing. The AE tells you they’re “still evaluating.” You check in a week later. “Still positive, just busy.” Three weeks after that, the deal slips to next quarter. Six weeks after that, it’s dead. Nobody can tell you why.
You already know this story. You’ve lived it four times this year, minimum.
The deal felt like it was next because nobody was forced to prove it was. Both sides filled the silence with optimism - you because you’d invested serious time, them because saying “we’re not actually going to buy this” is awkward and they’d quite like to keep their options open. The deal was alive in the same way Schrödinger’s cat is alive: only as long as nobody opens the box.
A mutual action plan is the thing that opens the box. It replaces shared optimism with shared accountability. And when it’s built properly - by someone who understands what actually needs to happen for a deal to close, not just what the CRM stages say - it exposes weak deals before you’ve burned another 40 hours on a POC that was never going anywhere.
That someone, more often than not, is you.
What a MAP actually is (and what it isn’t when it’s done badly)
A mutual action plan is a shared, time-bound document that maps every step both sides - vendor and prospect - need to take to reach a decision by a specific date. Not a contract. Not a project plan. Not a close plan with the prospect’s logo pasted on top.
The word doing the heavy lifting is mutual. If the prospect hasn’t co-created it, you don’t have a MAP. You have a wishlist.
Most teams get this wrong by introducing the MAP as a closing tool - a tidy checklist that appears in the final stages when the AE wants to “align on next steps.” By that point, you’ve already done all the work. The custom demo is built. The POC environment is provisioned. The architecture review is complete. The MAP arrives like a fire alarm after the building has burned down.
Used at the start of a deal, a MAP is a qualification instrument. Used at the end, it’s admin.
And here’s the part that should irritate you: when MAPs are built, they’re almost always built without you. The AE constructs it around commercial milestones - proposal sent, legal review, signature date - because those are the things that matter to the forecast. What gets left out are the technical milestones that actually determine whether the deal moves: security review timelines, data access approvals, integration validation, the specific person on the prospect’s infrastructure team who needs to bless the architecture before anyone signs anything.
The result is a MAP that looks complete but is technically naive. It doesn’t account for the two-week lag on the prospect’s IT security review. It doesn’t mention that the POC requires a data extract that needs legal sign-off from a department nobody’s spoken to yet. It doesn’t name the technical stakeholder who will quietly kill the deal if they’re not brought in early.
A technically-informed MAP - one with your fingerprints on it - is credible to the prospect’s technical team in a way that a commercial-only version never will be. It’s the difference between a document that makes the prospect’s CTO think “these people understand our process” and one that makes them think “this is a sales tactic.”
When to introduce it (and why that timing matters more than you think)
The right moment is after initial discovery, when both sides have agreed there’s a problem worth solving, and before you’ve committed any significant technical effort. Before the POC scope is agreed. Before the custom demo is built. Before you’ve spent a week writing an RFP response that reads like a short novel.
This is the window where a MAP functions as a filter. Prospects who are genuinely buying will engage with it - they’ll name stakeholders, confirm timelines, assign owners on their side. Prospects who are using your sales cycle for competitive benchmarking, internal justification, or free consulting will stall, deflect, or go quiet.
Both responses are useful. One tells you to invest. The other tells you to stop.
The typical late-stage introduction fails precisely because the prospect has already extracted most of what they wanted. They’ve got their technical validation. They’ve got their competitive intelligence. They’ve got the internal justification document they needed to show their board they did due diligence. At that point, committing to a timeline gives them nothing they don’t already have.
If you’re an SE watching an AE push to “just get into the POC” before any mutual plan exists, you have a specific, non-confrontational way to slow things down: “Before we scope the POC, we’ve found it works better when we align on what success looks like and who needs to be involved on your side. Can we spend 30 minutes building that out together?”
This isn’t bureaucracy. It’s genuinely useful for the prospect - it makes their evaluation more structured and less likely to stall internally. It also happens to be the single best qualifying question you can ask, because a prospect who won’t spend 30 minutes co-planning an evaluation they claim to care about is telling you something important.
Listen to what they’re telling you.
Disqualification is not failure - it’s capacity management
SEs feel pressure to keep deals alive. It comes from AEs who need pipeline. It comes from management who want coverage ratios. It comes from your own entirely human desire to see your technical work amount to something. Nobody wants to be the person who says “I don’t think this deal is real.”
But a disqualified deal isn’t a lost deal. It’s a deal that was never real, and you found out before spending three weeks proving it.
The MAP makes this visible through specific, observable signals. A prospect who can’t name an executive sponsor. A “decision committee” that keeps expanding every time you ask about it. An unwillingness to commit to a decision date - not even a rough one. An inability to articulate what success looks like beyond “we’ll know it when we see it.” Each of these is a qualification failure that would otherwise stay hidden until stage 4, when it surfaces as a deal that “just went quiet.”
Consider two versions of the same quarter.
In the first, you work twelve deals. You build custom demos for all of them. You run POCs for eight. You write technical proposals for six. Three close. Your win rate is 25%, and you’re exhausted.
In the second, you introduce MAPs early. Four prospects can’t engage with the plan - no named decision-maker, no timeline, vague success criteria. You disqualify them in week two, before any significant technical investment. You go deep on the remaining eight. Five close. Your win rate is 62%, and you had time to do proper architecture work on each one.
Same effort. Radically different outcome. The difference isn’t working harder. It’s choosing what not to work on.
Win rate is partly a function of deal selection, and deal selection is something you can influence - if you have a mechanism for it. The MAP is that mechanism.
What your MAP template is missing
Pull up whatever MAP template your organisation uses. If it was built by sales operations - and it almost certainly was - it probably includes: discovery call, demo, proposal, legal review, signature. Tidy. Commercial. Complete-looking.
Now look at what’s not there.
Who on the prospect’s side owns the technical evaluation? Not the business sponsor - the person who will actually assess whether your product works in their environment. What are their security and compliance requirements, and when does that review need to start? (Because if the answer is “six weeks” and your MAP has four weeks to close, you’ve already failed.) What data or environment access is needed for the POC, and who approves it? What are the technical success criteria - not business outcomes, but the specific things the prospect’s technical team needs to see before they’ll recommend next? Who is the technical champion, and is that the same person as the economic buyer? (It almost never is.)
These aren’t edge cases. They’re the things that cause deals to stall after commercial agreement. The contract is ready, legal is fine, the business sponsor wants to sign - but the infrastructure team hasn’t completed their review, or the security assessment surfaced a question nobody anticipated, or the integration dependency requires a change window that’s three months out.
When you co-create a MAP with a prospect, these are the questions to bring:
“Who on your infrastructure team needs to be involved in the integration review, and when do they need to start?”
“What’s your typical timeline for a security and compliance assessment? Should we factor that in now?”
“For the POC to be meaningful, we’ll need access to [specific data/environment]. Who approves that, and how long does it usually take?”
“Beyond the business case, who on your technical team needs to be satisfied before a recommendation goes forward?”
“What does a successful technical evaluation look like to your team - not to us, to you?”
Each question does two things simultaneously. It makes the MAP more accurate - which makes the deal more likely to close on time. And it surfaces the gaps that would otherwise ambush you in month three.
The MAP is a presales tool
There’s a quiet assumption in most sales organisations that the MAP belongs to the AE. It’s a sales tool. Presales supports it, the way presales supports everything - by showing up when asked and making the technical bits work.
That assumption is backwards.
The AE owns the commercial relationship. But the MAP - the actual, working, credible version of it - depends on technical knowledge that the AE doesn’t have. You know what needs to happen for a POC to succeed. You know which stakeholders on the prospect’s side will block a deal if they’re not engaged early. You know that “we’ll handle security review in parallel” is a fantasy in most enterprises.
A MAP built without that knowledge is a fiction. A polite, well-formatted fiction, but a fiction nonetheless.
The next time you’re handed a MAP late in a deal - or not handed one at all - consider that the problem isn’t the tool. It’s who’s been driving it. And the answer to that is probably sitting in the room, quietly building a POC environment for a deal that was never going to close.