
An MSP SLA needs a response commitment your desk can support when work arrives unevenly and someone is unavailable. I'd put the proposed promise beside the roster and a busy period from the board. Name who can pick up the work before you sell the response time.
Say you run the model's US example with 700 seats. At its well-run rate of 0.5 tickets per seat per month, that's 350 tickets. Ticket labor and residual monitoring alerts total 309.8 desk hours a month, or 3.20 full-time equivalents of work. The model staffs that desk with 4 technicians.
A full-time equivalent expresses work as a share of a person's productive capacity. It doesn't tell you who's free when a request arrives. A typical MSP runs 1.0 to 1.4 tickets per seat per month, so check your own demand before borrowing the example's staffing.
A service level agreement, or SLA, sets the service commitments you and the client agree to measure. Settle that measurement first. A fast number means little if the client expects an engineer to start work while your report counts an automatic email.
Say What Starts and Stops the Clock
The service lead needs to distinguish an acknowledgement from the response you promise. An acknowledgement confirms arrival. Define the human action that counts as a response, then check that your report records that action.
Keep resolution separate. A fix depends on the fault and the work needed to restore service. Waiting for a vendor can extend the elapsed time without adding the same amount of technician labor.
The model assigns 30 minutes of labor to a ticket resolved at Tier 1 and 120 minutes to one resolved at Tier 3. Those are workload assumptions, not resolution deadlines. Don't copy them into an agreement as promises about elapsed time.
Check the Work Arriving at the Same Time
The example's staffing leaves room for other demands, but that room isn't available evenly through the day. A technician can be working on a valid ticket when the next request lands. Inspect that overlap instead of dividing monthly hours across the roster and declaring the desk covered.
Choose ticket history that includes busy periods and absences as well as ordinary work. Keep the roster for those periods beside the export. If the proposed team differs, mark the difference before using the old response times.
- Service lead: export ticket creation times and the timestamps for the promised human response. Separate automatic acknowledgements.
- Service lead: group arrivals by time of day and day of the week. Inspect bursts alongside the priority and the people available.
- Service lead: compare the spread of response times in each proposed service category. Investigate long waits instead of hiding them in an average.
- Service lead: check leave, sickness, and competing work. Record which delays came from missing cover and which had another cause.
- Service lead: record client additions and routing changes during the period. Check whether that history describes the service you now plan to provide.
Use that record to judge the client's proposed commitment. Don't borrow a percentile from another business to choose the number. The owner and service lead need to agree what performance the client requires and what the desk can support.
Put the Promise Against the Roster
Take the proposed target through a recorded busy period. Name who receives the request and who has the skills to act. If that person is already committed, name the fallback and check their work too.
Repeat the check with a plausible absence and overlapping urgent requests. Include the lead's time coordinating the queue. A capacity calculation that gives the lead uninterrupted engineering time and uninterrupted dispatch time has hired an imaginary colleague.
If the roster cannot cover the work, change the coverage or the proposed commitment. Recheck after a staffing change. Old response times describe the old team; they don't establish what the new roster can deliver.
Give After-Hours Work Its Own Cover
The model assumes 5% of tickets arrive outside business hours and uses an on-call engineer as the default. It assumes 25% of those off-hours tickets need a live engineer. Those assumptions describe staffing work, not when incidents happen or how quickly the engineer will respond.
The service lead needs to name the after-hours work the agreement covers and how the client reaches the on-call person. Check who takes over if that engineer is unavailable or handling another incident. A daytime roster doesn't fill that gap.
Where a vendor or another provider forms part of the response, have the service lead check the handoff. Compare the action the provider promises with the action your client expects. Resolve the gap before the owner approves the commitment.
Write Down What the Team Will Actually Do
The owner needs the staffed service window and its time zone in the agreement. Define the service categories so the client and desk can classify the same request consistently. State the response action being promised and keep any resolution commitment distinct.
Explain how a dependency affects the clock and who handles an unresolved case. Then have the service lead check those terms against the actual workflow. A paused ticket needs the treatment the agreement permits, rather than whatever makes the report look better.
Make the service lead responsible for the performance report and the explanation of missed commitments. Revisit capacity when the client base or roster changes. A new person on payroll still needs the skills and availability to cover the promised work.
Test the Fastest Promise First
Start with the fastest response commitment in the draft. Put it beside the roster and a recorded busy period, then name the engineer who could meet it. Check who takes over when that engineer can't.
Give any uncovered handoff a named owner and resolve it before the client relies on the number. Then keep checking the same response action after the agreement starts. The board needs to show whether the promised work reaches a person who can do it.
mspoutpost.com/articles/msp-sla-set-response-promises-your-team-can-support
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
