Capacity Planning: Service levels
Objective. Open the service-levels screen and explain that a service goal is an input the plan is sized to - not an achieved result - and that moving the target moves the required headcount.
This screen holds the service goals (for example a speed-of-answer or completion target) that the capacity requirement is sized against. It matters because the single biggest lever on required FTE, after volume and shrinkage, is the service goal you choose to plan to.
See it in the demo
What this screen answers
A Sales or CSM person opens this when the customer asks 'what service level are we staffing for?' Capacity is never sized in the abstract - it is sized to hit a stated goal (answer speed, completion window, abandonment). This screen is where that goal lives, so the plan's required headcount can be traced back to a target someone chose.
The task
Scope to the relevant client, queue or work type and the planning period, then read the service goal the plan is using. The move that matters is to connect this goal to the requirement on the overview or headcount screens: show that the required-FTE number only means anything relative to this target. Do not invent control names - describe it as 'the service goal set for this scope', which is what the app logic supports.
How to read it
A service level here is an input you plan against, not a result you achieved. Raising the goal (faster answer, tighter window) raises required capacity; lowering it cuts the requirement. The classic misread is to treat the number on screen as current performance - it is not; it is the standard the plan is being held to. Attainment of that goal is measured in Real-Time Adherence and Intraday Management against actuals, not here. Confirm with product and the customer which goal definition matches their contract.
Honest limits
This screen does not prove the goal is being met, nor that it is the right goal - only that the plan is sized to it. The relationship between service goal and required FTE depends on the standards, shrinkage and occupancy assumptions elsewhere in the plan. Confirm the goal definition against the customer's SLA contract before quoting any requirement as defensible.
Interpretation check
A service level on this screen is a target the plan is sized to meet, not a measured result - change the target and the required headcount changes with it.
In the field
A contact-centre or RCM queue (OVO-style): the hiring ask only makes sense once the answer-speed or TAT goal it is sized to is on the table, so finance is approving a number tied to a chosen service target, not a guess.
Practical task
Open the service-levels screen for one scope, note the service goal in plain words, then state the one-line link: 'this requirement is the headcount to hit this goal - change the goal and the number changes.'
Self-check
A customer sees the service-level figure and says 'good, we are hitting 90 percent.' What do you correct?
This is the goal the plan is sized to, not measured attainment. Actual performance against it is read in Real-Time Adherence / Intraday against actuals, not on this planning screen.
Why does the service goal belong next to the headcount requirement?
Required FTE only has meaning relative to a target. Raise the goal and the requirement rises; a headcount number quoted without its service goal is not defensible.
What must you confirm before treating the goal as correct?
That the goal definition (metric and threshold) matches the customer's actual SLA contract - confirm with product and the customer, not the demo default.
Verified vs demo. Screen is live in the demo at /#/service; exact controls and figures are SME-validation-pending.