Most support teams have never actually decided when they answer. They drifted into it. Someone happened to be online at 8am, someone else stayed late one night during an incident, and over months those accidents hardened into an unspoken expectation that the team is "kind of always around." That ambiguity is expensive in both directions: customers don't know when to expect a reply, and agents don't know when they're truly off the clock. Deciding your coverage hours — deliberately, in writing — is one of the highest-leverage policy choices a support operation makes, because every other promise you make, especially your SLA targets, is only real inside the hours you actually staff.

Coverage is a promise, not a schedule

The mistake is treating coverage as a scheduling detail to sort out later. It's the opposite: coverage is the foundation every commitment rests on. A 4-hour first-response target means nothing if half your tickets arrive at 11pm and nobody is there until morning. So the first decision isn't "who works when" — it's "what are we promising, and to whom." Write down your coverage window in the same plain language a customer would read: the days, the hours, and the time zone. Then make sure your SLA clock honors that window by pausing outside it. A breach report that counts overnight hours you never staffed measures a promise you never made.

The honest version of this is uncomfortable and necessary: you cannot offer 24/7 response with a team that works one shift. Pick the coverage you can actually keep, publish it, and let the gap between "covered" and "uncovered" be explicit rather than a quiet hope that nothing breaks at 2am.

Match the window to where tickets actually land

Coverage hours should be drawn from data, not from when your office happens to open. Plot when tickets actually arrive across the week — by hour and by day — using your support metrics. Most teams find their volume has a clear shape: a Monday-morning spike, a midday peak, a long quiet overnight. Your published hours and your staffing should both bend to that curve.

  • Staff the peaks, not the average. A coverage window that looks adequate on average can hide a brutal two-hour spike where the queue blows out. Schedule to the peak load, or the peak is when every customer forms their opinion of you.
  • Decide the edges on purpose. Weekends and holidays are where drift does the most damage. Either you cover them — with a clearly smaller crew and a clearly different promise — or you don't, and you say so. "Reduced weekend coverage; urgent issues only" is a fine policy. Silence is not.
  • Separate the channels. Live chat implies someone is there right now in a way email doesn't. If you can't staff chat during a window, turn it off and route to a form, rather than leaving a widget that promises presence you can't deliver.

On-call is for incidents, not for the queue

The off-hours gap is where on-call comes in — but only for the right kind of work. On-call exists to handle the rare urgent thing that genuinely can't wait until morning: a production outage, a security issue, a payment system down. It is not a way to quietly extend normal queue-answering into the night. Blur that line and you'll burn out the exact people you most need, because "on-call" stops meaning "wake me for emergencies" and starts meaning "work a second shift from your couch."

Three rules keep an on-call rotation humane and effective:

  • Define what qualifies, in writing. An on-call page should fire only for issues that meet a clear severity bar — the same kind of bar your escalation workflow uses during the day. Everything below that bar waits for coverage hours. If the on-call person is being pinged for password resets, your definition is broken.
  • Rotate fairly and predictably. Publish the rotation weeks ahead so people can plan their lives. Keep shifts short enough to be survivable, give people a way to swap, and never let the same person silently absorb every weekend because they're the most senior.
  • Compensate and recover. On-call is real work even when nothing pages. Acknowledge it — with pay, time off, or both — and protect recovery time after a rough night. An agent who handled a 3am incident should not also be expected to clear a full queue at 9am.

Make the off-hours self-serve while you sleep

The best way to shrink the on-call burden is to make sure fewer things need a human at all when the team is offline. The hours you don't staff are exactly when self-service deflection earns its keep: a customer who hits a problem at midnight and finds the answer in a well-structured knowledge base never becomes an after-hours page. Set clear expectations at the seam, too — an auto-reply outside coverage hours that states your real hours and points to self-service does more for trust than a heroic but inconsistent attempt to answer everything instantly.

The honest test

Your coverage policy is working when a customer always knows whether someone is there, an agent always knows whether they're off, and the on-call phone only rings for things that genuinely couldn't wait. If instead customers are guessing, agents are quietly answering tickets at all hours because the team "doesn't really close," and on-call has become a second unpaid shift, you don't have a coverage policy — you have a slow-motion burnout machine wearing the costume of great service. Decide the hours, publish them, staff them, and let the off-hours be off.