A mutual action plan only works once it becomes the buyer's project plan. Here's how to build one backward from a date they already care about, and how to tell when they've made it theirs.
A mutual action plan is a shared, backdated list of milestones, each with a named owner and a date, that takes the buying team from today through their decision and on to the outcome they want. It works once it becomes the buyer's project plan, which you'll see when they edit it, add people, and move dates. If you're the only one updating it, it's still a close plan.
Placeholder answer
Short, practical frameworks for executive messaging, business cases, multithreading, and sales enablement.
When people find out I've raced a few Ironman triathlons, the reactions run from "gross, why would you do that?" to "woah, how'd you do that?" Twelve hours of exercise, squeezing food out of little tubes strapped to your body so you don't pass out, paying for the privilege, and at least six months of sticking to a training plan before you're ready for race day. Most people find the whole idea appalling.
But there's a small group of people who hear about it and light up. If I dropped a training plan in front of them, they'd see it as a gift, not a burden, because they've already decided this is what they want.
Your champions are that small group. Which is also why the shared spreadsheet you sent after your second call hasn't been opened since: you handed a training plan to someone who hadn't signed up for the race yet. Once they have, the plan stops being yours, and you'll know it's theirs when they start editing it.
A mutual action plan (MAP) is a backdated series of tasks, each with a specific owner and date, that leads the buying team from where they are today, through a buying decision, to their desired outcome. Backdated, because you build it backward from a date that already matters to the buyer, and the day you'd like a signature doesn't come into it. And it runs all the way to the outcome, because for your champion, the contract is the starting line.
A close plan is the list of things the buyer needs to do so you get paid, which is why it ends at the signature, and why you're usually the only one who ever updates it. A MAP is the plan for solving their problem, and the purchase happens to be a few rows in the middle of it.
Tom Williams, who led Clari Align (a product built around MAPs) when I was writing Selling With, told me how he'd frame it for buyers. When you introduce a MAP, say it explicitly: "This is not a plan to sell my software; it's a plan to solve your problem." Skip that step, and a MAP reads a lot like "here's what I need you to do to get me paid."
The quickest test is where your plan ends: at "contract signed," or at "first measurable outcome."
Usually because the plan showed up before the reason to act did.
I once asked a senior DevOps director, who manages about $2 million of spend on developer tools, how he uses the materials reps send him. He liked project plans, for a specific reason: "I'm going to match up the level of effort I'm seeing they need to how important I think this project is." But he wouldn't take one to leadership: "I can't just bring a bunch of tasks to my CTO and be like, 'Here, look at this.'"
What goes to his CTO first is what he called a decision memo, something that says "this is a big deal for us; we need to address it." The project plan only comes out after that, "to basically say, 'we're not gonna just wing it here.'"
Did you catch the order? Memo first, plan second, which gives you four things to build around:
Every date in the plan hangs off one date: the compelling event. It's a time-bound need that already exists inside the account, something you discover with your buyer (you can't manufacture it as a seller). A product launch that's already in a press release. The holiday shopping season and the traffic it brings. A use-it-or-lose-it budget (the seller's dream).
A compelling event has three parts: a specific deadline tied to a business event, a measurable cost of missing it, and a named person who'll be held accountable for it. Then run the litmus test: if you removed yourself from the conversation, would they still need to solve this by that date? If not, the urgency is yours, not theirs. And if you can't find one yet, here's how to find a real compelling event.
Most close plans start at the contract date and count forward, so flip it: start from when the customer needs the outcome, whether that's live before the holiday rush or ready for the board meeting, and work backward through every step it takes to get there.
The length of each task tells you how far ahead of the event it has to start. If there are 90 days of tasks left and the holiday season is 90 days away, well then, giddy up. The time to start is now.
Write down every step, from agreeing there's a problem through onboarding and adoption. Then get specific about the steps that tend to bite late:
Ask those while you're still qualifying, so the plan has actual durations in it by the time you build it. Better yet, ask a champion from a recently closed deal to walk you through the internal work you never saw, the emails, conversations, and docs, and compare it to how you thought they bought (lunch on you). The sales-to-CS handoff has the email I use.
Group the tasks into a handful of milestones (our product team calls them epics), and split them between your team and theirs. Every task gets one owner, a DRI ("directly responsible individual"), and a due date.
Now, keep it simple. Remember the DevOps director matching effort to importance: a long, complicated plan raises the perceived effort and drops the return, even when every task is easy. But don't skip steps to make it look easier, because that's how you end up sinking weeks into a deal that was never going to make the date.
Bring your baseline to your champion and ask them to change it:
Here's the process we typically see our customers using to go live and make sure everyone's on the same page. How does this compare to any past purchases you've made? It'd be great to cut what you don't think applies and add anything I've missed.
If they've run a purchase like this before, they'll have detailed edits. If they haven't, ask what surprises them, which tells you where you'll either need to explain why a step matters or change the plan.
In an Ironman, each leg (the swim, the bike, and the run) has a cutoff time. Fall too far behind and you're pulled from the course, because the organizers know it's highly unlikely you'll finish in a reasonable time after that. Your MAP needs the same thing, set together and early:
Since you're thinking we'll need [names of colleagues] involved in this process, I'm wondering, what amount of time is reasonable to spend getting them involved? I'd hate to just spin our wheels if this doesn't become a priority for everyone.
Then if three weeks go by with unanswered requests, you don't need a breakup email. You need an honest check-in against the cutoff you both agreed to: "We were hoping to get your team's input before the month was up. Does it still make sense for us to track down their feedback? Or is this not as big of a priority as we thought?"
It's better for both of you to pull out of the race early than to spend hours on the course without ever crossing the finish line.
Here's an illustration built on an example from Selling With: a retailer whose customers couldn't find answers in their help content, which buried the support team during the holiday rush. The fix was a search tool that understood what customers were actually asking. The "create budget" tasks are adapted from the book's MAP example, and the timing is illustrative, so it's written in weeks before go-live.
Goal: New site search live before holiday traffic arrives, so customers find answers on their own and support isn't buried in tickets by Black Friday. Compelling event: The holiday rush, which shows up on the same day whether anyone signs anything or not.
- Task: Project two-year cost savings, pick the tier; Owner (theirs / ours): Champion / your SE; Due: Week −6 - Task: Present savings and budget plan to the CFO; Owner (theirs / ours): Champion (you draft the memo); Due: Week −6 - Task: Sign off on payment amount and structure; Owner (theirs / ours): CFO; Due: Week −5
Cutoff, agreed with the champion: if the security review hasn't kicked off by week −6, we revisit together whether a holiday go-live is still realistic.
The last row is the VP of support looking at ticket volume after the busiest week of her year, which is the outcome she actually cares about, and the reason she'll keep opening the plan.
Agreement doesn't tell you much, since everyone says "looks great" to a plan on a call. What tells you something is what they do to it after you hang up:
Those edits are deal evidence, and they're better evidence than "the champion said yes."
So use the plan strategically, not administratively. Too many reps treat a MAP as permission to send reminders ("you said you'd do X by today, so I'm following up"). Look for these instead:
Sometimes the row that's stuck is a whole workstream. On one deal from an enterprise team I advise, the buyer's legal review of the MSA had sat for about three months with no executive pushing it, and the risk was that the reason to buy would fade while it sat. A deal review flagged it two months before legal would have escalated, so the forecast moved ahead of the surprise. The fix wasn't more follow-up. They pulled the paper process out as its own workstream, split it into separate approval gates (data protection, IP, and AI governance among them), put an owner and a date on each, had the lawyers on both sides work them in parallel, and added executive weight wherever things stalled. It closed about two months after that review, on a three-year contract.
And as the deal grows, the plan is also where your multithreading shows up in writing: every new owner on the plan is a thread, with a date attached.
"Buyers hate MAPs. They know it's a sales tactic." Some do, and when it's really a close plan, they're right to. The DevOps director liked project plans, he just wouldn't bring one to his CTO before the memo. So skip the MAP:
Take your biggest late-stage deal and: