Capacity Planning - Data and Setup Reference
Objective. Set out exactly what Capacity Planning needs to produce correct numbers: the data and signals it depends on, the setup/config and integrations required (at app-logic level, with specifics confirmed with product), its dependencies on other Time Champ apps, what a CSM validates before trusting the output, and what escalates to the implementation specialist.
Capacity Planning is a computation, and its output is only as good as its inputs. The requirement is built from demand volume, handling standards, shrinkage and occupancy, service goals, skills, and the forecasting model - each of which is a setup choice that can be a validated customer figure or a silent default. This reference lists what the app consumes, what has to be configured, where it depends on other apps, and the validation gate a CSM runs before anyone trusts a plan. Exact sourcing, methods and connectors are 'confirm with product'.
See it in the demo
The data and signals the app depends on
Capacity Planning turns demand into a required capacity, so it consumes, roughly in chain order:
- Demand volume - projected arriving work by period and work type (the volume forecast, /#/demand), plus the work drivers that generate it: mix, rework, backlog (/#/drivers). Volume carries forecast error bars; it is a projection, not actuals.
- Trend, seasonality and events - the patterns and known events that shape the volume curve (/#/trend area).
- Handling / productivity standards - the figures that convert volume into effort (/#/standards). Defaults will be wrong for the customer's work mix.
- Shrinkage and availability - what turns nominal headcount into effective FTE (/#/availability). The single biggest distorter of the requirement.
- Occupancy caps, rounding and other planning-policy defaults - these silently drive every requirement (/#/policies).
- Service levels / goals - the target the plan is sized to (/#/service). Moving the target moves the requirement.
- Skills and credentials - who can do which work, so the plan is skills-in-intervals not a lump (/#/skills).
- Workforce availability and roster - the available-capacity side of the balance.
- The forecasting model and its backtested accuracy/bias (/#/fcmodels).
Every one of these is an assumption the number inherits. None of them is self-evidently correct.
The setup and integrations required
Described at app-logic level (exact connectors, field mappings and methods are confirm with product):
- A volume source - where projected demand comes from (a feeding system, an import, or a modelled forecast). Confirm the source, its coverage and its freshness (/#/sources). A connected source is not the same as validated, current data.
- Standards configuration - the handling/productivity standards per work type, ideally derived from the customer's measured work rather than defaults.
- Shrinkage, occupancy and rounding policy - the planning-policy defaults that apply across the plan (/#/policies).
- Skills and credential model - the definitions of skills, who holds them and their currency (/#/skills).
- Service-goal configuration - the service levels the plan sizes to (/#/service).
- Hiring and training configuration - lead times and ramp curves that drive the hiring plan (/#/hiringcfg).
- Users and approval setup - who can edit and who approves plans (/#/users). Access existing is not governance happening.
Do not re-engineer the forecasting model or build deep integrations in the account - that is specialist work. Validate and confirm; escalate setup.
Dependencies on other Time Champ apps
Capacity Planning sits in the Workforce Management chain and both feeds and is fed by neighbours:
- Standards and workforce reality can be informed by Work Output and Time and Activity - measured handling standards and real utilisation/shrinkage are more credible when grounded in observed work rather than assumed. Confirm with product how, or whether, these feed in for a given customer; at minimum they are the reference the CSM validates standards and shrinkage against.
- Scheduling consumes the plan - the sized requirement (skills-in-intervals) is what Scheduling turns into feasible shifts. A capacity plan is the input to scheduling, not a schedule.
- Real-Time Adherence and Intraday Management operate against the day - they compare and re-forecast actuals versus plan; capacity planning is the longer-horizon sizing behind them.
The honest boundary: Capacity Planning produces a requirement. Execution (scheduling, hiring) and in-day correction live in the neighbouring apps. Whether and how data actually flows between them for a customer is confirm with product - do not assert an integration that has not been verified for that account.
What a CSM validates before trusting the numbers
The validation gate - run this before any plan is presented as trustworthy. These are the six inputs from the app overview, with the check for each:
- Volume - is the demand source correct, and are seasonality and known events reflected? (/#/demand, /#/sources, trend).
- Handling standards and work drivers - are the standards the customer's measured figures, not defaults, and does the work-type mix match reality? (/#/standards, /#/drivers).
- Shrinkage and availability - is shrinkage the customer's real figure, not a placeholder? It swings the requirement heavily (/#/availability, /#/policies).
- Skills - are required skills, coverage and currency defined correctly? (/#/skills).
- Service goals - is the plan sized to the customer's actual service targets? (/#/service).
- Forecast accuracy and bias - how well has the model predicted historically, and does it lean consistently over or under? Backtested fit, not a guarantee (/#/fcmodels).
Validation rule: read the requirement by skill and interval, never trust the headline FTE balance alone. Record which figures are the customer's real values and which remain defaults to fix.
What to escalate to the implementation specialist
A CSM validates and confirms; these go to the implementation specialist or product rather than being configured in the account:
- Volume sourcing and the forecasting method - which method applies, how volume is fed, and the exact accuracy metric. Confirm with product.
- Model changes or re-engineering - do not alter the forecasting model or build the skills/credential model from scratch in-account.
- Deep integration setup - connectors to demand or workforce systems, field mappings, data residency and refresh mechanics.
- Planning-policy architecture - the structural defaults (occupancy, rounding) beyond confirming the customer's figures.
- Anything touching security, compliance or contractual data handling - never guess; route to security/product.
The line to hold: the CSM makes sure the inputs are the customer's real figures and the output is read correctly; the specialist makes sure the plumbing and the model are right.
Interpretation check
A connected source and a generated plan are not the same as validated, current inputs. The requirement inherits every assumption - volume, standards, shrinkage, occupancy, service goal, skills, model - so the number is only trustworthy once each input is confirmed as the customer's real figure and the output is read by skill and interval.
In the field
An OVO-style contact-centre operation: before trusting a capacity requirement, the CSM confirms the demand volume source and seasonality, that handling standards reflect the real contact mix, that shrinkage is the operation's measured figure rather than a default, and that the forecast's historical bias is understood - then reads coverage by skill and interval rather than the quarter's net FTE total.
Practical task
For a sample customer, fill a setup-readiness sheet: list the volume source and its coverage/freshness status, the standards and shrinkage with a real-vs-default flag each, the service goals, the skills model, and the forecast accuracy/bias. Mark each of the six validation inputs pass/fail, note one skill/interval gap the total hides, and separate the items you (CSM) confirm from the items you escalate to the implementation specialist.
Self-check
A customer's data source is connected and the plan generates. Is the output ready to trust?
No. A connected source is not the same as validated, current data, and a generated plan inherits whatever standards, shrinkage and policies were set - often defaults. Run the six-input validation gate and confirm coverage and freshness first.
Which input most distorts the requirement if it is a placeholder, and where is it set?
Shrinkage (with handling standards and volume close behind). It is set via workforce availability and planning policies (/#/availability, /#/policies) and must be confirmed as the customer's real figure.
Capacity Planning depends on and feeds which neighbouring apps, and where is the boundary?
It can be informed by Work Output and Time and Activity for standards and workforce reality (confirm with product), and it feeds Scheduling, which turns the requirement into shifts; RTA and Intraday operate against the day. The boundary: Capacity Planning produces a requirement, not an executed schedule or outcome.
Name two things a CSM validates and two things the CSM escalates instead.
Validate: shrinkage is the customer's real figure; standards match the real work mix (also volume source, skills, service goals, forecast bias). Escalate: the forecasting method/volume sourcing specifics and any model re-engineering, deep integration setup, and anything touching security/compliance.
Why read the requirement by skill and interval rather than the headline total?
A net FTE balance can hide a shortage of a specific skill at peak and a surplus elsewhere. Only skill/interval reading (/#/balancing) shows whether coverage is actually met.
Verified vs demo. The setup screens (sources, standards, availability, policies, skills, service, hiring config, models) are demo-shown on seeded data; the actual volume source, forecasting method, accuracy metric, real standards/shrinkage figures, integration mechanics and any cross-app data flow for a customer must be confirmed with product. Security, compliance and data-residency specifics always escalate.