Use this as a working guide, not a passive read. Skim the sections, copy the frameworks, then connect the advice to a real role, interview, call, or account you are working on this week.
A mutual action plan is a shared record of the work needed to reach a buying decision and, when appropriate, begin implementation. It becomes mutual when the buyer has reviewed the steps, owners, and dates. A seller's private close checklist is only a draft.
Download the free mutual action plan CSV. The fictional example is a starting point for discussion. Replace the activities with the customer's actual evaluation process; do not present its dates as an agreed commitment.
Start with the decision the buyer needs to make
Write the business question at the top of the plan. For a fictional support team, it could be “Can this workflow reduce handoff rework without creating extra administration?” The evaluation should produce evidence for that decision, including reasons to stop if the proposed solution does not fit.
Ask who needs to participate, what evidence they need, and how approval works. Do not assume the person attending the demo can approve budget or speak for security, procurement, and implementation teams.
Give each milestone an owner and an output
The template includes milestone, buyer owner, seller owner, target date, dependency, acceptance criteria, status, and next action. Name the person who has agreed to own the work. If the owner is unknown, mark it unconfirmed rather than assigning someone who has not accepted.
A useful milestone ends with an observable output. “Technical review” is vague. “Customer technical lead documents whether the required workflow can be supported and lists unresolved gaps” is easier to review.
Work through a fictional example
Start with a workflow review. The buyer provides a sanitized example of the handoff process, and the seller prepares a relevant demonstration. The output is an agreed list of requirements and open questions.
Next, the buyer's evaluation team tests the priority workflow against agreed criteria. An unresolved requirement becomes a decision or follow-up task, not a green status because a meeting happened.
If the evaluation supports proceeding, the relevant teams review commercial terms and any required security, legal, or procurement steps. Their sequence depends on the customer. Ask about lead times before putting a signature date on the plan.
Finally, confirm implementation ownership and the first operational milestone. Signing an agreement and achieving the customer's intended outcome are different events.
Separate target dates from commitments
A seller's month-end target does not create a customer deadline. Record why each date matters and whether the owner has accepted it. When a dependency slips, review the downstream effect with the people involved.
Use a small status vocabulary: proposed, agreed, in progress, blocked, and complete. “Complete” should mean the acceptance criteria were met. Keep the blocking question visible instead of hiding it in meeting notes.
Send a short review message
Try: “I drafted the steps we discussed so we can check the owners and dependencies. Could you correct anything that does not match your process? The evaluation criteria and timing are proposals until your team confirms them.”
If the buyer does not want a shared document, use their preferred process. The goal is agreement about decisions and responsibilities, not adoption of your template.
Use the plan in a deal review
Ask what has been confirmed, what remains unknown, and which next action resolves the most important uncertainty. Do not treat a completed document as evidence that the buyer has committed to purchase.
Continue with the discovery and deal-execution reading path, or preview the Enterprise Playbook for account planning, stakeholder mapping, and evaluation workflows.
