Quick answer: A mutual action plan is a shared, dated sequence of steps that the seller and the buyer both commit to between today and go-live. It includes each step, an owner on both sides, a date, and the dependencies between steps, built backwards from the buyer's own deadline. Its real value is diagnostic: a buyer who will not co-build one is telling you something about the deal.
Most mutual action plans are not mutual. A rep builds a timeline, emails it over, the buyer says "looks good", and it is never opened again. That document is a project plan with a friendly name.
What is a mutual action plan in sales?
A mutual action plan, often shortened to MAP, is a jointly built 1-page document listing every step between the current conversation and the buyer getting value, with named owners on both sides and dates attached. It is sometimes called a close plan, a joint execution plan or a success plan.
Two words carry the weight. Mutual means the buyer has steps and owns them, not just the seller. Action means each line is a thing someone does on a date, not a stage name.
What should a mutual action plan include?
A MAP should include 7 things. Most templates include 4 and fail on the 3 that matter.
| Element | Why it matters |
|---|
| Every step to go-live | Including steps after signature |
| An owner on each side | A step with one owner is not mutual |
| A date per step | Not a week number or a quarter |
| Dependencies | Which steps block which |
| The buyer's deadline and its driver | Working backwards is what makes dates real |
| Internal approval steps | Legal, security, procurement, finance |
| A review cadence | When you both look at it again |
The three commonly missing: dependencies, the driver behind the deadline, and internal approval steps. A plan without those three looks complete and still slips, because the thing that slips is usually a security review nobody put on the page.
How do you create one with the buyer?
Build it live, on a shared screen, working backwards from the buyer's date. The order matters more than the format.
-
Establish the deadline and its driver. "We want it live by March 1 because the contract with the current vendor ends February 28." A date without a driver will move.
-
Work backwards to today. Go-live, then training, then provisioning, then signature, then legal, then security review, then approval, then decision.
-
Attach a real duration to each step, asked of the buyer: "how long does your security review usually take?" Their estimate, not yours.
-
Name an owner on both sides for every step. Steps with only your name are not mutual.
-
Mark dependencies. Which step cannot start until another finishes.
-
Agree a review cadence and put the first review in both calendars before leaving the call.
Step 3 is where most of the value appears. Asking how long security review takes usually produces a longer number than the rep assumed, and that number is the difference between a forecast and a miss.
What does the template look like?
A copy-paste version with 13 steps. Keep it to 1 page; a MAP long enough to need scrolling stops being read.
The plan
Account: Our owner:
Opportunity: Their owner:
Target go-live: What drives that date:
Last reviewed: Next review:
STEP | OUR OWNER | THEIR OWNER | DUE | DEPENDS ON | STATUS
---------------------------------------------------------
1. Technical validation call
2. Security questionnaire returned
3. Security review complete
4. Reference call
5. Pricing agreed
6. Legal / MSA review
7. Procurement approval
8. Signature
9. Provisioning and account setup
10. Admin training
11. Team onboarding
12. Go-live
13. 30-day check-in
OPEN RISKS
Risk | Impact on the date | Who is resolving it
AGREED AT: [date, in which meeting]
Steps 9 to 13 are the ones sellers cut. Leaving them off signals that your interest ends at signature, and it removes the steps that give the buyer a reason to keep the plan open after the contract is signed.
What are some real examples?
2 shapes, depending on deal complexity.
A mid-market deal, six weeks. Eight steps, one approval layer, a single security questionnaire rather than a review, and go-live two weeks after signature. Review cadence weekly, attached to the existing call.
An enterprise deal, five months. Eighteen steps, three approval layers, a formal security review with a named reviewer, procurement with its own intake process, legal redlines, a phased rollout by region, and a 90-day success review. Review cadence every two weeks, with a named owner on each side.
The enterprise version's value is almost entirely in the approval and procurement steps, which are the ones a seller cannot see without asking.
What should an action plan include that most people forget?
The dependency chain and the buyer's internal calendar, plus the 3 specifics below. Most plans list steps in order and imply they happen sequentially, when in practice several run in parallel and one blocks everything.
Three specifics worth adding every time:
- Blackout periods. Quarter-end close, holidays, an offsite, a product freeze.
- Who covers each owner when they are away. A five-month plan will cross someone's vacation.
- What happens if a step slips. Does the go-live date move, or does something compress?
Why does it improve forecast accuracy?
Because it converts a close date from an opinion into arithmetic. A date derived from thirteen steps with durations the buyer supplied is checkable; a date derived from the end of your quarter is not.
It also produces an early warning signal. When a step misses its date, the deal has a visible problem weeks before it would otherwise surface, and the conversation is about a specific step rather than about whether the buyer is still interested.
The diagnostic value is the part most sellers underuse.
A buyer who will not name an owner for the security review, or will not share when procurement meets, is telling you the deal is earlier than your pipeline says. That is useful on the day you learn it, not at the end of the quarter.
How do you keep it alive?
Review it in the meeting every 1 to 2 weeks rather than emailing it, and update it live on screen. A plan edited in front of the buyer stays a shared document; one emailed as an attachment becomes yours.
The practical failure is reconstruction. Three weeks later nobody is sure whether the buyer committed to returning the security questionnaire by the 12th or merely said they would try, and the plan drifts from what was agreed. Writing commitments as they are made is the fix, and our action items guide covers the format.
If your team records its calls, Lynkk writes a summary after each one with action items, each with an owner and a due date, and you can push those tasks to Jira. On Pro, Ask Lynkk searches all your notes, so "who agreed to the 12th, and in which call?" gets an answer with numbered sources instead of an argument. Our guide to sales conversation intelligence covers the wider pattern.
Frequently asked questions
What is a mutual action plan?
A shared, dated sequence of steps that the seller and buyer both commit to between today and go-live, with named owners on both sides.
What is a mutual action plan in sales used for?
Coordinating the path to signature and go-live, and diagnosing deal health: a buyer unwilling to co-own steps signals an earlier-stage deal than the pipeline shows.
What should a MAP include?
Every step to go-live, owners on both sides, a date per step, dependencies, the buyer's deadline and its driver, internal approval steps, and a review cadence.
How do you create one with the buyer?
Build it live with the buyer, working backwards from their deadline, asking them for the duration of each internal step rather than estimating it yourself.
What is the difference between a mutual action plan and a close plan?
Largely naming. A close plan often stops at signature; a mutual action plan usually continues through onboarding to go-live.
Why do these plans fail?
They are built alone and sent over, they omit internal approval steps and dependencies, and they are never reviewed after the call in which they were created.
Further reading: HubSpot's guide to key account management.