A customer maturity model is a staged map of how deeply an account uses your product — typically crawl, walk, run — that a CS team uses to set the right next action for each customer and to time expansion. It is not a health score (health tells you risk right now; maturity tells you how far the account has traveled toward full value) and it is not the same as the customer journey (the journey is the sequence of lifecycle moments; maturity is the depth of adoption within them). The model exists to answer one question for every account in the book: what is the single highest-impact thing this customer should do next?
The crawl / walk / run framework
Define each stage by observable product behavior and an outcome the customer has reached — not by how long they have been a customer. Time is a weak proxy; a six-month account stuck on one feature is less mature than a six-week account using the core workflow daily.
- Crawl — onboarded and live. The customer has completed setup, the primary admin logs in, and at least one core workflow runs successfully. Adoption breadth is one to two features; usage is shallow and admin-driven. The CS job here is time-to-first-value: get the account to its first real outcome, not to feature breadth.
- Walk — adopted in one team. The core workflow is habitual for one team or use case. Weekly active usage is steady, a second feature is in play, and the customer can describe the value in their own words. The CS job is to deepen and document the outcome so it survives a champion change, then find the next team.
- Run — embedded and expanding. Multiple teams or use cases depend on the product, usage is daily across roles, and the account treats it as infrastructure. The CS job flips from adoption to expansion and advocacy: new seats, new modules, multi-year renewal, references.
Calibrating the stage gates
Generic stages are filler. Calibrate each gate to two or three measurable thresholds you can pull from product analytics (Pendo, Amplitude) or your CS platform (Gainsight, Vitally, Planhat). A worked example for a collaboration tool:
| Stage | Breadth (features adopted) | Depth (WAU / licensed seats) | Outcome reached |
|---|---|---|---|
| Crawl | 1-2 of 6 core features | under 20% | first project shipped |
| Walk | 3-4 of 6 | 20-50% | one team uses it weekly |
| Run | 5-6 of 6 | over 50% | 2+ teams, named in their process docs |
Pick thresholds from your own data: take your best-retained, highest-NRR cohort, look at what breadth and depth they hit before they expanded, and set the Run gate just below that. The gates are product-specific — copying another company’s numbers defeats the purpose.
Using maturity to drive expansion
Maturity is a routing rule for plays, not a vanity dashboard. Map each stage to the one play that moves the account forward:
- Crawl accounts get an adoption play, never an upsell. Pitching seats to an account that has not reached first value is how you manufacture churn — they buy more of something they are not yet using, then both renewals fail. Guard: the expansion motion is disabled for any account below the Walk gate.
- Walk accounts get a deepen-and-land-a-second-team play. This is where expansion pipeline is created, not closed — a Walk account that adds a second team is graduating itself to Run.
- Run accounts get the expansion play. Multi-team dependency plus over-50% depth is the strongest expansion signal you have; it correlates with NRR far better than tenure or contract value. Time the upsell conversation to the moment an account crosses the Run gate, not to the renewal calendar.
The compounding benefit: maturity gives RevOps a forecastable expansion pipeline. Count of accounts at the Walk gate this quarter is a leading indicator of expansion-eligible accounts next quarter.
Common pitfalls
- Confusing maturity with health. A Run-stage account can be unhealthy (champion just left) and a Crawl account can be perfectly healthy (on track, just early). Guard: track both, and never let a high maturity stage suppress a churn-risk alert.
- Time-based stages. “90 days = Walk” is not a maturity model; it is a calendar. Guard: every gate is defined by a product threshold or an outcome, never by elapsed time alone.
- Gates with no demotion. Accounts regress — a reorg kills the champion, usage drops. Guard: recompute the stage on the same cadence as health (weekly is typical) so an account that falls below the Walk depth threshold drops back and re-enters the adoption play.
- Upselling Crawl accounts. Covered above; it is the single most expensive mistake the model is designed to prevent.
When the framework breaks down
Three stages are too coarse for products with a long adoption surface (a platform with twenty modules needs sub-stages within Run) and too fine for transactional or single-feature products where “live” is the only meaningful state. Calibrate the number of stages to your adoption surface, not to the crawl/walk/run convention. For usage-based pricing, maturity and revenue move together automatically, so the expansion play is less about a sales motion and more about removing friction from deeper usage.
Related
- NRR vs GRR — the retention metrics maturity is meant to move
- Gainsight — CS platform for scoring and staging accounts
- Vitally — product-usage-driven CS platform
- Pendo — product analytics for calibrating the stage gates