You want to build a mutual action plan with AI because a deal you like has gone quiet. The demo landed, your champion is enthusiastic, and there is still no date on anything. A mutual action plan fixes that by naming every step between today and a signed contract, who owns each one, and when it happens. Here is the workflow: two prompts run in order that turn the notes you already have into a plan your buyer will agree to, plus the one rule about how you send it that decides whether it works.
What a mutual action plan is, and why most of them die
A mutual action plan is a dated, shared sequence of steps both sides commit to, ending in a signature and a go-live. It is not a timeline you present. It is a document your buyer edits.
Most plans die for one reason: the rep writes the plan from the seller's process instead of the buyer's. A plan that reads demo, proposal, negotiation, signature tells your buyer nothing they need to act on. A plan built from their approval path tells them what they forgot — that security review takes three weeks, that procurement will not open a file without a signed order form, that their current contract auto-renews in forty days.
That is the narrow job worth handing to an assistant. You have already heard the buyer's close path in pieces, across four calls and a dozen emails. You just never wrote it down as steps.
Step one: pull the buyer's close path out of your notes
Gather everything you have on the account — call notes, email threads, CRM activity, the Slack thread where your solutions engineer flagged a data residency question. Paste all of it into one prompt. Messy input is fine here; if your notes need structuring first, the evidence-to-action prompt chain handles that step.
You are helping me build a mutual action plan for a B2B deal. Below are my raw notes from every conversation with this account. Read them and extract ONLY the buyer-side steps required for them to sign and go live. For each step, give me: - the step, in the buyer's own words where I recorded them - who on their side owns it (name and title if I captured it, otherwise UNNAMED) - what has to happen before it can start - the evidence in my notes that this step exists, quoted back to me Then list separately: 1. Steps I have clearly assumed but have no evidence for. 2. Approval gates common in this kind of purchase that my notes never mention: security review, legal redlines, procurement, data privacy, budget sign-off, terminating an existing vendor. 3. The three questions I most need to ask to close the biggest gaps. Do not invent owners, dates, or steps. Where something is missing, say it is missing. MY NOTES: [paste everything here]
What comes back is usually uncomfortable, and that is the point. A deal that feels close often has two evidenced steps and six assumed ones, and the approval gates your notes never mention are usually the reason it went quiet. Read the evidence column closely: if the assistant cannot quote your notes for a step, that step is your guess, not the buyer's plan.
Step two: turn the path into a plan your buyer will co-sign
Run this second prompt in the same conversation, so it works from the verified steps rather than starting over.
Using only the evidenced steps from your last answer, build a mutual action plan as a table with these columns: Step | Owner (their side) | Owner (my side) | Target date | What it makes possible Rules: - Work backwards from this go-live date: [DATE]. If the steps do not fit before it, say so and show me exactly where the plan breaks. - Sequence by dependency, not by my sales stages. Never use the words demo, proposal, negotiation, or closed won. - Write every step as something a named person does, not as a phase. - Mark in bold any step whose owner is UNNAMED, so I know who to chase. - Keep the plan to 12 steps or fewer. If there are more, merge the smallest ones. Then write, in under 120 words, the message I send my champion asking them to correct the plan. It must ask them to change at least one thing, name the step I think is riskiest, and end with a single question.
The bolded UNNAMED rows are your next week of work. A step with a date and no owner is a wish. If you want to see how a prompt like this is put together for your exact role before writing your own, try a free one.
Step three: send it as a question, not a document
This is the rule that decides everything. If you send the plan as a finished attachment, you have sent a seller artifact and your champion will reply "looks good." That is not agreement. That is politeness.
Send it as a draft with a visible mistake you want corrected, in a document they can write in. Ask them to fix the dates you got wrong and add the people you are missing. When a champion changes a date and adds a name, the plan is partly theirs and you have a real mutual action plan. When they change nothing, you have a document and a deal that is still quiet.
Then keep it alive: re-date it after every call and let it be the agenda for the next one. Your champion also has to sell this internally when you are not in the room, so give them the approved customer evidence that answers the questions their CFO will ask.
This chain reuses the same deal file across many prompts, so it rewards an assistant that holds long context well — one reason Claude Fable 5.1 for sales workflows is worth testing on a live deal.
Common mistakes
Writing the plan from your pipeline stages. Your stages describe what you need. The plan has to describe what they need. If the assistant hands back anything resembling your CRM stage names, reject it and re-run step two.
Dates without owners. Every row needs a human name on the buyer's side. "Legal" is not an owner.
Building the plan around one contact. If your champion owns eight of ten steps, you do not have a plan, you have a single point of failure. Use the plan itself as the reason to meet the other owners.
Letting the assistant invent the buyer's process. Models fill gaps with a plausible generic procurement path. That is why step one demands quoted evidence and a separate list of assumptions — keep those two lists apart in your own head, too.
Introducing the plan at the end. A plan produced alongside a contract reads as pressure. The same plan raised right after a successful technical evaluation reads as help.
Treating "looks good" as a commitment. An unedited plan has told you nothing about whether the buyer intends to do any of it.
Frequently asked questions
When should I introduce a mutual action plan in a deal? As soon as the buyer has confirmed they want to solve the problem and has shown you any part of their internal process, which is usually right after a successful technical evaluation. Early enough that the dates are still movable, late enough that you are not asking a stranger to plan a purchase.
What if my buyer refuses to co-sign a mutual action plan? Do not push the artifact. Ask instead for the pieces one at a time: who signs, what review it goes through, how long that review usually takes. A refusal to discuss any dated step is itself the answer about the deal, and better to hear in week two than in the last week of the quarter.
Can AI build a mutual action plan without call notes? It can produce a generic template, which is worth very little, because the value of a plan lives entirely in the buyer-specific gates it names. With no notes, use the second prompt's approval-gate list as a question bank for your next call, then build the plan afterwards.
Deals stall inside the steps nobody wrote down. When your plan comes back with names missing on the security, legal or procurement side, the Account Research and Buyer Intelligence prompts cover the stakeholder mapping that fills them in.