mutual-action-plan

Mutual Action Plan

A mutual action plan is a shared document that aligns buyer and seller on every step between "we want to move forward" and "the contract is signed and live." The word mutual matters: if the buyer has not contributed to and agreed on the plan, it is a vendor's wishlist, and the deal it was supposed to protect will stall in legal, procurement, or a budget cycle nobody mentioned. The costly mistake this skill prevents is discovering a six-week security review three weeks before the quarter ends.

Operating procedure

Steps run in this order because dates cannot be set before milestones are known, and milestones cannot be known before the buyer has contributed theirs.

Step 1: Gather inputs

Collect before drafting anything. Label guesses as guesses.

1. Deal stage and evidence of intent - a MAP before clear evaluation intent is premature. Default assumption: qualified with verbal intent.
2. Buyer's desired go-live date, or the business event driving urgency. If neither exists, that absence is a finding (see Step 3).
3. Known buyer-side steps: security review, legal, procurement, budget approval, board sign-off. Default: unknown, to be elicited from the buyer.
4. Deal size and cycle length. A sub-30-day, low-complexity deal gets the lightweight variant (see Escape hatch).
5. Names or roles for owners on both sides.

Step 2: Introduce the MAP to the buyer

Introduce it only after the buyer has expressed clear intent to evaluate seriously - never on the first call. Framing: "A lot of our customers find it helpful to build a shared timeline so nothing gets stuck waiting on anyone. Would you be open to putting one together?" Present it as a coordination tool, never a closing tool; buyers who smell a closing device disengage from it.

Step 3: Anchor on the go-live date and work backward

Start from the buyer's desired go-live date and schedule backward. If the buyer has no date, ask: "Is there a business outcome or event this needs to be live before?" The answer either surfaces real urgency or reveals that urgency does not yet exist - in which case the MAP's first milestone is establishing the compelling event, not exchanging redlines.

Step 4: Build the milestone table

Use exactly these columns: milestone, owner (buyer or seller, by name or role), due date, status. Keep it in a shared document the buyer can edit - a MAP only the vendor can update is not mutual.

Seed with the typical mid-market SaaS milestones, then ask the buyer to add every step on their side the rep might not know about - budget approval cycles, procurement reviews, board sign-offs:

• Technical review / security questionnaire completed
• Legal review started
• Reference calls completed
• Final business case signed off internally
• Contract redlines exchanged
• Signatures collected
• Kickoff scheduled

Step 5: Date the milestones with buffer

Dating rules:

• Pad every third-party-dependent step by 50%: if legal typically takes two weeks, put three on the plan. Slipping a MAP date by a day looks sloppy; finishing early is fine.
• Every milestone gets a single named owner. "Both teams" is not an owner - split the milestone until each piece has one name.
• No two consecutive milestones due on the same date; sequence forces honesty about dependencies.
• The gap between signature and go-live must reflect real onboarding time, not zero.
• Confirm each buyer-side date with the buyer out loud. A date the buyer never agreed to is a seller fantasy.

Step 6: Keep it alive

Open every subsequent call with the MAP: "Before we dive in, let me pull up our plan - we have three items due this week." This maintains momentum and makes silent slippage uncomfortable. When a milestone slips, update the date and record why in the status column. A MAP showing perfect on-time completion is a red flag that nobody is tracking honestly.

Template: MAP skeleton

MUTUAL ACTION PLAN - [FILL: buyer company] + [FILL: seller company]
Target go-live: [FILL: date]   Driving event: [FILL: business outcome/event, or "none identified - establish"]
Shared doc, editable by both sides. Reviewed at the start of every call.

| # | Milestone                                    | Owner (name/role)     | Due date | Status / notes |
|---|----------------------------------------------|-----------------------|----------|----------------|
| 1 | Success criteria for evaluation agreed        | [FILL: buyer name]    | [FILL]   |                |
| 2 | Technical review / security questionnaire done| [FILL: buyer name]    | [FILL]   |                |
| 3 | Reference calls completed                     | [FILL: seller name]   | [FILL]   |                |
| 4 | Business case signed off internally           | [FILL: buyer name]    | [FILL]   |                |
| 5 | [FILL: buyer-added step, e.g. procurement]    | [FILL]                | [FILL]   |                |
| 6 | Legal review started                          | [FILL: buyer name]    | [FILL]   |                |
| 7 | Contract redlines exchanged                   | both - split: [FILL]  | [FILL]   |                |
| 8 | Signatures collected                          | [FILL]                | [FILL]   |                |
| 9 | Kickoff scheduled                             | [FILL: seller name]   | [FILL]   |                |

Slipped items log: [date, milestone, reason, new date]

Bad date-setting: "Legal review - Owner: both teams - Due: end of month." No single owner, no buffer, a vague date nobody committed to.

Good date-setting: "Legal review started - Owner: Dana Reyes (buyer, legal ops) - Due: May 9 (typical turnaround 2 weeks; padded to 3). Confirmed with Dana on the Apr 14 call."

Deliverable

Produce a shared MAP document containing the target go-live date and driving event, a milestone table with single named owners and buffer-padded dates for every row, buyer-contributed milestones explicitly included, and a slipped-items log - plus the introduction framing script and the standing agenda line for reviewing it each call.

Do NOT

• Do not introduce the MAP on the first call - before intent exists it reads as pushy process and gets ignored.
• Do not build the MAP alone and send it for signature; a plan the buyer did not shape carries no buyer accountability.
• Do not set dates without buffer - one publicly slipped date erodes the plan's authority for every date after it.
• Do not assign milestones to "both teams"; diffuse ownership is how milestones silently die.
• Do not treat a fully green MAP as good news without checking - perfect status usually means it stopped being tracked.
• Do not use the MAP to pressure-close ("per our plan, you owe me a signature Friday"); it is a coordination instrument, and weaponizing it destroys the mutuality that makes it work.

Quality bar

Ship only when: every milestone has one named owner and a dated deadline; buyer-side steps came from the buyer's mouth, not the rep's assumptions; third-party steps carry 50% buffer; the go-live date traces to a business event or the plan's first milestone is finding one; the document lives somewhere the buyer can edit; and the rep has a standing habit of opening calls with it.

Escape hatch

For a simple or short-cycle deal (under 30 days, no procurement or security review), skip the table: send a bullet list in the follow-up email - three to five actions, one owner each, one deadline each. The goal is shared accountability, not administrative overhead. If the deal keeps stalling despite a healthy MAP, the problem is usually qualification, not coordination - revisit with discovery-call-prep.