# Mutual Action Plan > Builds a mutual action plan (MAP) with shared milestones, named owners, and buffer-padded dates that drives a qualified deal from verbal intent to signature and go-live. Use when someone asks "build a mutual action plan for this deal", "how do I keep this deal from stalling", "the buyer said yes but nothing is moving", or once a prospect is qualified and has expressed intent to move forward. Do NOT use for preparing the qualification call itself - use discovery-call-prep instead. Do NOT use for scripting the negotiation and close conversation - use closer-sales-script instead. - Skill: `skillmedev/mutual-action-plan` (Agent Skill) - Install (CLI): `npx skillmds@latest add skillmedev/mutual-action-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/skillmedev/mutual-action-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: SkillMedev (https://skillmd.com/u/skillmedev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/skillmedev/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.