The model assumes 5% of tickets arrive outside business hours. Define after hours IT support by the client's agreed operating need and the consequence of waiting, then give the caller a working route to triage. A request arriving late doesn't by itself justify waking an engineer, and a small arrival share doesn't make an urgent problem safe to defer.
I'd write the decision with the client before putting anyone on call. Name the covered work and who can authorize an escalation. The technician should be assessing the problem, not negotiating the service agreement while half awake.
Define the Consequence of Waiting
An emergency rule should say which loss of service needs action outside the normal support window. Use the business activity the client needs to perform and the effect of delay. A server label alone doesn't tell you whether its failure is stopping that activity now.
Check whether a usable alternative exists and whether it is acceptable for the affected work. Don't assume that a workaround acceptable during an office day is adequate for a client's overnight operation. Record the boundary the people delivering support are expected to apply.
For a hypothetical policy, a business-critical function that has stopped during the client's agreed operating period, without an acceptable workaround, would reach live assessment. A routine request with no time-critical dependency could be scheduled for the normal window. These are examples to adapt to the agreement, not universal priority definitions.
Keep suspected security incidents on the agreed incident-reporting and escalation route. Don't require a caller to prove an incident before they can report the concern. The receiving person needs a route for uncertainty as well as an obvious outage.
Write Examples the Caller Can Recognize
Give clients plain examples, including cases that need more information. The purpose is to help someone reach the right support route. It shouldn't turn into a quiz that blocks a caller who doesn't know the technical cause.
| Policy Example | What Triage Establishes | Decision to Record |
|---|---|---|
| A Critical Business Function Has Stopped | Whether the affected activity must operate now and whether an acceptable alternative exists | Apply the agreed emergency route if the consequence of waiting meets it |
| A User Needs a Routine Change | Whether the request has a genuine immediate business dependency | Schedule in the normal window when waiting is acceptable |
| An Alert Arrives Without a Clear Impact | What service it concerns and what the client agreement or runbook requires | Use the defined assessment route instead of assuming every alert is harmless or critical |
| The Caller Cannot Explain the Impact | Who can assess the affected work and what information is missing | Escalate uncertainty through the named route rather than silently deferring |
| A Security Concern Is Reported | Which incident contact and reporting process applies | Follow the agreed incident route without substituting a routine ticket response |
Don't make the word urgent the whole test. An urgent label has excellent attendance and poor judgment. Ask what is affected and what happens if the work waits.
Avoid writing that a failed backup always waits until morning. Its significance depends on the situation and the agreed recovery requirements. The person doing triage needs the relevant runbook and a capable escalation contact, rather than a rule inferred from the alert's subject line.
Put a Working Route Behind the Rule
Tell the client how to request after-hours help, what information to give, and what response commitment their agreement provides. Check whether the advertised channel actually reaches the intended responder. An inbox that nobody watches cannot supply a live response just because the signature says it can.
Define the primary responder and the fallback if that person cannot take the work. Make the receiving person's authority explicit. They need to know which cases they can defer and which require help from the service lead or another capable responder.
Don't call that seamless coverage until you've tested the handoff. Walk a representative request through the actual route, with the client contacts and responders involved. Check who receives it and whether they have the information needed to act.
The model's default is an on-call engineer, rather than assuming a fully staffed overnight desk. That staffing choice still needs a usable escalation path. Publishing a phone number isn't the same as checking that the right person can answer and continue the work.
Tell the Client What Will Happen Next
A deferred request needs an explanation and a recorded next step. Say why the reported impact fits the normal service window and when the next update is due under the agreed process. Give the caller a way to report a material change in impact.
Suggested wording is: 'Based on the activity affected and the alternative you've confirmed, we've recorded this for the normal support window. This is the next update we've agreed. If the impact changes, use this route and tell us what has changed.' Adapt it to the case rather than sending it as an unexplained closure message.
For a live escalation, confirm that the responder has accepted the work. Tell the client who owns the next update and where it will come from. Don't promise a restoration time merely because someone has been paged.
Keep the service and any additional charge clear in the agreement and client explanation. An emergency definition shouldn't conceal a new billing rule. Get the authorized commercial decision made before expecting the on-call engineer to explain it.
Use the Volume Assumptions Correctly
The model separately assumes that 25% of off-hours tickets need a live engineer. That is a planning assumption, not an instruction to reject the other requests until the proportion looks right. Record what your own calls required and plan from that evidence.
For context, the model's 700-seat example produces 350 monthly tickets at a well-run rate of 0.5 tickets per seat; a typical MSP runs 1.0 to 1.4. Applying its 5% off-hours share to 350 gives 17.5 off-hours tickets a month on average. Applying the 25% live share to those gives about 4.4 live call-outs.
Those fractional averages size a planning case. They don't predict the next night or tell you how many incidents occur outside business hours. Tickets arriving after hours and incidents starting after hours are different records.
Count actual live work and deferred requests, with the reason for each decision. If an escalation was missed, review the route and criteria. If routine work repeatedly reaches the live engineer, inspect the client's understanding and the intake path before blaming the technician.
Make the Policy Survive the Handoff
- The account lead checks the client's operating needs and the support commitments in the agreement.
- The service lead writes the triage examples and the route for uncertain cases.
- The roster owner confirms the primary and fallback responders can receive and continue the work.
- The account lead explains the request channel and expectations to the client's authorized contacts.
- The receiving technician records the impact, decision, and accepted owner for the next action.
Use this test when reviewing the handoff: what does this do to the board on Monday morning? The next person should be able to see what happened overnight and which work still needs attention. A note saying someone was called isn't enough to continue the case.
Before publishing the policy, run an ambiguous example through it with the person who will receive the request. Repair the missing authority or contact information that stops them reaching a decision. Then give the client the version your responders can actually carry out.
mspoutpost.com/articles/after-hours-it-support-define-the-emergency-route
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.