# Customer Success Plan: [Customer name]

> A joint success plan agreed between a customer and its supplier: the
> business outcomes the customer bought the product for, how each one
> is measured, the milestones to get there, the adoption metrics that
> show progress and who does what on both sides. Based on common
> customer success practice. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Write it with the customer, not for them. The customer's sponsor
  should agree the outcomes in section 2 in their own words.
- Start from the onboarding success criteria (`business/client-onboarding`)
  and carry them forward; the success plan covers the whole contract
  term, not only the first 90 days.
- Review progress in every quarterly business review
  (`customer-success/quarterly-business-review`) and refresh the plan
  at least once a year, before the renewal conversation starts.
- Common pitfall: listing product activities ("roll out module B") as
  outcomes. An outcome is a change in the customer's business that the
  sponsor would report to their own management.
-->

## Document control

<!-- Guidance: Both sides keep the same version. Record who signed off on the customer side. -->

| Field | Value |
|---|---|
| Plan ID | [SP-YYYY-NNN] |
| Customer | [Customer name] |
| Contract | [Contract reference], term YYYY-MM-DD to YYYY-MM-DD |
| Version | [1.0] |
| Status | [Draft / Agreed / Under review] |
| Supplier owner | [@csm] |
| Customer owner | [Customer sponsor name, role] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD (next quarterly business review) |
| Classification | [Confidential, shared with customer] |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-04-30 | CSM | First plan agreed at kick-off |

## 1. Customer context

<!-- Guidance: Two short paragraphs: what the customer does, why they bought, and what would make the sponsor look good in a year. Check facts with the account executive's notes. -->

*Example:* Quellmoor Freight (fictional) runs regional road freight
with [12] depots. It bought [Product] to replace spreadsheets for
delivery planning, because late deliveries were costing contract
penalties and planners spent most of Monday rebuilding schedules.

| Item | Value |
|---|---|
| Industry and size | [Industry, employees, regions] |
| Products in use | [Product, edition, number of seats] |
| Strategic priorities this year | [From the customer's own plan or annual report] |
| Why they bought | [Problem in the customer's words] |
| Constraints | [Budget cycle, IT freeze windows, regulation, staffing] |

## 2. Desired outcomes

<!-- Guidance: Two to four outcomes. Each needs a baseline, a target, a date and an agreed data source. If the customer cannot give a baseline, make "measure the baseline" the first milestone. -->

| ID | Outcome | Measure | Baseline | Target | By | Data source |
|---|---|---|---|---|---|---|
| OUT-01 *(Example)* | Fewer late deliveries | Share of deliveries arriving after the agreed slot | 9% | 4% | 2027-06-30 | Customer delivery report |
| OUT-02 *(Example)* | Faster weekly planning | Planner hours to publish the weekly plan | 14 h | 4 h | 2027-03-31 | Customer time log, sampled monthly |
| OUT-03 *(Example)* | One planning system | Depots planning only in [Product] | 0 of 12 | 12 of 12 | 2027-03-31 | Usage report |
| OUT-[NN] | [Outcome] | [Measure] | [Baseline] | [Target] | YYYY-MM-DD | [Source] |

## 3. Milestones

<!-- Guidance: Milestones are the steps that make the outcomes possible. Link each to an outcome and name an owner on each side. Show dependencies on the customer. -->

| ID | Milestone | Supports | Supplier owner | Customer owner | Target date | Status |
|---|---|---|---|---|---|---|
| MS-01 *(Example)* | Baselines confirmed for OUT-01 and OUT-02 | OUT-01, OUT-02 | CSM | Operations manager | 2026-05-29 | Done |
| MS-02 *(Example)* | Pilot at 3 depots live | OUT-03 | Onboarding lead | Depot lead | 2026-07-15 | Done |
| MS-03 *(Example)* | Route rules configured for all depots | OUT-01 | Solutions consultant | Planning lead | 2027-01-31 | On track |
| MS-04 *(Example)* | All 12 depots planning in [Product] | OUT-03 | CSM | Operations manager | 2027-03-31 | On track |
| MS-05 *(Example)* | Six-month outcome review | All | CSM | Sponsor | 2027-06-30 | Not started |

```mermaid
gantt
  title Success plan milestones (Example)
  dateFormat YYYY-MM-DD
  section Measure
  MS-01 Baselines confirmed :done, m1, 2026-05-04, 2026-05-29
  section Roll out
  MS-02 Pilot at 3 depots :done, m2, 2026-06-01, 2026-07-15
  MS-03 Route rules configured :m3, after m2, 2027-01-31
  MS-04 All depots live :m4, after m3, 2027-03-31
  section Review
  MS-05 Outcome review :milestone, m5, 2027-06-30, 0d
```

## 4. Adoption metrics

<!-- Guidance: Adoption metrics are leading indicators: they move before the outcomes do. Choose three to five that the product reports automatically, and set a target per milestone. -->

| ID | Metric | Definition | At kick-off | Target | Review |
|---|---|---|---|---|---|
| AD-01 *(Example)* | Weekly active planners | Planners who publish at least one plan per week, divided by licensed planners | 40% | 85% | Monthly |
| AD-02 *(Example)* | Plans built from route rules | Share of plans generated with rules, not built by hand | 10% | 70% | Monthly |
| AD-03 *(Example)* | Driver app usage | Deliveries confirmed in the app | 55% | 90% | Monthly |
| AD-[NN] | [Metric] | [Definition] | [Value] | [Value] | [Cadence] |

These metrics also feed the account health score
(`customer-success/health-score-model`).

## 5. Roles and responsibilities

<!-- Guidance: A named person on both sides for each role, and a backup. Unnamed customer roles are the commonest cause of stalled plans. -->

| Role | Supplier | Customer | Responsible for |
|---|---|---|---|
| Executive sponsor | [VP customer success] | [Sponsor name] | Outcomes, priorities, escalation |
| Plan owner | [@csm] | [Operations manager] | Plan, milestones, reviews |
| Champion | n/a | [Name] | Internal promotion, user feedback |
| Technical lead | [Solutions consultant] | [IT contact] | Integrations, data, access |
| Support | [Support desk] | [Super users] | How-to questions, incidents |

## 6. Risks and dependencies

<!-- Guidance: Keep only risks that threaten an outcome. Severe risks move to the renewal and churn risk plan. -->

| ID | Risk or dependency | Affects | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|---|
| RSK-01 *(Example)* | Depot leads keep spreadsheets in parallel | OUT-03 | Medium | High | Sponsor message, retire shared spreadsheet on go-live date | Customer operations manager |
| RSK-02 *(Example)* | Telematics feed delayed by customer IT freeze in December | MS-03 | High | Medium | Configure rules on test data first | Solutions consultant |
| RSK-[NN] | [Risk] | [ID] | [L/M/H] | [L/M/H] | [Mitigation] | [Owner] |

## 7. Review cadence

<!-- Guidance: Agree the rhythm once and put the dates in both calendars. -->

| Meeting | Frequency | Attendees | Inputs |
|---|---|---|---|
| Working check-in | Every two weeks | Plan owners | Milestones, adoption metrics |
| Quarterly business review | Quarterly | Sponsors, plan owners | Outcomes, value delivered, roadmap |
| Plan refresh | Yearly, and before renewal | Sponsors | Updated outcomes for the next term |

## 8. Sign-off

<!-- Guidance: A lightweight acknowledgement, not a contract. The success plan does not change the contract terms. -->

| Side | Name | Role | Date |
|---|---|---|---|
| Customer | [Name] | [Sponsor] | YYYY-MM-DD |
| Supplier | [Name] | [CSM] | YYYY-MM-DD |

This plan records shared goals. It does not change the contract,
service levels or prices.

## Standard and licence note

Based on common customer success practice for joint success plans and
outcome-based account management. No standard governs this document.
All text and the fictional Quellmoor Freight example are original.
Template licence: MIT.