Mutual Action Plan Template for Customer Success Teams

A mutual action plan (MAP) is a shared document that defines exactly what needs to happen, who is responsible for each item, and by when — agreed upon by both the CS team and the customer. The word "mutual" is the important part. This is not a project plan the CSM creates and sends. It is a plan both sides build and own together.

MAPs originated in B2B sales — used during the final stages of a deal to align on implementation timelines. Their use has expanded to customer success, where they serve as the foundation of structured onboarding and the anchor for every conversation about progress and accountability.

Why Mutual Action Plans Reduce Churn

The core mechanism is shared ownership. When a customer helps build the plan — when they see their name next to specific tasks with specific dates — they feel responsible for following through. A plan that arrives from the CSM as a polished document creates no such ownership. The customer is a recipient, not a participant.

MAPs also create a natural escalation mechanism. When a task is overdue, the CSM does not need to chase the client awkwardly. They simply reference the plan: "We agreed that [task] would be complete by [date]. We are now three days past that. What has blocked progress?" The plan does the accountability work.

The Mutual Action Plan Template

A good MAP for B2B SaaS onboarding covers six sections. Here is the template with guidance on what to include in each.

Section 1: Success Outcomes

This captures what the customer is trying to achieve — in their own words, agreed in the kickoff. Not product features. Business outcomes. Example format:

• Primary outcome: Reduce time CSMs spend chasing clients from 3 hours/week to under 30 minutes
• Secondary outcome: Give CS leadership real-time visibility into account health without relying on team reports
• Success metric: Onboarding completion rate above 85% within 60 days of go-live

Section 2: Go-Live Date and Milestones

The go-live date is the anchor. Everything else is backwards from it. Include: contract signing date, target go-live date (agreed on kickoff call), key milestones between signing and go-live, and the first value milestone date.

Section 3: Task Table

The heart of the MAP. A clear table with task description, owner (a specific person — not just "client"), due date, status, and blocker notes if applicable.

Section 4: Escalation Path

Agreed in advance — who to contact if a task is blocked for more than 48 hours. On the vendor side: CSM to CS Manager to VP CS. On the client side: project lead to IT contact to executive sponsor. Having this agreed upfront means escalation happens without awkwardness.

Section 5: Communication Cadence

How will you communicate during onboarding? Weekly check-in call? Async updates only? What constitutes an emergency that warrants a same-day response? Agreed upfront, documented in the MAP.

Section 6: Completion Criteria

How will both sides know when onboarding is complete? Define the specific conditions: all tasks marked complete and client-verified, go-live date reached, first value milestone achieved, and 30-day review scheduled. When all conditions are met, both sides sign off on onboarding completion.

How to Run the MAP in Practice

A MAP is only useful if it is a living document — updated regularly and referenced in every customer conversation. Review it at every touchpoint. Walk through the status of each item, update completion, note any new blockers. When tasks are overdue, reference the plan by date: "We had agreed this would be complete by the 15th. We are now on the 19th. Can we talk about what has blocked this?"

The MAP does the accountability work — the CSM is simply reading from it. For the broader onboarding structure that the MAP lives inside, see our complete SaaS onboarding checklist. And for the practices that make MAP execution most effective, our onboarding best practices guide covers the full picture.

MAP vs Onboarding Plan: What Is the Difference?

An onboarding plan is typically CSM-owned — it represents what the CS team is going to do for the customer. A mutual action plan is jointly owned — it represents what both sides have committed to do together. The difference is not just semantic. Jointly owned plans have higher completion rates because both parties feel accountable to something they helped create.

In practice, many CS teams merge the two: they have an internal onboarding plan with detailed task logic, and a client-facing MAP that shows what both sides own. For handling the blocked tasks that often appear inside MAPs, read our specific guide on how to handle blocked tasks in customer onboarding.