Use Service Desk Capacity Planning to Protect the Slack

Keep the Monthly Calculation in Its Place

The example uses 0.5 tickets per seat per month for a well-run MSP. A typical MSP runs at 1.0 to 1.4. Use your measured workload before deciding you have the example's spare capacity.

FTE means full-time equivalent: the workload expressed as roles at the productive capacity used in the model. The desk's ticket and residual alert work requires about 3.20 FTE, and whole-person staffing rounds that up to four. That rounding creates the 0.80 FTE gap.

It doesn't create a separate person who can cover every skill or shift. Check who is working when the demand arrives, which work they can handle, and who covers escalation. A monthly average can't settle those questions.

Do Not Count the Utilization Allowance Twice

The model starts with 1,660 available hours per technician per year and uses 70% service utilization. Monthly productive capacity is 1,660 × 0.70 ÷ 12 = about 96.83 hours. Available hours already account for the model's leave and admin assumptions.

For this model example, divide its ticket and alert hours by the staffed available hours: 309.8 ÷ (4 × 1,660 ÷ 12) = about 56%. That doesn't mean the remaining available time is an unassigned project team. The 70% utilization assumption already leaves room outside productive service work; the rounding gap is additional room within the modeled productive capacity.

Put scheduled training and internal work into your assumptions explicitly. If the time is already excluded in availability or utilization, don't deduct the same time again. If the activity is additional to what the plan allowed, reduce the capacity available for the other commitments.

Use the actual absence calendar to check coverage without subtracting the annual leave allowance a second time. The annual calculation describes average capacity. The roster tells the lead whether the desk can cover a particular day.

Reserve the Work the Lead Already Owes

Below the model's dedicated-dispatcher threshold of about 10 desk people, a team lead dispatches from the pool. That work sits inside the pool's slack in the example. The model doesn't add separate dispatch minutes or headcount at this size.

Give dispatch a place on the real schedule. The lead needs time to assign work, deal with blocked tickets, and arrange handoffs. If those duties take more time than your plan allows, record the difference and update the plan before booking something else into the same hours.

Check demand by the periods you actually cover. Use arrivals, labor time, and the timing of escalations rather than only the monthly ticket total. Keep known coverage commitments visible before promising optional work.

Choose Improvement Work the Desk Can Set Down

Once the coverage plan is clear, use some of the remaining room for work that improves delivery. I'd favor a documented repeat problem, a missing procedure, or a tool policy that creates avoidable manual handling. Give the task an owner and a result you can inspect.

Keep the task small enough to hand over or pause safely. Record its current state before the technician returns to the queue. A partially changed production system needs a planned stopping point, not an assumption that the phone will stay quiet.

Use the model's principle of assigning work to the least costly capable resource and automating appropriate routine work. Count the design, testing, and maintenance effort too. A proposal to automate is not removed workload until you check what the finished change actually does.

For training, state the skill the desk needs and who will help the learner use it. Put both people's time in the schedule. Completing training is a useful record, but it doesn't by itself establish that the desk can transfer an escalation without support.

Keep Project Help Separate From Permanent Capacity

A project request needs an explicit agreement with the lead about the work and coverage. Check what happens if the desk needs the technician back. Work with a fixed client appointment or a change that can't pause needs firmer coverage than a task the person can safely set down.

The model puts onboarding on project engineers, outside the support desk. Don't use the desk's spare hours to hide onboarding that the project plan has failed to staff. If you deliberately move work between teams, update both plans and keep its cost visible.

Record any desk assistance against the project and in the desk schedule. Otherwise the project can appear to have free labor while the desk appears to have unexplained lost capacity. Neither report helps you decide whether to repeat the arrangement.

Give the Spare Capacity Named Owners

I'd use this checklist before approving the next block of optional work. Keep it beside the roster so the decision can change when the workload changes.

• The service lead reconciles ticket labor and residual alert work, counting each hour once.
• The person managing the roster checks absences, coverage periods, and the skills needed for the expected work.
• The team lead records dispatch and escalation responsibilities before assigning improvement tasks.
• The task owner records the work, the expected result, and a safe place to pause or hand it over.
• The project owner and service lead agree any borrowed capacity and update both schedules.
• The owner approves any extra commitment that changes the desk's staffing or delivery budget.

Set the conditions for recalling borrowed capacity using your own service obligations and queue behavior. The model supplies no universal reserve percentage or queue cutoff for this decision. Write the conditions in terms the lead can recognize and act on.

Check Whether the Room Is Still There

At the next desk review, compare the planned workload with what actually arrived and the labor it took. Include improvement tasks, training, dispatch, and project help in the right categories. Investigate missing time rather than treating an incomplete record as evidence of spare capacity.

If the board deteriorates, inspect demand, skills, availability, and the commitments you added before declaring that the team needs another person. If an improvement seems to remove work, check that requests are still being captured and resolved. A quieter record can have more than one explanation.

Start with the hours your current desk can supply and the work it already owes. Protect coverage, choose an improvement you can pause safely, and record the result. The spare capacity earns its place when the board can still run while the team gets better at the work.