Solutions
Discover how you can run your deals on Cobl, by use-case, industry or role.
Sales
Guides

Mutual Action Plans: A Practical Guide and Template

A practical mutual action plan guide and template for bid and pre-sales teams. See which milestones need a document, who owns it, and why plans stall.

This guide is for bid managers, pre-sales leads, and enterprise sellers who already run a mutual action plan and have watched it go stale by month three. If your deals close in two weeks with a single decision maker, you do not need one.

A mutual action plan (MAP) is a shared timeline, owned jointly by the seller and the buyer, that lists every milestone, owner, and date required to get a deal signed. Most MAPs fail for a reason the published guides never name: roughly half of their milestones are not meetings, they are documents someone has to produce, and the plan says nothing about who produces them or how long that takes. A plan that schedules a security review in week six without asking who fills in the questionnaire is a calendar, not a plan.

Key takeaways

  • A mutual action plan is a shared timeline that the seller and the buyer build together, listing every milestone, owner, and date needed to move from an agreed business problem to a signed contract. Close plan, mutual success plan, and joint execution plan are the same artifact under other names.
  • Introduce it once the buyer has confirmed the outcome they want and you have confirmed who can approve the spend. Earlier than that, you are asking someone to co-sign a timeline for a purchase they have not decided to make.
  • Most plans go stale by month three for two reasons: a missed date costs the buyer nothing, and roughly half the milestones are documents someone has to produce, which the plan never schedules.
  • Add the column every template omits: the deliverable behind each milestone, with a named producer on your side or theirs. A security review is a questionnaire someone has to complete. A commercial proposal is a document someone has to write, price, and get approved.
  • Keep the plan alive by updating it on screen inside every meeting, moving slipped dates out loud, tying at least one milestone to a date the buyer actually chose, and reducing your own document turnaround before asking the buyer to reduce theirs. Track whether your documents were opened, not just whether the box was checked.

What is a mutual action plan?

A mutual action plan is a document that a seller and a buyer build together, listing the milestones, owners, and dates needed to move from an agreed business problem to a signed contract and a working deployment. It is sometimes shortened to MAP.

The naming is a mess, and it is worth knowing which mess you are in. Salesforce and Clari both offer "joint execution plan" as a synonym. Recapped uses "joint engagement plan" instead. Clari adds "go-live plan". Most vendors accept "mutual success plan" and "close plan" interchangeably.

None of this is a real distinction. If a prospect, a manager, or a tool uses one of those labels, they mean the same artifact. What does change from one definition to the next is who owns it, and that difference is worth arguing about.

SalesHood describes the plan as co-created and co-owned, and treats the champion's willingness to co-own it as a leading indicator that the deal will close. Aviso defines it against a seller-only playbook. Recapped, by contrast, describes these plans as documents that account executives create.

The Recapped framing is the honest one about what usually happens, and the SalesHood framing is the right one about what should happen. A plan the rep writes alone and emails over is a project plan with a friendlier name. It carries no commitment from the other side, which is exactly why it stops being updated.

Use this test. If you deleted the buyer's name from the owner column and nothing about the plan changed, it was never mutual.

What a mutual action plan is not

  • Not a close plan you keep in the CRM. A close plan can be internal and private. A mutual action plan the buyer has never seen is not one.
  • Not a project plan. Project plans start after signature. A MAP ends there, or overlaps it by a few weeks.
  • Not a diagram of your sales process. Your sales process lists the steps your team takes. A mutual action plan describes the buyer's buying process, which runs on internal approvals, committees, and queues your pipeline stages know nothing about. Sellers on r/sales draw exactly this line when they describe the plan as a roadmap of how the buyer buys rather than of how you sell.
  • Not a partner program tracker. HubSpot uses the same phrase for a tool that lets Solutions Partners set annual goals with their Partner Development Manager. Same words, unrelated object. If that is what you were looking for, this page will not help.
  • Not a forecasting instrument. It gives you better forecast inputs, but a plan built to satisfy your own pipeline review will read that way to the buyer.

Why mutual action plans go stale by month three

The published guides treat the mutual action plan as a self-sustaining object. Build it well, keep it visible, and it stays alive. Practitioners report the opposite, and they are specific about the failure.

One thread on r/SalesOperations puts it plainly: a mutual action plan is a living document in theory and a stale one by month three in practice. A thread on r/sales is titled, without qualification, "Mutual Action Plans suck". The value of MAPs is openly debated by the people who run them, while the vendor guides treat it as settled.

That gap between what gets published and what gets practiced is the most useful thing on this subject, so it is worth being precise about why it happens. There are two reasons, and neither is laziness.

The asymmetry problem

A mutual action plan only creates pressure if missing a date costs both sides something. In most plans it does not. The buyer slipping a legal review by two weeks costs the buyer nothing. The seller slipping the same date costs the seller a quarter.

Sellers on r/sales describe this directly when they discuss close plans that read as to-do lists without consequence. When the cost of a missed milestone lands entirely on one side, the word "mutual" is decoration. The plan becomes a seller's chase list that the buyer politely tolerates.

The fix is not more follow-up. It is tying at least one milestone to something the buyer actually wants on a date they actually chose: a budget cycle that closes, a board meeting, a contract that expires, a go-live tied to a season. If no such date exists, you may be looking at a deal that has no real timeline, which is a go or no-go question rather than a planning question.

The layer nobody schedules

The second reason is more mechanical.

Read the main published guides on mutual action plans, from Salesforce, SalesHood, Aviso, Clari, and Highspot, and look for the documents a B2B deal actually produces: a proposal, an RFP response, a quote, a statement of work, a security questionnaire, a technical memo. They are not there. Five guides on how to plan the closing of a complex B2B deal, and not one of them names a single document that closing requires.

This matters because those documents are where the dates die. A milestone called "security review, week six" is not a meeting. It is a questionnaire someone on your side has to complete. A milestone called "commercial proposal, week four" is a document someone has to write, price, and get approved. The plan schedules the checkpoint and stays silent on the work.

The same guides also set the evidence bar low. Most carry no statistics at all, and the figures that do appear measure buyer experience in general, not whether a mutual action plan works.

The evidence that MAPs improve outcomes is thinner than the confidence with which it is asserted. That is not an argument against using one. It is an argument for using one that names its deliverables, because that is the part you can actually control, and because stalled late-stage deals are the single largest drag on a sales win rate.

When should you introduce a mutual action plan?

Introduce it once the buyer has confirmed a business outcome they want and you have confirmed who can approve spending on it. Earlier than that, you are asking someone to co-sign a timeline for a purchase they have not decided to make.

The guides genuinely disagree here, and the disagreement is not cosmetic.

  • SalesHood advises introducing the plan early, as soon as a champion is identified or even suspected.
  • Clari also says early, but qualifies it: there is no point discussing a plan until the buyer has agreed there is at least some potential.
  • Highspot places it later, immediately after shared objectives are agreed and budget authority is validated.

SalesHood and Highspot are describing different stages of the same cycle, potentially weeks apart. Both cannot be the rule.

Highspot's position is the defensible one, and its own reasoning shows why. The plan works by creating shared accountability. Accountability requires that both parties have already agreed on what they are accountable for. A plan introduced before the outcome is agreed has nothing to hold. You end up negotiating the timeline of a decision that has not been made, which reads as pressure and produces a polite yes with no follow-through.

SalesHood's instinct is not wrong about the champion. Identifying the champion early is correct. Handing them a timeline early is not. Separate the two: qualify the champion in discovery, build the plan once the outcome and the budget path are on the table.

One practical consequence. If you cannot get a buyer to co-own a plan after the outcome is agreed and budget authority is confirmed, that refusal is information. It usually means you are working with an enthusiast rather than a champion.

The mutual action plan template

Most published templates carry six or seven fields. Here is the full set, with one column the standard templates omit.

The mutual action plan template, with the deliverable column most published templates omit
FieldWhat goes in itWhy it matters
Business outcomeThe result the buyer wants, in their words and their metricAnchors the plan to their goal, not your close date
MilestoneOne step, named as a completed state, not an activity"Security review passed" is checkable, "security discussions" is not
DeliverableThe document or artifact the milestone requiresThe column that decides whether the date holds
Owner, buyer sideA named person, not a departmentDepartments do not miss deadlines, people do
Owner, seller sideA named person on your teamSays who produces the deliverable above
Target dateA date the buyer proposed or accepted out loudDates you set alone are yours to miss alone
StatusNot started, in progress, done, blockedFour states, no percentages
BlockerWhat is stopping it and who can unblock itTurns a silent slip into a named ask

Two rules on the dates. Work backwards from the buyer's fixed constraint, not forwards from today. And record who proposed each date, because a date the buyer proposed carries a commitment that a date you proposed does not.

The column every template is missing

The deliverable column is the change. Everything else on that list appears in most published templates.

Adding it forces a conversation you would otherwise have three weeks late. As soon as each milestone has to name a document, someone has to say who writes it and when it can realistically be ready. That is where a plan stops being optimistic.

It also changes what the plan reveals. A MAP without deliverables tells you a deal is late. A MAP with deliverables tells you why: the technical memo is waiting on an engineer who is staffed elsewhere, or the security questionnaire is sitting with a person who has never seen one.

Milestone to document: what each step actually requires

This table maps the milestones that appear in most mutual action plans to the artifact each one needs and the person who has to produce it. It is built from the failure patterns sellers describe publicly rather than from a vendor's template library.

Each milestone, the document it actually requires, and where it stalls
MilestoneThe document it actually requiresWho has to produce itWhere it stalls
Discovery alignedWritten summary of goals and success criteriaSellerNever written down, so the criteria quietly drift
Technical validationSolution overview or technical memoPre-sales or solutions consultantWaiting on an engineer staffed on another deal
Security review passedCompleted security questionnaire plus compliance evidenceSeller, with the security ownerQuestionnaire length, and certifications you do not hold
Commercial proposal deliveredPriced proposal with scope, terms, and assumptionsSellerRebuilt from scratch instead of reused
Business case approvedThe internal deck the champion presentsChampion, from material you supplyThe champion is left to build it alone
Legal and procurement clearedRedlines, vendor forms, supplier onboarding packBoth sidesThe stage where deals go quiet
References completedNamed references matched to the buyer's profileSellerReference fatigue on your own customer base
Signature and go-liveSigned contract plus an onboarding planBoth sidesOnboarding written after signature, not before

The security row deserves its own note, because it is where the seller and the buyer describe the same problem from opposite sides. On r/SaaS, a founder describes a procurement team sending a security questionnaire that's 47 pages long on a first enterprise deal. On r/procurement, buyers describe the same artifact as waste: sales teams waste time filling out security questionnaires that no one reads.

Neither side wants the document. Both sides need the milestone. That is precisely why it slips, and why building your security and compliance answers once, so they can be reused across deals, moves more dates than any amount of chasing.

Sellers on r/sales report the same thing about the stage after it, with two progressed deals worth 250,000 and 225,000 dollars stalling completely in legal and procurement. In both cases the plan was not wrong about what had to happen. It was silent about what had to be produced.

If most rows in that table describe work your team has to do rather than work the buyer has to do, the constraint on your deals is document production, not deal management. That is the problem Cobl is built for: the deal materials a plan schedules, generated from the context of the deal itself rather than assembled from scratch each time.

How to keep the plan alive after week two

A plan that is not updated is worse than no plan, because it produces false confidence in your forecast. Four practices keep it live.

  1. Review it inside the meeting, not after it. Open the plan on screen in the first three minutes of every call and update it live. A plan updated by one person afterwards becomes that person's document again.
  2. Change dates out loud. When a date slips, move it in the plan while both parties are present and record the new blocker. Silent slippage is how a plan dies without anyone deciding to abandon it.
  3. Give every deliverable a named producer before the milestone is agreed. If nobody on either side will put their name against producing the artifact, the milestone is not real yet.
  4. Reduce your own turnaround before you ask the buyer to reduce theirs. You have very little leverage over a procurement queue. You have complete control over how long your side takes to produce a proposal or a technical memo.

That last point is where most of the recoverable time sits. At Open, a public sector organization, Engagement Executive Thierry Wawrzyniak describes proposals that used to take two to three hours from scratch now coming back as a framework version in about five minutes, leaving the team time to adapt it to the client. Open reports cutting RFP response time by half. Those hours are not a productivity statistic in the abstract. They are the difference between a milestone that holds its date and one that moves twice.

Track engagement, not check marks

A check mark tells you the buyer said a step was done. It does not tell you whether anyone on their side engaged with what you sent.

The more useful signal is behavioral: whether the proposal was opened, how many times, by how many people, and when it was last viewed. A business case that your champion opened once and never returned to is a business case that is not being presented internally, whatever the plan says. A document opened repeatedly by people you have not met means the buying group is larger than your stakeholder map, and that stakeholders are shaping the decision whose objections you have never heard.

None of the guides we reviewed mentions engagement signals at all. It is the cheapest correction available to a mutual action plan, because it replaces asking with observing.

Do you need mutual action plan software?

Not to start. A shared spreadsheet or a collaborative doc runs a mutual action plan perfectly well, and the discipline matters far more than the format.

There is a real product category here. Dock, Aligned, Accord, GetAccept, and Recapped all build dedicated MAP and digital sales room tools, with buyer-facing portals, task notifications, and engagement tracking. If you run many parallel enterprise deals and the plan itself is your bottleneck, those tools solve that bottleneck well.

Be clear about which bottleneck you have. A MAP tool makes the plan easier to run. It does not make the documents the plan schedules easier to produce. If your slippage is concentrated in the deliverable column, better plan software will give you a very well organized record of the same delays.

That is the distinction worth drawing before you buy anything. Deal materials that arrive late slow a deal regardless of how elegantly the delay is displayed. It is the same observation Daoud Chami, Data Science and AI Manager at CBTW, makes about the documents that carry real deals: RFPs, technical memos, and structured reports follow an internal grammar, and generating them with control at every stage is a different problem from tracking them.

One caution on any tool, Cobl included. AI-generated deal documents still need a human pass before they reach a buyer, particularly on pricing, scope, and anything a legal team will read.

Make the plan name its documents

A mutual action plan is a good instrument that is usually built one column short. Milestones, owners, and dates are the easy part, and every published template covers them. The deliverable behind each milestone is what determines whether the date survives contact with a procurement queue, a security team, and a champion who has to sell internally without you in the room.

Add the column. Name the document. Name the person producing it. Then reduce your own turnaround before you ask the buyer to reduce theirs.

If the deliverable column on your plan is where the slippage clusters, that is a document production problem rather than a deal tracking problem. You can try Cobl for free for 30 days, at app.cobl.ai.

FAQ

What is the difference between a mutual action plan and a close plan?

In practice, very little. Most vendors treat close plan, mutual success plan, joint execution plan, and joint engagement plan as synonyms for the same artifact. The only distinction worth keeping is visibility: some teams reserve "close plan" for an internal document the buyer never sees, and "mutual action plan" for the shared version. If the buyer has not seen it, it is not mutual.

Do you need both a mutual action plan and a business case?

Yes, and they do different jobs. The business case argues why the purchase is worth making and is usually presented internally by your champion. The mutual action plan sets out how the purchase gets done and by when. Sellers on r/sales who use both tend to build the business case first, then the plan, because the plan needs an agreed outcome to hang milestones on.

Who should own the mutual action plan, the rep or the buyer?

Both, in name and in the owner column. In practice the seller maintains it, because the seller has more at stake in it staying current. Ownership shows up in whether the buyer has named people against their own milestones. If every owner on the plan works at your company, you have a seller's project plan.

How often should a mutual action plan be updated?

Every time you speak to the buyer, during the conversation rather than afterwards. Plans that are updated in a separate admin block drift, and practitioners consistently report them going stale within a few months. If a plan has not changed in three weeks on an active deal, either the deal has stalled or the plan has.

What should a mutual action plan template include?

Business outcome, milestone, deliverable, an owner on each side, target date, status, and blocker. The deliverable field is the one most templates leave out and the one that decides whether the dates hold, because it forces each milestone to name the document it needs and the person producing it.

Do you need mutual action plan software to run one?

No. A shared document works, and several dedicated tools exist if plan management itself is your constraint. Diagnose the constraint first: if your delays cluster around producing proposals, technical memos, and questionnaires rather than around tracking tasks, a plan tool will document the delay rather than remove it.