Short answer
A mutual action plan is a shared, dated list of the steps both buyer and seller must complete to reach the buyer's goal, such as go-live by a deadline. A good template starts from that date and works backward, names one owner on the correct side for every step, marks which dates the buyer has confirmed, lists dependencies and risks, and is short enough to review in five minutes at every meeting.
- Start from a date the buyer cares about and work backward, not forward from today.
- Every step has one named owner, and most of the owners should be on the buyer's side.
- Mark each date as confirmed or proposed; only the buyer can confirm theirs.
- Ask how long legal, security and procurement really take, and plan around holidays.
- Send it as a draft for correction; a plan the buyer edits is a plan the buyer owns.
On this page
This page is for account executives, founders and account managers working deals with several people on the buying side, a review by legal, security or procurement, and a date that matters to the customer. It gives you a one-page plan, the columns for a spreadsheet version, the emails to propose and maintain it, and a filled-in example. If your deal has one buyer and a one-week cycle, a good follow-up email after the meeting does the same job.
What a mutual action plan is
A mutual action plan (MAP) is a shared timeline of the steps, people and dates needed to get from where a deal is today to the outcome the buyer wants. You'll also see it called a mutual close plan, a joint execution plan or a mutual success plan.
GitLab's public sales handbook gives a clear working definition. It describes a mutual close plan as "a visual timeline of all the necessary tasks, individuals, and deadlines necessary to get the deal through closure and into deployment", created with the customer's champions, advocates and economic buyers. Note the last part: it runs past the signature to deployment, because that's the date the buyer cares about.
A MAP isn't a contract and it isn't a forecast. It's a shared working document. It becomes "mutual" when the buyer has corrected it and accepted their share of the work.
When to use one, and when not to
| Deal | Use a MAP? | Why |
|---|---|---|
| One decision maker, simple purchase, short cycle | No | A recap email with next steps is enough |
| Three or more people involved on the buyer's side | Yes | Someone has to coordinate them, and it shouldn't only be you |
| Legal, security or procurement review required | Yes | These steps have lead times the buyer often doesn't know |
| The buyer has a hard date (audit, launch, renewal of a current supplier) | Yes | Working back from it shows what has to happen this week |
| No agreed problem or date yet | Not yet | A plan without a reason to finish is just your to-do list |
Introduce it once discovery has confirmed a problem and a date the buyer cares about. GitLab's handbook puts it at the start of deal closure, after the economic buyer's verbal commitment; many teams start earlier with an evaluation plan (one of the templates below) and extend it.
What goes in a mutual action plan
| Section | What to write | Why it matters |
|---|---|---|
| Goal and date | The buyer's outcome and the date they need it by | Everything is worked back from this |
| Why that date | The buyer's reason, in their words | Keeps the date real when things slip |
| People | Name, role and responsibility on both sides | Shows who decides, signs and approves |
| Steps | Outcomes, not activities: "Security approved", not "Security call" | You can tell when an outcome is done |
| Owner | One person for each step | Shared ownership means no ownership |
| Date and status | Due date, confirmed or proposed, done or not | Separates what the buyer agreed from what you hope |
| Dependencies | What must finish first | Finds the tight step |
| Risks | What could move the date, and the plan if it does | Raised early, risks can be fixed |
Keep it to 8 to 15 steps. A 40-row plan won't be reviewed.
How to build it
- Start from the buyer's date. Go-live, first delivery, launch or the day a current contract ends. Ask why that date matters and write the answer down.
- Work backward with real lead times. Ask the buyer how long their legal review, security review and purchase order process take. Then add the holidays: in the US, Thanksgiving week and the last two weeks of December slow most approvals.
- Give each step one owner. Most steps in the second half of a deal belong to the buyer's people. Name them; "IT" isn't an owner.
- Send it as a draft. Ask the buyer to correct the dates and owners. Only mark a date confirmed when the person who owns it has agreed.
- Review it at every meeting. Five minutes at the start: what's done, what's next, what's at risk.
- Update it when things move, and note why. A plan that's never changed is a plan nobody is using.
Mutual action plan templates
Copy the version that fits your deal. Fill every bracket with something the buyer has told you or agreed to.
[Buyer company] and [your company]: plan to [goal] by [date] Why this date: [the buyer's reason, in their words] People [Buyer]: [name, role, responsibility] for each person, including who signs [Seller]: [name, role, responsibility] Steps (owner, due date, status: confirmed / proposed / done) 1. [Outcome] ([owner], [date], [status]) 2. [Outcome] ([owner], [date], [status]) 3. [Outcome] ([owner], [date], [status]) 4. Contract signed ([owner], [date], [status]) 5. [Onboarding or delivery step] ([owner], [date], [status]) 6. [Goal achieved] ([owner], [date], [status]) Tightest step: [which one, and why] Risks: [what could move the date] / [what we'll do if it does] Last updated: [date] by [name]
Columns: Step | Outcome (what "done" means) | Owner | Owner's company | Depends on | Due date | Date status (proposed / confirmed) | Status (not started / in progress / done / blocked) | Notes | Last changed Header rows above the table: Goal | Goal date | Why this date | Buyer lead | Seller lead | Next review date Second tab, change log: Date | What changed | Why | Agreed by
Buyer - Decision maker (signs or approves budget): [name, role] - Day-to-day lead (champion): [name, role] - Users or their manager: [name, role] - Approvers (legal, security, procurement, finance): [name, role] for each Seller - Deal lead: [name, role] - Specialist (technical, implementation): [name, role] - Executive sponsor, if needed: [name, role] Who's missing: [roles we haven't met yet]
Subject: Draft plan to [goal] by [date] Hi [first name], You said [goal] needs to happen by [date] because [their reason]. I've worked back from that date to see what has to happen when. It's a draft, and I've guessed at some dates on your side. [Plan, or link to it] Two questions: 1. Are the owners right, especially [step]? 2. How long does [legal / security / procurement] usually take at [company]? The tight step looks like [step]. Could we go through it together at our next call on [date]? [Your name]
Subject: Plan to [goal]: update [date] Hi [first name], Done since last time: [step], [step]. Next two weeks: [step] ([owner], [date]), [step] ([owner], [date]). At risk: [step], because [reason]. [What's being done about it.] The goal date of [date] still holds. Anything I've got wrong? [Your name]
Subject: [Step] has moved: what it means for [goal date] Hi [first name], [Step] has moved from [old date] to [new date] because [reason]. Working forward from there, [goal] would now land on [new goal date]. Two options to keep [original date]: 1. [Run two steps in parallel, e.g. start sizing while legal finishes] 2. [Reduce scope for the first phase] Or we move the goal date. Which would you prefer? [Your name]
[Buyer] evaluation of [product or service]: [start date] to [end date] What we're testing: [the problem, in the buyer's words] Success looks like: [measurable criteria the buyer set, e.g. 95% of orders correct] Who's involved: [names and roles on both sides] Steps: 1. [Setup] ([owner], [date]) 2. [Trial or pilot] ([owner], [dates]) 3. [Results review] ([owner], [date]) Decision after the evaluation: [who decides, and by when] If successful, next step: [proposal, contract or rollout]
Worked example: working back from an audit date
Illustrative example. The companies, people and dates are fictional, to show the method.
The seller: Bluestem Uniform Rental (bluestemuniform.example), a uniform rental company. The buyer: Marlow Bakeries (marlowbakeries.example), which needs new food-safe uniforms for 140 production staff. The date: a food safety audit on Tuesday 2 March 2027. Ruth, the plant manager, wants the new garments in use for two weeks before the audit, so the goal is first delivery by 16 February. It's Monday 26 October 2026.
Working backward from the goal:
| Step | Owner | Date | Lead time |
|---|---|---|---|
| First delivery | Bluestem route manager | Tue 16 Feb | Goal |
| Garments made and embroidered | Bluestem | 19 Jan to 16 Feb | 4 weeks after final sizes |
| Sizing sessions on all three shifts | Bluestem and Marlow HR | 12 to 19 Jan | 1 week |
| Contract signed | Marlow controller | Fri 8 Jan | Before garments are ordered |
| Legal review | Marlow legal | 10 Dec to 8 Jan | 15 working days, plant shut 24 Dec to 1 Jan |
| Final proposal approved | Ruth and the controller | Fri 4 Dec | After Thanksgiving week |
| Wear trial results reviewed | Ruth and two shift leads | Tue 24 Nov | Before the proposal |
| Wear trial, 20 staff | Marlow shift leads | 9 to 20 Nov | 2 weeks |
| Sample garments delivered | Bluestem | Fri 6 Nov | 2 weeks from today |
The arithmetic shows the tight step. Marlow's legal team takes 15 working days, and the plant shuts from 24 December to 1 January. Counting 15 working days back from the 8 January signature, skipping the shutdown, legal must have the contract by 10 December. That leaves three working days between proposal approval (4 December) and legal, too few to draft a contract, so Bluestem drafts it during the wear trial and sends it with the proposal.
The plan Ruth received had nine steps, six owned by Marlow people, and asked her one question: "Is 15 working days right for legal, given the shutdown?" She corrected it to 20, which moved the legal deadline to 3 December. Bluestem ended the wear trial a day early, moved the results review to Friday 20 November and the approval to Tuesday 1 December. Because Ruth made the correction, the dates were now hers.
Knowing who signs, who approves and who's new is what makes the people section accurate. Bebop researches each account and writes a playbook with the people involved, what's happening at the company and the angle to open with.
Mistakes to avoid
- Building it alone and sending it as final. The buyer has no reason to own a plan they didn't shape.
- Only seller tasks. If every step is yours, it's your to-do list, not a mutual plan.
- Activities instead of outcomes. "Security call" can happen without anything being approved.
- No reason behind the goal date. Without a reason, the date slips at the first delay.
- Treating proposed dates as confirmed. Mark which the buyer has agreed to.
- Using it as pressure. A plan that exists to force a quarter-end signature is a forecast, and buyers can tell.
- Letting it go stale. If it hasn't been updated in two weeks, the deal has probably stalled.
Plan health check
Answer yes or no before each review:
- The goal date has a reason the buyer gave you.
- Every step has one named owner.
- At least half the steps are owned by the buyer's people.
- The buyer has confirmed the dates for their own steps.
- Legal, security and procurement lead times came from the buyer, not from your guess.
- Holidays and shutdowns are in the dates.
- It's been updated since the last meeting.
- You know which step is the tightest.
Three or more noes: fix the plan before you forecast the deal.
Next step: when the plan reaches the proposal step, write it with the sales proposal template, which includes the options and pricing table the approvers will ask for.
Sources
- Deal Closure (GitLab sales operating procedures), GitLab Handbook, accessed 26 October 2026
- Federal Holidays, US Office of Personnel Management, accessed 26 October 2026
Written by the Bebop team at Blackpearl Group. Last updated .
Questions people ask
What is a mutual action plan in sales?
A mutual action plan is a shared timeline of the steps, people and dates needed to get a deal from its current stage to the outcome the buyer wants, usually go-live by a certain date. Both sides own steps in it. It's built with the buyer, reviewed at each meeting and updated when dates move. It isn't a contract or a forecast; it's a working document both sides use.
When should you introduce a mutual action plan?
Once discovery has confirmed a real problem and a date that matters to the buyer, such as a launch, an audit or the end of a current contract. Without that date, the plan has nothing to work back from. Some teams start with an evaluation plan during a pilot and extend it into a full plan; others, like GitLab's sales team, create it once the economic buyer has given a verbal commitment.
What should a mutual action plan include?
The buyer's goal and the date they need it by, the reason for that date, the people on both sides with their roles, 8 to 15 steps written as outcomes, one owner and a due date for each step, whether each date is confirmed or proposed, dependencies between steps, and the risks that could move the date. Add a short change log so everyone can see why dates moved.
What's the difference between a mutual action plan and a close plan?
A close plan is often the seller's internal plan for getting a deal signed, and it can include things the buyer never sees, such as forecast notes and risks. A mutual action plan is shared with the buyer, built with them and usually runs past the signature to go-live. The terms overlap, and GitLab's handbook uses "mutual close plan" for the shared version.
How do you get a buyer to use a mutual action plan?
Build it around a date the buyer cares about, send it as a draft and ask them to correct the owners and dates on their side. Ask how long their own legal, security and procurement steps take. Review it briefly at the start of every meeting. A buyer who has edited the plan treats it as theirs; one who received a finished plan treats it as your paperwork.