The Voicify "Competitor A or Competitor B" battlecard library is built around a slot-thesis the rep runs internally — A-slot displacement of an incumbent dental AI vendor or B-slot deployment alongside Voicify — and every internal artifact in the library serves that thesis. The discovery brief captures the hard facts that confirm the slot, the objection map defends the slot, the pricing battlecard prices the slot, and the pilot scorecard proves the slot. But none of those artifacts cross the line into the buyer's organization. The mutual close plan is the artifact that does. It is the one document the AE and the named champion co-build, jointly own, and review together — and it is where the slot-thesis stops being an internal sales framing and starts being a signed timeline.
TL;DR
One page. Co-built with the named champion. Introduced after the pilot reads green and before pricing is sent. Every line item has a named owner and a committed date — line items without both get cut. The plan is slot-typed at construction: A-slot deals require incumbent-offboarding milestones; B-slot deals require Voicify-side integration milestones. The buyer commits in writing to their half of the timeline; the rep commits in writing to theirs. At close, the plan becomes input to the sales-to-CSM handoff. In win-loss debriefs, slipped line items become coaching signals — patterns of slip diagnose where the slot-thesis is breaking under buyer reality.
Why the Battlecard Library Needs a Buyer-Shared Artifact
Every other artifact in the Voicify A-or-B library is rep-side. The pre-call prep template is rep-side. The demo script is rep-side. The forecast call scorecard is rep-side. They all exist to help the rep run a better cycle internally, but none of them are visible to the buyer and none of them carry buyer-side commitments. That asymmetry is fine through discovery and pilot — the buyer does not need to see the rep's working tools — but it becomes the binding constraint in the late stage of the deal. The slot-thesis the rep has been running for sixty days has to translate into a signed contract within a buyer-side window the rep does not control. Legal cycles, security reviews, procurement approvals, and signature flows all live on the buyer's calendar. Without a co-built artifact, the rep is reading the buyer's calendar through inference, and inference is what gets deals slipped out of quarter at the last minute.
The mutual close plan is the artifact that flips the asymmetry. The rep makes their working assumptions visible to the buyer — these are the steps we need to complete by these dates — and the buyer makes their working calendar visible to the rep — these are the steps my side has to complete, and here is who owns each. The buyer signs nothing yet, but the buyer commits to a path, in writing, in front of the named champion. The mutual close plan is not a contract. It is the diagnostic instrument that tells both sides whether a contract is realistic in the timeline both sides claim to want.
When in the Cycle to Introduce It
Timing is the most common failure point with mutual close plans, and the failure is bimodal: too early or too late. The introduction window is narrow — after the pilot scorecard reads green and before pricing is sent. Introducing the plan before the pilot reads green positions it as the rep pushing for close before the buyer has converted from evaluation to intent. The buyer reads the plan as a sales tool and resists it. Introducing the plan after pricing is sent is too late because pricing is the moment procurement enters the deal, and procurement runs its own timeline that supersedes the rep's. The plan written after pricing-sent is a tracking document for the rep, not a commitment device for the buyer.
The pilot-green-to-pricing-sent window is where the rep, the champion, and the procurement function are all aligned enough to co-build a single artifact. The pilot reading green gives the champion internal cover to invest the time. The pricing not yet being sent keeps procurement out of the room so the champion can speak for the buyer's path without procurement's gatekeeping voice. The plan written in that window gets buy-in from the champion, and the champion is the person who carries the plan into the procurement conversation when pricing arrives.
The Six Sections
The plan has six sections. Each is a list, each is one page, and each line item carries a named owner and a committed date. Line items without both get cut at construction time.
| Section | What it contains |
|---|---|
| 1. Success criteria | The three to five outcomes the buyer named during discovery, restated in the buyer's own words and signed off by the named champion as the basis for the buy decision |
| 2. Buyer-side path | Legal review, security review, procurement review, executive approval, and signature — each with a named owner inside the buyer's organization and a committed date |
| 3. Vendor-side path | Final scope document, security questionnaire response, redline turnaround on legal, executive sponsor briefing, and any rep-side commitments captured during discovery — each with a named owner inside the vendor and a committed date |
| 4. Slot-specific milestones | For A-slot: incumbent-vendor termination notice, data export window, incumbent end-of-life date. For B-slot: Voicify-side API access confirmation, named Voicify technical contact, integration test window. The slot drives this section's content |
| 5. Dependencies and blockers | Items where one side's date depends on the other side's prior completion — the IT integration sign-off that cannot happen until legal returns redlines, the executive sign-off that cannot happen until pricing is finalized |
| 6. Decision points | The two or three points where either side can walk — the buyer's go/no-go decision after security review, the vendor's pricing-floor decision after procurement counters — with the date by which the decision will be made |
Six sections, one page, named-owner-plus-committed-date on every line. The discipline is what compresses the plan from a sprawling project document into something the buyer will actually read at the start of every status call. The plan should fit on a single screen at presentation zoom; if it does not, the rep has either confused tracking for planning or has not yet identified the named owners and the plan is not ready to share. A two-page plan dies in week one because nobody reads the second page.
Slot-Typed at Construction
Section four — slot-specific milestones — is the section that makes the plan slot-typed. A generic mutual close plan template that ignores slot fails because the buyer-side commitments that close the deal are different by slot. An A-slot deal does not close until the incumbent is leaving — the buyer has to give termination notice to the existing vendor, plan the data export, and commit to an end-of-life date. The plan that does not list those milestones is letting the buyer hide behind "we are still figuring out the timing with the current vendor" right up to the signature line, and "still figuring out" is exactly what kills A-slot deals in week thirteen. A B-slot deal does not close until the buyer has confirmed that Voicify will not block the integration — the API access has to be confirmed, the technical contact on the Voicify side has to be named, and the integration test window has to be scheduled. The plan that does not list those milestones is letting the buyer slow-walk the integration confirmation until the rep gives up.
The slot decision log drives section four's content at construction. The rep takes the slot status from the log — A or B at the point of plan construction — and uses the corresponding slot-specific template for section four. If the slot flips after the plan is built, section four gets rewritten and the plan is re-shared with the champion. Slot flips post-plan are uncommon (most flips happen earlier in the cycle) but when they happen, the plan rewrites are how the slot-thesis stays coherent through to close.
What the Plan Is Not
The mutual close plan is not a contract, not a statement of work, and not a project plan. It is a one-page commitment device that lives in the late stage of the deal and is retired at signature. Reps who try to make the plan also serve as the statement of work end up with a document that is too detailed to be read on status calls and too operational to be useful as a pre-contract commitment device. The SOW lives in legal review, runs ten to thirty pages, and exists to be redlined. The mutual close plan lives in the rep's email and the champion's email, runs one page, and exists to be marked up with check-marks as line items complete. The two documents serve different functions and confusing them kills both.
The plan is also not a forecast tool. The forecast call scorecard is the rep-side instrument that uses the plan as one input — items slipping on the plan become forecast risk signals — but the plan itself does not exist to feed the forecast. The plan exists to keep the buyer honest about their half of the timeline and to keep the rep honest about theirs. Confusing the plan for a forecast input means the rep updates it as a CRM tracker rather than as a working document with the champion, and once the plan becomes a CRM artifact rather than a champion-shared artifact, the champion stops engaging with it and the plan dies.
Three Failure Modes
First, the rep builds the plan without the champion. The rep writes a sixty-line project plan in a spreadsheet, sends it to the buyer, and asks for sign-off. The champion reads twenty lines, gets overwhelmed, and never engages. The plan is dead before it has been used. The fix is co-building — the first version of the plan is built on a forty-five-minute working call with the champion, the champion names their owners and dates while the rep writes them down, and the artifact that comes out of that call is the working draft. A plan the champion did not help write is a plan the champion will not defend internally.
Second, the rep treats the plan as static. The plan is built, signed-off by the champion, and never updated. Items slip silently, the champion does not mention it, and the rep finds out in week eleven that legal review never started. The fix is a standing fifteen-minute check-in with the champion every Friday — the agenda is the plan, the rep walks the open items, the champion confirms or revises ownership and dates, and the artifact is updated in real time. The cadence is what keeps the plan alive after construction.
Third, the rep does not slot-type section four. The rep uses a generic mutual close plan template, leaves section four as "implementation timeline TBD," and loses the binding leverage the slot-specific milestones provide. The fix is in the battlecard governance SOP: section four templates are maintained by slot, and the rep is required to pick one at plan construction. A plan without slot-typed section four content is rejected at manager coaching review the same way a handoff with a blank field seven is rejected.
How the Plan Feeds Downstream Artifacts
At close-won, the completed mutual close plan becomes input to two downstream artifacts. It feeds sales-to-CSM handoff field eight — the next-step the buyer expects — because the items that slipped or were renegotiated on the plan are exactly the items the buyer will ask the CSM about on the kickoff. It also feeds handoff field nine — open unresolved objections — because objections that came up during the late-stage cycle but did not get fully resolved show up on the plan as deferred decision points, and deferred decision points become deployment-stage friction.
At quarter-end, the plan feeds the win-loss debrief and the quarterly refresh. Patterns across plans become coaching signals: if legal review slips on eighty percent of A-slot deals, the rep is sending paper to legal too late and the discovery brief is where the fix lives. If Voicify-side API access confirmation slips on most B-slot deals, the rep is asking too late and the IT integration due-diligence battlecard is where the fix lives. The plan is a working document in the late stage and a diagnostic document after the deal closes or dies — the field correcting the cluster with what actually happens between pilot-green and signature.