--- name: building-deal-close-plans description: >- Builds a buyer-agreed mutual action plan for a late-stage enterprise deal: dated milestones back-planned from the go-live date, a multithreading map of every stakeholder and their coverage owner, and an explicit legal, security, and procurement path to signature. Use when the user says close plan, mutual action plan, MAP, mutual success plan, "path to signature", "what needs to happen to close by", procurement, legal review, security review, redlines, PO, order form, "the deal keeps slipping", multithreading, or "we're single-threaded". Do NOT use for scoring qualification gaps (see qualifying-with-meddpicc), for discovery question planning (see running-discovery-calls), or for diagnosing a buyer who will not decide at all (see handling-buyer-indecision). metadata: version: "1.0" --- # Building deal close plans Produce one mutual action plan for a named opportunity: dated milestones back-planned from the buyer's required go-live, a stakeholder coverage map, and the paper path through security, legal, and procurement. Out of scope: qualification scoring, discovery, negotiation strategy, and any plan the buyer has not been asked to co-own. ## What separates a close plan from a task list The plan covers Decision Process and Paper Process as two distinct phases. Decision Process is "the steps that the buyer will take to decide whether they will buy your solution"; Paper Process is "the series of steps that follow the Decision Process in how you will go from Decision to signature" ([MEDDICC](https://meddicc.com/meddpicc-sales-methodology-and-process)). Deals slip at quarter-end because the Paper Process was never mapped, not because the buyer changed their mind. Two properties make a plan mutual rather than internal: - Every milestone has a **named owner on the buyer side**, not just a rep task. - The buyer has **seen and edited the dates**. A plan the buyer has not corrected is your forecast, not their commitment. ## Multithreading targets Design coverage against these observed figures, all from Gong Labs analysis of its customer base (observational correlations from a vendor's own data, not controlled experiments) ([Gong](https://www.gong.io/blog/the-best-sales-insights-of-2025)): - **77%** of deals involve multiple buyer contacts, across 1.8M opportunities. - Successful deals have **twice as many** buyer contacts as unsuccessful ones, same sample. - Strategic enterprise deals average **17 contacts**. - Multithreading on deals over **$50K** is associated with a **+130%** win-rate lift. - Closed-won deals have a selling team **67% larger** than lost deals. - Bringing a sales engineer into the demo and technical questions is associated with up to a **+30%** win-rate lift for enterprise reps. Use the deal's size band to set the target: below $50K, cover the champion, the economic buyer, and one technical evaluator; above $50K, treat single-threading as the top risk in the plan and name a coverage owner for every stakeholder. ## Workflow Copy this checklist into your reply and tick items as you complete them: ``` - [ ] 1. Establish the buyer's compelling event and required go-live date - [ ] 2. Back-plan the Decision Process milestones from that date - [ ] 3. Back-plan the Paper Process: security, legal, procurement, PO - [ ] 4. Build the multithreading map with a coverage owner per stakeholder - [ ] 5. Run the plan audit; fix and re-run until every test passes - [ ] 6. Set the mutual-agreement ask and the re-baselining rule - [ ] 7. Emit the plan in the output template ``` **1. Anchor on the buyer's date.** Get the date something must be live and the business event behind it — fiscal deadline, contract expiry, regulatory date, board commitment. A date the buyer invented on a call under pressure is not an anchor; the timeline element you need is the buyer's actual urgency, driven by business events, fiscal deadlines, competitive pressure, or escalating pain ([Weflow](https://www.weflow.ai/blog/neat-selling)). If there is no such event, say so in the plan header and mark the whole timeline as unanchored, because every downstream date then inherits that risk. **2. Back-plan Decision Process.** Work backwards from go-live: implementation start, contract signature, final approval, business case submission, executive readout, evaluation completion, technical validation. Ask the buyer directly: "Can you walk me through the steps between now and a signed contract?" and "Is there a formal vendor selection committee, and who sits on it?" ([Weflow](https://www.weflow.ai/blog/meddpicc)). **3. Back-plan Paper Process.** This is the fragile step; use these exact questions and get durations from the buyer rather than estimating ([Weflow](https://www.weflow.ai/blog/meddpicc)): - "What does your legal and procurement process look like for a purchase of this size?" - "How long does legal review typically take for new vendor agreements?" - "Is there a security review process, and do you need a SOC 2 report or completed security questionnaire upfront?" - "Who in procurement should I contact early?" - "Are there any fiscal year deadlines that affect when the PO needs to be issued?" Record each answer as a duration with a named owner. Start the security questionnaire and vendor onboarding forms in parallel with, not after, commercial agreement, because those two queues are the longest and are owned by teams with no stake in your close date. **4. Multithread.** For every stakeholder, record name, title, role in the decision (approver, evaluator, influencer, blocker, user), what they are measured on, their current stance, and the person on your side who owns the relationship. Map "every stakeholder who influences, supports, evaluates, blocks or approves" with each person's motivation, concerns, and power — this is explicitly not a hunt for one decision-maker ([Weflow](https://www.weflow.ai/blog/neat-selling)). Where a stakeholder is uncovered, the plan item is a named introduction request to the champion with a date, not "build relationship." **5. Plan audit — validate, fix, re-validate.** Check every test below, fix failures, then re-run the full set, because moving one date usually breaks another dependency: - Every milestone has a date, a buyer-side owner, and a seller-side owner. - No milestone depends on a predecessor scheduled after it. - Security, legal, procurement, and PO issuance each appear as separate line items with buyer-quoted durations. - Every stakeholder in the map has a coverage owner, and the count meets the size-band target from above. - The critical path is marked and the total slack between last milestone and go-live is stated. Only proceed to step 6 when all five pass. Do not present a plan with an unmarked critical path; the buyer cannot prioritise what you have not identified as blocking. **6. Set the mutual ask and the re-baselining rule.** Send the plan to the champion with a request to correct the dates and add missing steps, and propose a standing review of the plan at each meeting. State the re-baselining rule explicitly in the document: any change to the close date demotes the deal out of Commit until it re-earns the criteria ([ORM-Tech](https://orm-tech.com/blog/sales-forecast-categories-explained/)). Making that consequence visible to the internal team is what stops silent date drift. **7. Emit** using the template below. ## Output format Use this exact section order and column set. The milestone table is parsed by deal-review and forecast tooling, so keep its columns; prose inside sections is yours to adapt. ```markdown ## Close plan — / / Go-live required: · Compelling event: Target signature: · Critical path: · Slack: ### Milestones | # | Phase | Milestone | Buyer owner | Our owner | Due | Status | Blocks | |---|---|---|---|---|---|---|---| | 1 | Decision | Technical validation complete | | | | Not started | 2 | | 5 | Paper | Security questionnaire returned | | | | In progress | 7 | | 8 | Paper | PO issued | | | | Not started | — | ### Stakeholder map | Name | Title | Role | Measured on | Stance | Covered by | Next touch | |---|---|---|---|---|---|---| ### Paper path Security review: · Legal review: · Procurement: · PO cutoff: ### Risks | Risk | Milestone at risk | Mitigation | Owner | By | |---|---|---|---|---| ### Agreement Sent to on for correction. Reviewed at every meeting. Re-baselining rule: any close-date change demotes this deal out of Commit until it re-earns the criteria. ``` ## Gotchas - Legal, security, and procurement run on their own queues and are indifferent to your quarter. Ask "are there any fiscal year deadlines that affect when the PO needs to be issued" early ([Weflow](https://www.weflow.ai/blog/meddpicc)), because a PO cutoff two weeks before the buyer's fiscal close silently moves your real signature deadline forward. - A close plan cannot fix a deal that is failing on Champion or Economic Buyer. Deals with weak Paper Process and weak Champion are the ones that slip at quarter-end ([Weflow](https://www.weflow.ai/blog/meddpicc)); if either is unconfirmed, run qualification first and say so rather than producing a plan built on an unverified approver. - Forecast category is a shared language, not a probability. Do not attach 90%/60%/30% confidence figures to milestones; assigning probabilities re-introduces the rep judgment the categories were meant to replace ([ORM-Tech](https://orm-tech.com/blog/sales-forecast-categories-explained/)). Commit entry requires the close date to have not moved in two weeks, the economic buyer confirmed, pricing and terms agreed, and order form or procurement in motion. - Adding your own sales engineer, security lead, and executive sponsor is part of the plan, not overhead. Closed-won deals carry a selling team **67% larger** than lost ones, and enterprise reps who bring a sales engineer into technical discussion see up to **+30%** win-rate lift ([Gong](https://www.gong.io/blog/the-best-sales-insights-of-2025)). Name each internal participant and the milestone they own. - A friendly contact who forwards your plan but never edits it has not agreed to it. Treat an uncorrected plan as unvalidated: buyers who own a step reliably change at least one date, and silence usually means the plan never reached the people who own the steps. - Do not compress the security questionnaire into the final week. It is frequently gated on a SOC 2 report or completed questionnaire being supplied upfront ([Weflow](https://www.weflow.ai/blog/meddpicc)), and it is the item most often discovered late because the champion does not run that process and does not think to mention it. - When the buyer stops responding to plan updates rather than disputing them, the failure is decision risk and not scheduling. Switch to handling-buyer-indecision; re-sending a tighter timeline to a buyer who is afraid of owning the outcome adds pressure to the case where pressure backfires. - Present one recommended path, not a menu of contract shapes and start dates. Late-stage optionality slows signature; the plan should carry a single sequence with named alternates only where the buyer's own process forces a branch.