Capacity Planning - Troubleshooting and Diagnosis
Objective. Equip the CSM to diagnose the common ways a Capacity Planning output looks wrong, disputed or incomplete: the likely causes, the first checks to run, and when to escalate to the implementation specialist - described at app-logic level, with no invented error messages or UI paths.
Most Capacity Planning problems are not bugs; they are input or interpretation issues. A number looks wrong because an assumption is a placeholder; coverage looks fine but service misses because the total hid a skill/interval gap; a customer disputes a figure because they are comparing a requirement to an actual. This module organises the common symptoms, gives the first checks a CSM runs for each, and draws the line where diagnosis stops and the specialist takes over.
See it in the demo
Symptom - 'the numbers look wrong or too high/low'
Likely cause: an input assumption is a default or a stale figure, not the customer's real value. Shrinkage is the usual culprit (it swings the requirement most), followed by handling standards and the volume forecast. A too-high requirement often means shrinkage or standards are inflated; too-low often means a work-type mix or seasonality is missing.
First checks a CSM runs:
- Re-run the six-input validation: volume source and seasonality (/#/demand, /#/sources), standards versus real work mix (/#/standards, /#/drivers), shrinkage versus the customer's measured figure (/#/availability, /#/policies), skills, service goal, forecast bias (/#/fcmodels).
- Check which inputs are still defaults versus confirmed customer figures.
- Confirm the forecast is a projection with error bars, not an actual - a requirement will not match last period's handled volume and should not.
- Read the figure by skill and interval, not just the total.
Escalate when: the inputs are all confirmed correct and the output still looks implausible - that points at the forecasting method or model, which is specialist/product territory, not a CSM fix.
Symptom - 'coverage gaps' (service misses despite a balanced plan)
Likely cause: the plan was read as a net FTE total that nets out balanced while a specific skill is short at peak and long in the trough - the app's core interpretation trap. Or the work-type mix shifted so the required skills changed and the plan was not rebalanced.
First checks:
- Open balancing and read required versus available by skill and interval (/#/balancing) - the headline total is the wrong lens here.
- Check the work-driver mix (/#/drivers) for a shift that moved required skills.
- Confirm skills coverage and currency (/#/skills) - a credential lapse can open a gap without changing headcount.
- Check whether the plan is stale relative to current demand (a plan built on an old forecast can look valid while failing the current requirement).
Escalate when: the skills/credential model itself needs restructuring, or the balancing logic appears not to reflect the customer's real skill groups - do not re-engineer the skills model in-account.
Symptom - 'the customer disputes a figure'
Likely cause: almost always a category confusion - the customer is comparing the plan's requirement to an actual, or treating a simulation as a commitment, or reading a service goal (an input) as an achieved result, or a forecast's backtested accuracy as a guarantee.
First checks:
- Establish which category the disputed figure is: projection (demand), simulation (scenario/what-if), or requirement (FTE). Name it out loud.
- If they compare it to an actual, explain the requirement is sized to a goal under assumptions and will not equal last period's handled volume.
- If they dispute a scenario, confirm it is simulated, not executed, and whether it was promoted to an approved plan (confirm with product).
- Walk the assumptions behind the number - a disputed requirement is usually a disputed assumption (shrinkage, standard, service goal). Settle the assumption and the number follows.
- Keep capacity value separate from any cash figure if the dispute is about savings.
Escalate when: the dispute turns on the forecasting method, the accuracy metric, or a contractual/commercial commitment - route to product or the commercial owner, do not invent a defence.
Symptom - 'data missing, stale, or a source not feeding'
Likely cause: a volume or workforce source has partial coverage or is not current, so the plan is confident about an incomplete picture. A connected source is not the same as validated, current data.
First checks:
- Check the data-sources view for coverage and freshness (/#/sources) - is the source present AND current, and does its scope match the plan's scope?
- Confirm the work-type breakdown matches the customer's real mix (partial coverage often shows as a missing work type).
- Check whether seasonality and known events are reflected (a flat curve may mean an event feed is absent).
- Separate 'no data' from 'data not yet validated' - they are different problems.
Escalate when: the source connection, field mapping, refresh mechanics or integration itself is the issue - that is implementation-specialist work. The CSM confirms coverage and freshness and validates the figures; the specialist fixes the plumbing.
The escalation line and the diagnostic habit
What the CSM owns: input validation (are the six inputs the customer's real figures), interpretation (is the figure being read as the right category and by skill/interval), coverage/freshness confirmation, and category disputes.
What always escalates:
- Forecasting method, model behaviour, or the accuracy metric looking wrong after inputs are confirmed.
- Skills/credential model restructuring or balancing logic that does not reflect real skill groups.
- Source connections, field mappings, refresh/integration mechanics.
- Anything touching security, compliance, data residency or a contractual commitment - never guess.
The diagnostic habit: before calling anything a bug, run the two-question check - 'Is every input the customer's real figure?' and 'Am I reading the right category, by skill and interval?' Most Capacity Planning problems resolve at one of those two questions. No invented error codes or UI paths - describe the symptom at app-logic level and point at the screen area, and where you are unsure, say confirm with product.
Interpretation check
Most Capacity Planning problems are input or interpretation issues, not bugs. Before escalating, confirm every input is the customer's real figure and that the figure is being read as the right category, by skill and interval - that resolves the majority of 'wrong number' and 'coverage gap' cases.
In the field
KnackGlobal (RCM): a leader reports that claims staffing 'should be covered' but a payer-specific denial queue missed SLA at month-end. The diagnosis is not a bug - the plan netted balanced while a specialised skill was short at the peak interval. Reading balancing by skill and interval surfaces it; the fix is a rebalance, and only a genuine skills-model issue would escalate to the specialist.
Practical task
Take a seeded demo plan and stage three faults: an inflated shrinkage, a balanced total hiding a peak-skill gap, and a stale volume source. For each, write the symptom as a customer would report it, the likely cause, the first two checks you would run and the screen area, and whether it resolves at the CSM level or escalates - with the escalation reason.
Self-check
A customer says the required FTE is far too high. What is your first diagnostic move?
Re-run the six-input validation and check which inputs are still defaults - shrinkage first, then handling standards and volume, since an inflated shrinkage or standard is the usual cause of a too-high requirement. Confirm the figures are the customer's real values before suspecting a bug.
Service is missing at peak even though the plan's total is balanced. Where do you look and why?
Open balancing and read required versus available by skill and interval. A balanced net total can hide a scarce skill short at peak and a surplus elsewhere; the total is the wrong lens for a coverage gap.
A customer disputes a capacity figure. What is the most common root cause?
A category confusion - comparing a requirement to an actual, treating a simulation as a commitment, or reading a service goal (an input) as an achieved result. Name the category, then walk the assumptions behind the number.
A data source is connected but the plan looks incomplete. What do you check, and when do you escalate?
Check coverage and freshness on the data-sources view and whether scope and work-type mix match reality - a connected source is not validated, current data. Escalate when the connection, mapping or refresh mechanics themselves are the problem.
Name two things the CSM owns in diagnosis and two that always escalate.
Owns: input validation and interpretation/category disputes (also coverage/freshness confirmation). Escalates: forecasting method/model issues after inputs are confirmed, and source/integration mechanics - plus anything touching security, compliance or contractual commitments.
Verified vs demo. The screens and symptoms are grounded in the demo on seeded data; no error messages or exact UI paths are asserted. The forecasting method, accuracy metric and any integration/source mechanics are confirm-with-product, and the diagnosis is described at app-logic level only.