Capacity Planning - CSM Adoption Playbook
Objective. Give the CSM a runnable onboarding and adoption plan for Capacity Planning: what 'adopted' means for this app, a staged pilot-to-scale rollout with a milestone at each stage, the specific adoption risks and how to counter them, and the success metric and review cadence to watch - all honest about the fact that a plan is a validated requirement, not an executed outcome.
Capacity Planning is adopted when a customer produces a capacity requirement they trust enough to act on - sized from their own validated inputs, with assumptions visible, reviewed on a cadence, and signed off by a named owner. It is NOT adopted because a login exists or a plan was generated once. This playbook stages the rollout from a single pilot queue to the full operation, names the risks that stall this app specifically (placeholder shrinkage, FTE-balance complacency, plan-as-execution confusion), and sets the metric and cadence that tell you adoption is real.
See it in the demo
The adoption goal and what 'adopted' looks like
The outcome you are driving is a capacity requirement the customer can defend and act on in time - not a dashboard they visited once. Adoption here is behavioural, not just entitlement or configuration.
Adopted looks like:
- A named planner owns the plan and its assumptions, and a named approver signs it off (see /#/reviews and /#/users).
- The plan is sized from the customer's own validated inputs - measured handling standards, real shrinkage, real skills - not product defaults.
- The requirement is read by skill and interval, not as a single FTE total, so coverage gaps are seen.
- Forecast accuracy and bias are reviewed so the customer knows how much to trust the number.
- The plan is revisited on a cadence as reality moves, and feeds the downstream hiring and scheduling decisions.
Not adopted: a one-off generated plan on default assumptions, nobody owning it, and the headline FTE balance treated as 'staffing solved'. Honesty line to hold throughout: the app produces a requirement, a projection with error bars - it does not hire, schedule or guarantee an outcome.
Staged rollout - pilot to team to scale
Stage 1 - Pilot (one queue / one work type). Pick a single high-value queue where staffing pain is felt. Validate its six inputs with the customer (volume source, handling standards, shrinkage, skills, service goals, forecast accuracy - see the data-setup reference). Produce one requirement-vs-available view and one what-if scenario.
Milestone: the pilot queue has a requirement the planner believes, built on the customer's own figures, with one gap the headline total hid made visible.
Stage 2 - Team (the full planning scope for one site or client). Extend to all work types and skills in that scope. Stand up balancing by skill and interval (/#/balancing) and a first capacity review with a named approver (/#/reviews).
Milestone: a complete plan for the scope is reviewed and approved by a named owner, with assumptions recorded, and it is handed to scheduling/hiring as the sized requirement.
Stage 3 - Scale (operation-wide, recurring). Roll the review into a standing cadence, track forecast accuracy/bias over several cycles, and connect long-range and hiring plans (/#/headcount, /#/hiringcfg).
Milestone: two or more review cycles completed where the plan changed in response to actuals, and forecast bias is being watched and acted on. This is where adoption becomes a routine, not a project.
The top adoption risks and how to counter them
Risk 1 - Placeholder assumptions treated as real. Shrinkage, handling standards and occupancy caps often start as defaults; every requirement inherits them silently (/#/policies, /#/availability, /#/standards). Counter: make input validation a gate before the first plan is trusted; have the customer confirm each figure is theirs, not a placeholder. Shrinkage is the single biggest distorter - start there.
Risk 2 - FTE-balance complacency. The customer sees a net-balanced total and declares staffing solved. Counter: every review, inspect coverage by skill and interval, not the total. Keep one worked example where a balanced plan hid a peak-skill shortage.
Risk 3 - Plan read as execution. A scenario chosen or a review approved gets treated as hiring or scheduling done. Counter: say the integrity line every time - a scenario is simulated, a plan is a requirement; execution happens in Scheduling and in real hiring, and an achieved service result is proven later, not here.
Risk 4 - Set-once-and-forget. A plan built in onboarding and never revisited. Counter: the review cadence IS the product; a plan with no review loop has not been adopted. Book the recurring review in Stage 2, not Stage 3.
Risk 5 - Forecast trusted blindly. High backtested accuracy read as a guarantee. Counter: review bias as well as accuracy, and flag regime changes (new client, product, event) where past accuracy may not carry.
The success metric to watch and the review cadence
Watch the grounding's candidate measures for this app, in order of signal strength:
- Forecast bias/accuracy by an agreed method - the single biggest driver of plan quality. Is the forecast consistently over or under, measured how, and is the bias narrowing? Confirm the accuracy metric with product.
- Unresolved skill gaps - intervals or skills where required exceeds available and no plan closes them. Trending down means the plan is actually driving action.
- Review cadence - is the plan revisited as reality moves, with a completed review on schedule, not set once.
- Plan approval - does a named owner sign off the plan and its assumptions each cycle.
Cadence: a recurring capacity review (align the interval to the customer's hiring and demand rhythm - confirm with the customer, do not assert a fixed period). Each review: refresh volume and actuals, re-check the six inputs for drift, read coverage by skill and interval, record the approval. Tie this into the CSM operating-routine work (C06) and prove value against the customer's own baseline at the business review (C08), keeping capacity value separate from any cash claim.
Runnable this month with a real account
A concrete 30-day shape you can run with a real account:
- Week 1: pick the pilot queue; validate its six inputs with the customer; record which figures are real and which are still placeholders to fix.
- Week 2: produce the requirement-vs-available view and one what-if scenario; surface one skill/interval gap the total hides.
- Week 3: extend to the full planning scope; run the first capacity review with a named approver; record assumptions and approval.
- Week 4: book the recurring review; set up forecast accuracy/bias tracking; agree the success metric with the customer and write it into the success plan.
Exit criteria for 'onboarded': one approved plan built on validated customer inputs, one gap made visible that the headline total hid, and a recurring review on the calendar with a named owner. Everything deeper (forecasting method changes, model re-engineering, integration setup) escalates to the implementation specialist - do not re-engineer the model in the account.
Interpretation check
Adoption of Capacity Planning is a trusted, owned, reviewed requirement built on the customer's validated inputs - not a login, a one-off generated plan, or a net FTE balance. A plan is a requirement with error bars, not an executed or guaranteed outcome.
In the field
KnackGlobal (RCM, ~6,000 seats): adopting Capacity Planning means sizing the claims-processing headcount ask from validated work drivers and real shrinkage, reviewed on a cadence and read by skill and interval, so the operation can defend hiring to finance and avoid the over/under-staffing that spreadsheet planning bakes in - without claiming the plan itself delivers the staffing or the cash.
Practical task
For a real account, draft the 30-day adoption plan: name the pilot queue and its six inputs to validate, define the milestone for each of the three rollout stages, list the top three adoption risks you expect for this customer with a specific counter each, and state the success metric and review cadence you will agree with the customer. Mark which figures are the customer's real values versus placeholders still to fix.
Self-check
A customer has logged in, generated a plan on default assumptions, and says 'we're using Capacity Planning.' Is it adopted? Why or why not?
No. Adoption requires a requirement built on the customer's own validated inputs, owned and approved, read by skill and interval, and revisited on a cadence. A one-off generated plan on defaults is entitlement plus a single use, not adoption.
What is the milestone that ends the pilot stage?
The pilot queue has a requirement the planner believes, built on the customer's own validated figures, with at least one skill/interval gap surfaced that the headline FTE total had hidden.
Which adoption risk is specific to this app's biggest distorting input, and how do you counter it?
Placeholder assumptions - especially shrinkage - treated as real. Counter by gating the first trusted plan behind input validation, having the customer confirm shrinkage (and standards/occupancy) is their measured figure, not a default.
Which single metric best signals plan quality, and what two things do you read in it?
Forecast bias/accuracy by an agreed method. Read both the accuracy (error size) and the bias (consistent over/under lean), since a biased forecast systematically mis-staffs even at high accuracy. Confirm the metric with product.
Why is the recurring review part of adoption, not an optional extra?
A capacity plan is only as good as its live assumptions; reality moves, so a plan set once and never revisited stops being trustworthy. The review loop is how the plan stays a defensible requirement - without it the app has not been adopted.
Verified vs demo. The screens referenced (overview, balancing, reviews, policies, availability, standards) are demo-shown on seeded data; the customer's real volume source, forecasting method, measured standards, shrinkage and the accuracy metric must be confirmed with product and built from the customer's own baseline. The rollout cadence is a recommended shape to agree with the customer, not a product-enforced schedule.