The underlying delivery models are covered in the outsourced help desk and outsourced NOC guides; this page adds the off-hours layer that applies to both.
Assign four coverage duties
Assign an owner and service window to each coverage duty:
- Intake - calls and tickets enter through the agreed channels; assign technical work and resolution authority separately.
- Acknowledgement - define whether an automated acknowledgement or human response counts, which queue receives it and when the agreed timer begins.
- Remediation - someone qualified actually works the issue at 2 am, with the access and runbooks to do so.
- Resolution authority - someone may approve the risky fix: the reboot of a production host, the emergency change. Define this authority explicitly and test the escalation path to your authorized person.
Map every promised hour against these duties. State the intake window, technical-work window and approval route in the client service schedule.
How one MSP routes client support (podcast)
In an August 2026 IT Business Podcast interview (external website), Mike Glasman of Vitalpoints IT Services describes outsourcing help desk support from the outset and giving clients account-specific escalation contacts. He says clients learned to use the help desk instead of calling him. The publisher's transcript discusses these choices around 19:45 and 37:40.
Use this as a routing example when writing your own service order. Name the support entry point, the queue owner and the escalation contact for each client, then test what happens when the first receiver is unavailable. Keep the supplier's written commitments beside that process.
Staffed versus on-call
| Dimension | Staffed shift | On-call arrangement |
|---|---|---|
| Who is available | Technicians are already on duty during the purchased window | A designated engineer is reachable for the agreed trigger, potentially while off shift or doing other work |
| Work begins | Requests enter the active shift queue, subject to priority and capacity | A page or contact must reach an accepting engineer, followed by active investigation |
| Task scope | Scheduled monitoring, maintenance or user support can be assigned to the shift | Define which incident types justify a callout and which routine requests wait |
| Capacity | Size the shift for handling time, concurrency, absence cover and escalation | Define simultaneous-callout limits and the fallback when the primary engineer is unavailable |
| Handoff | Transfer open work between outgoing and incoming staffed owners | Define who takes an acknowledged incident when the on-call duty ends |
| Commercial schedule | Identify the staffed hours, included workload and extra capacity charges | Identify availability, callout, time-billed work and any minimum charges |
Google's SRE chapter on being on-call (external website) describes availability during working and nonworking hours and a paging-response agreement with service owners. For an MSP purchase, write the contact trigger, work-start target and accepting owner into your own service schedule.
Example coverage week
- Retained coverage
- 40 hours/week
- Still to assign
- 128 hours/week
A nominal 168-hour example. Plan holidays and daylight-saving changes for the actual week.
Coverage-window worksheet
Build your requirement before pricing it. One row per client promise or internal target:
| Input | Your value | Notes |
|---|---|---|
| Promised window per client tier | e.g. business hours / extended / 24x7 | from your MSAs, not memory |
| Client timezones | list | combine every client's promised hours |
| Your staffing timezone(s) | list | gaps = the requirement |
| DST behavior | both directions | a UTC-fixed window can shift against local promises where daylight saving applies - define how each timezone and change is handled |
| Weekend definition | per client geography | not universal across markets |
| Holiday calendar(s) | per client geography | name the holiday calendar and who maintains it |
| Languages after hours | list | often thinner than daytime; verify separately |
| Expected overnight volume | tickets/alerts per night band | decides staffed vs on-call economics |
| Severity mix overnight | estimate from history | decides authority requirements |
Write a short coverage brief: the hours promised to clients, the hours your own team staffs, and the remaining hours, expected volume, urgency and languages. Use that brief to compare internal staffing, a provider or a hybrid arrangement.
Combine local windows
Example: two clients each need Monday support from 09:00 to 17:00 in their own city: one in London and one in New York. Using Europe/London and America/New_York with the IANA timezone rules (external website), their local promises map to these UTC windows on the dates shown.
| Monday | London window in UTC | New York window in UTC | Combined coverage window | Overlap |
|---|---|---|---|---|
| 19 October 2026 | 08:00 - 16:00 | 13:00 - 21:00 | 08:00 - 21:00: 13 hours | 13:00 - 16:00: 3 hours |
| 26 October 2026 | 09:00 - 17:00 | 13:00 - 21:00 | 09:00 - 21:00: 12 hours | 13:00 - 17:00: 4 hours |
The client clocks change on different weekends, so the gap between these local promises changes. The first date needs 13 hours of coverage even though the two eight-hour promises add to 16 client-hours. During the three-hour overlap both clients can need work at once. Size concurrent capacity from their combined demand, handling time and work-start commitments.
Use a separate dated coverage plan for each local promise, then combine the windows on your roster's common timeline. The planner checks one timezone per plan. Keep both demand streams when planning the overlap, and recheck dates around clock changes and the named holiday calendars.
Severity rules that work at night
Define overnight decisions through observable impact, written authority and a reachable escalation owner:
- Written impact criteria the intake person can apply, plus a technical owner for unclear cases and reassessment.
- Agreed urgent triggers and paging routes for defined security, data-loss and client-specific conditions. State who accepts the page and the fallback if that person is unavailable.
- Authority boundaries: what the overnight team may do alone, what needs your on-call approver, who that approver is, and the backup.
- A decision log for morning review of classification, unnecessary pages and missing runbook steps.
The handoff document
Keep three written records so work has an owner at every shift change:
- Receiving handoff (day to night) - open incidents with state and next action; fragile clients; changes in flight; who is on call. Written, not verbal.
- Overnight log - what happened, what was decided, what waits for morning. The decision log above feeds this.
- Next-shift handoff (night to day) - the morning summary your team reads before clients call: incidents, decisions, items needing daytime follow-up, anything client-visible.
Ask the provider for a sanitized handoff record from a real shift. If one is unavailable, walk through a sample together before accepting the process.
Provider coverage examples
These three providers publish NOC or help desk service hours. Use their stated windows as examples when writing your own schedule.
- 31West: Business-hours, extended, after-hours and 24x7 schedules are advertised. General service terms also mention two days of Diwali unavailability. Obtain the applicable MSP holiday calendar in writing. General service terms / 2026-10-16 (external website) MSP help desk page / 2026-10-15 (external website)
- White Label Service Desk: 24/7/365, overflow and out-of-hours options are described. Source / 2026-10-15 (external website)
- NOC 24/7: After-hours or full 24x7 coverage; the homepage describes three overlapping staffed shifts. Source / 2026-10-15 (external website)
Put your holiday calendar, assigned shifts and handoff ownership in the proposal. Use each linked profile for service context and the directory to build your shortlist.
Calendar cases that need a written answer
| Case | Required agreement |
|---|---|
| Client and provider change clocks on different dates | Named timezone, dated window and overlap owner |
| Client holiday is a normal provider workday | Applicable holiday list and included staffing/charges |
| Provider holiday is a client workday | Substitute coverage and accepted escalation |
| On-call engineer does not accept | Contact timeout and fallback owner |
| Incident survives the morning boundary | Current state, next decision and receiving acceptance |
A staffed shift and an on-call response route are different operating models. Confirm which applies to each window instead of relying on the phrase 24x7. Use the filled handoff example, NOC 24/7's coverage evidence and White Label Service Desk's channel questions to prepare a dated calendar request.
Launch checklist
Before the first covered night:
- Coverage brief written and matched to the contracted window.
- Severity definitions and always-escalate list agreed and tested on paper cases.
- Your on-call approver and backup named, with contact channels that bypass quiet hours settings.
- Access for the overnight team: least privilege, named accounts, tested.
- All three handoff records defined with owners.
- Synthetic incident test scheduled: one P1-class and one routine ticket, injected off-hours, full path timed including your own acknowledgement.
- Morning review routine on the calendar for the first two weeks.
Start only after the test incidents reach the right people, the handoff records name the next action and owner, and the decision log shows how the escalation rules were applied.
FAQ
Is "24x7 support" actually staffed overnight?
Ask whether the required window is staffed, on-call or a mixture. Get the shift and holiday schedule, the on-call activation rule and the accepting escalation owner. Use a timed out-of-hours case in your pilot to check the agreed arrangement.
Should we build after-hours coverage in-house or buy it?
Compare complete internal and provider scenarios using the same coverage, workload and retained-management assumptions. Compare the full staffing floor and quoted minimums as well as ticket volume. Define resolution authority at night for either model.
What should an overnight handoff actually contain?
Keep three written records: a receiving handoff (open incidents, fragile clients, changes in flight), an overnight log with every judgment call, and a morning summary your team reads before clients start calling. A verbal handoff alone is not auditable. Keep all three records in a place the next shift can reach.
Next steps
- Outsourced help desk models - choose the ticket-handling model behind the window.
- Outsourced NOC models - the alert-handling equivalent.
- Define after-hours SLA terms - align the promises with the clocks that measure them.