What Counts as an After-Hours Call, and How It Is Raised
Tuesday, 23:10, at Acme. Luis is holding the on-call phone for the first time. It is ringing with a number he recognises from the accounts department. It is Dev, who is at home finishing the month-end figures because they are due in the morning. He has locked himself out of his account. "Can you just reset it? It'll take you two minutes." Luis does not know whether this is an on-call call. Nobody has written down what one is. Twenty minutes later, on the factory floor, the night shift's label printer stops. The shift supervisor, Carol, does not ring anyone, because she has always understood that IT closes at six. Of the two problems that night, the one that reached the phone was the one that should not have. The one that should have did not.
An after-hours call is a request that justifies reaching the on-call person outside the desk's published hours. The whole of this article is about the one sentence that defines it and the one route that carries it. Without the sentence, every call is a judgement made by a tired person at eleven at night. The judgement will drift toward yes, because saying no to a colleague on the phone is harder than resetting a password. Without the route, the calls that should arrive do not, and the ones that should not arrive on somebody's personal mobile. This article is part of our After-Hours & On-Call Support series. It sits between the rota that decides who answers and the measuring that decides whether the phone rang for the right things.
It covers the definition, which is business-stopping only, and the three-question test behind it. Then come worked examples from Acme, the single route in and why personal mobiles fail. Next is the ticket logged before anything else or first thing after. The password call at eleven at night and the manager who calls on behalf of a team follow. Then it covers what service-level targets on a business-hours schedule mean for the night, and when the call is an incident. A short war story and the after-hours definition and route to copy come last.
The Definition: Business-Stopping Only
The definition that works for a small desk is one sentence: the after-hours phone is for work that the organisation has scheduled at that hour and that has stopped, where waiting until the desk opens has a cost the organisation would not accept. Everything else is logged for the morning. The sentence is deliberately narrow, because the night is expensive and the phone holder is one person. It is deliberately about the work rather than the person. The moment the definition becomes "important people" it stops being a definition and becomes a list of who is allowed to wake Luis.
Behind the sentence are three questions, asked in order, and a call counts only if all three are yes. First, is this work the organisation scheduled for now? A night shift, a weekend dispatch, a month-end run that finance has timetabled for tonight, a scheduled overnight job: yes. A person who chose to catch up at eleven: no, however sympathetic. Second, has the work stopped, as opposed to slowed or become annoying? A line that cannot print labels has stopped; a line whose printer is slow has not. Third, would waiting until the desk opens cost something the organisation would not accept? A night shift idle for seven hours: yes. A report that will be ten minutes late at nine: no. Three yeses is a call. Anything else is the first ticket of the morning.
The organisation decides what is scheduled, not the caller and not the technician. That decision is written into the definition as a list. At Acme the list is the night production shift, the Saturday dispatch, and the month-end run on the two nights finance names each month. If Dev's month-end work is on that list, his lockout is a call. If finance has not put it there, it is not. In that case, the fix is for finance to put it there, not for Luis to guess. A definition with a list attached can be applied at eleven at night by a person who has just woken up. A definition without one is a debate, and the debate is always lost by the person who is not on the phone.
The person's seniority is not one of the questions. It is worth saying so in the definition, because the first person to test it will be senior. A director locked out of e-mail on a Sunday has not stopped scheduled work. The honest answer is the logging route and the first ticket on Monday, offered politely. The desk has already settled this question for daytime priority in No Shadow SLA: Keeping Priority Honest. The night does not reopen it. If the organisation wants its directors covered at weekends, it adds that to the scheduled list, in writing, and pays for the rota it implies. That is a legitimate decision. It is not one Luis makes at 23:10.
Examples From Acme
The table applies the three questions to a dozen situations from Acme's first quarter of on-call. Acme's lead, Hannah, wrote them up for the team. The "what happens instead" column matters as much as the verdict, because a no with nowhere to go is a no that gets argued with. Every no in the table has a route.
| Situation | Scheduled now? | Stopped? | Cost of waiting? | Verdict | What happens instead |
|---|---|---|---|---|---|
| Night shift's label printer fails; no labels, no dispatch | Yes | Yes | A shift idle | Call | Fixed tonight; ticket logged |
| Night shift supervisor locked out of the production system | Yes | Yes | A shift idle | Call | Identity verified; reset tonight |
| Accounts clerk working late at home, locked out, no scheduled run | No | Yes | Report ten minutes late at nine | Not a call | Logged; first ticket at eight |
| Same clerk, on a month-end night finance has listed | Yes | Yes | Figures late to the board pack | Call | Reset tonight; finance's list did the deciding |
| Director cannot open e-mail on a Sunday | No | Yes | Inconvenience | Not a call | Logged with a courteous reply; first ticket Monday |
| Night shift's second printer is slow; the first one works | Yes | No | Slower, not stopped | Not a call | Logged; fixed in the morning |
| Overnight order import fails; the morning shift has no picks | Yes | Yes | The morning shift idle | Call | Restarted tonight; the recurring cause goes to the review |
| Monitor reports a disk at ninety percent on the file service | Yes | No | None tonight | Not a call | Ticket waits for the morning |
| Monitor reports the production database down | Yes | Yes | A shift idle | Call | Investigated tonight; may become an incident |
| Sales manager wants a laptop set up for a new starter on Monday | No | No | None | Not a call | Logged; the onboarding process |
| Saturday dispatch cannot print delivery notes; drivers waiting | Yes | Yes | Trucks late | Call | Fixed Saturday; ticket logged |
| Whole site cannot reach the network at 06:40, before the day shift | Yes | Yes | The day cannot start | Call, and likely an incident | Secondary brought in; incident declared |
Two things stand out when a desk writes its own version of this table. The number of rows that are calls is small, usually a third or fewer. Almost every call row is about a shift or a service rather than a person. That is the definition doing its work. The rows that are not calls are not refusals. They are the night's traffic being routed to the morning, which is where a desk of three can actually handle it.
The Single Route In
There is one way to reach the on-call person. It is one published number, and it is not anybody's personal mobile. The number reaches whoever holds the phone that week, by forwarding or by the phone itself being handed over. That way, the caller never needs to know whose week it is. The number is published in three places and no more. They are the desk's page on the portal and the wall of every shift office that is on the scheduled list. The third is the automatic reply from the desk's mailbox outside hours. Beside the number, in every one of those places, is the one-sentence definition and the logging route for everything else. The number without the sentence is a help line. The sentence without the number is a policy nobody can act on at midnight.
Personal mobiles fail as a route for a reason that has nothing to do with rudeness. A personal number follows the person, not the rota. Carol has Luis's mobile from the time he fixed the printer in March. She will ring it in October when Luis is on holiday and Hannah is holding the phone. The call then fails, and Carol concludes that IT is unreachable at night. The next time the printer fails she does not ring at all. Every personal number in circulation is a route that will one day lead nowhere. The published number leads to the rota, and the rota always has a name on it. When a technician is rung directly, the reply is short and kind: "I'm not on the phone tonight. The number is on the shift office wall, and it will reach whoever is. I'll make sure they know you've called." Then they text the holder, once, and go back to sleep.
The other routes have to be named so they can be closed. E-mail to the desk's mailbox is a fine way to log a problem for the morning and a terrible way to raise a call. Nobody reads it at night. The auto-reply says so and gives the number. A direct message to a technician in the chat tool is a personal mobile with a different icon. A message to the desk's group chat is read by whoever happens to be awake, which is a rota with no names. The logging route, the form or the mailbox, is the right home for all of them. Suppose a desk's logging route puts the night's messages into the same queue the morning desk reads. Any tool that takes e-mail and web form requests into one queue will do this, including QuerySolv. Such a desk loses nothing by closing the others. The 23:00 e-mail becomes the 08:00 ticket. Nobody was woken and nothing was lost.
The Ticket Logged Before Anything Else, or First Thing After
Every after-hours call becomes a ticket. The ticket is opened before the work starts when that is possible and first thing after when it is not. A two-line ticket takes a minute: who called, what has stopped, the time. The detail goes in as the work goes on, or in the morning, honestly marked as written after the fact. The rule exists for four reasons, and each one on its own would justify it. The ticket is the record of what happened for the person who holds the phone next week. It is the count that the compensation in the previous article is read from. It is the data the measuring article turns into a pattern. And it is the only evidence, later, that the night happened at all.
The temptation not to log is strongest at night and the reasons sound good. The fix took four minutes; the person is tired; it felt like a favour rather than a ticket. But a night call that is not a ticket is a night call that did not happen, as far as the desk, the review and the compensation are concerned. The person who did not log it has given the organisation a free hour and taught the recurring fault that it is invisible. Carol's printer failing every third Tuesday is a pattern only if every third Tuesday is a ticket. The notes that make a ticket useful to the next person are the subject of the ticket notes series. For the night, the minimum is who, what stopped, when it started, what was done, when it was over, and whether it is likely to happen again.
Logging after the fact is honest when it says so. "Call at 23:40, logged 00:20 after the fix" is a true record. The same ticket with the opening time quietly set to 23:40 is not. The difference matters when the month's response times are read. Most tools let the technician write the real call time in the first note while the ticket carries its own creation time. That is the right way round. The ticket does not have to be pretty at one in the morning. It has to exist.
The Password Call at Eleven at Night
The password call is the hardest case because it is the easiest fix, and the three questions settle it in two directions. Dev at home, catching up on figures that are due at nine with no scheduled run behind them, fails the first question. The organisation did not schedule the work. The honest answer is a kind no with a route. "I can't do a reset through the on-call route tonight. It's for work the business has scheduled, and this isn't on the list. If you raise it on the form now it will be the first ticket at eight. If finance has this night listed as a month-end run, tell me and it's a different answer." Dev may be annoyed, and that is allowed. The alternative is a definition that bends for anyone who sounds stressed, which is everyone at eleven at night.
Carol locked out of the production system passes all three questions and is a call. The right response is a reset done properly. That means identity verified at eleven at night exactly as it would be at eleven in the morning. The night is when a desk is most tempted to skip verification. The caller is in a hurry and the holder is half asleep. The night is therefore when an attacker who has learned the number will try. The verification standard lives in Verifying Identity Before You Reset Anything. It does not have a night-time edition. A reset done without it at 23:10 is a security event with a ticket number.
The password call also produces the single most useful morning conversation on the on-call rota. If the night shift is locking itself out often enough to ring the phone, the question is why. The answer is usually a policy that expires passwords on a schedule nobody told the night shift about, or a shift that shares a login it should not. Either way the fix belongs to the day, and the night call is the evidence for it. Luis's job at eleven is the reset. Hannah's job at nine is the pattern.
The Manager Who Calls on Behalf of a Team
A manager ringing to say "none of my shift can log in" is the right caller. The definition should say so, because the impact of a problem is often visible only to the person responsible for the team. The manager becomes the requester on the ticket. The people affected are listed in it by name or by count. The manager is verified like anyone else, since "I'm the night manager" is a claim until it is checked. A call from a manager about a stopped team is often the clearest call the phone will ever get. The three questions answer themselves. A shift is scheduled, it has stopped, and the cost is the shift.
The manager calling on behalf of one person who wants a favour is a different call wearing the same voice. "Can you sort out Dev's password, he's doing the month-end" is still Dev's lockout. The three questions are asked about Dev's work, not about the manager's title. If the month-end night is on the scheduled list, it is a call. If not, the manager gets the same kind no and the same route Dev would have. In that case, suggest that finance list the month-end nights so that next time the answer is yes before anyone rings. The manager is not the test. The work is. The desk's daytime rule reads impact and urgency from the work rather than from who is asking. That rule, in Impact Times Urgency in Practice, holds at night without amendment.
Service-Level Targets on a Business-Hours Schedule
A service-level target is the time the desk promises to respond to or resolve a ticket of a given priority. On most small desks that clock runs on a business-hours schedule. That clock counts only during published hours, so a ticket raised at 23:00 is not one minute late at 23:01. It starts counting at eight. This is the right design, and it is also the reason the after-hours call needs its own promise. The service-level clock does not know about the night. The on-call agreement does. It says the holder answers within an agreed number of minutes and starts work within another. That promise is separate from, and in addition to, the daytime targets. The two are not in conflict. They cover different hours.
The confusion to avoid is trying to make the service-level clock cover the night. That means running it around the calendar or giving after-hours tickets a special priority that starts the clock at midnight. Both produce a stream of tickets that breach overnight for no reason anyone can act on. Both also produce a desk that has learned to ignore breaches. Keep the targets on business hours, and let the after-hours promise live in the agreement and the definition. Many tools, QuerySolv among them, run service-level targets per priority against a business-hours schedule. The right use of that is to let the night's logged tickets sit unbreached until eight. Then they are the first things read. How targets are set and what they mean is in SLA in Plain Words. The night adds nothing to it except the sentence that the on-call promise is a different one.
Tell the requester, because they will not know. A person who raises a ticket at 23:00 and hears nothing until 08:10 has been treated exactly as promised. They will still feel ignored unless the auto-reply told them what would happen. "Your request has been logged and will be picked up when the desk opens at 08:00. If work the business has scheduled for tonight has stopped, ring the after-hours number below." One sentence of expectation at 23:00 saves one annoyed reply at 08:00, which is a good rate.
When the Call Is an Incident
Some calls stop being calls within ten minutes of being answered, because the thing that has stopped is not one printer but the site. A major incident is what the desk calls a failure that stops many people at once and needs more than one person to handle. The holder's job at that point is to recognise it and to say so, out loud, to the secondary. The holder should not spend an hour alone trying to be enough. The signs are in the call: more than one shift, more than one service, a caller who says "nothing works" and means it. The threshold for declaring, and what the first fifteen minutes look like, are in Declaring an Incident and the First Fifteen Minutes. The pair model's secondary exists precisely so that one person is fixing and one is communicating.
The definition should name this. "A call that affects more than one shift or more than one listed service is an incident. The holder calls the secondary and follows the incident routine." It is one line and it saves the holder from the worst decision available at two in the morning. That is to decide that it is probably fine. Communication during the incident, including the first notice to whoever is awake and affected, belongs to The First Notice. The holder does not improvise it at night. They follow the routine the day desk wrote.
Remember: the after-hours phone is for work the organisation scheduled at that hour that has stopped and cannot wait. Calls are judged by a list the organisation wrote, never by who is calling. One published number, one sentence beside it, everything else logged for the morning, and every call a ticket.
A Short War Story: Three Routes In at Pennant Freight
Pennant Freight, a haulage firm with a night dispatch office, had an after-hours number that nobody at the depot used. The dispatch manager, Rob, had the personal mobile of a technician called Sam from a Saturday fix two years earlier. He had rung it ever since. Meanwhile the drivers' supervisor e-mailed the desk mailbox. The warehouse lead posted in a chat group that one technician happened to watch. When Sam left for another job, Rob's route went dead in the same week. On the following Friday night the dispatch system's print service failed at 22:15 with sixty consignments to load. Rob rang Sam's old number four times, e-mailed the desk, and posted in the chat group that nobody was watching. He finally found the published number on a laminated card behind a filing cabinet at 00:40. By then the trucks were two and a half hours behind and the night's loading plan had been redone by hand. The on-call technician, Aisha, answered on the first ring and restarted the service in six minutes. The lead's review counted the cost as two and a half hours of a twelve-person shift and three late deliveries. It found that the published number had not received a single call in two years. Three other routes had been quietly doing its job until, in one week, none of them did. The desk put the number and the one-sentence definition on the dispatch office wall, in the mailbox's night-time auto-reply and on the portal. The desk asked every technician to redirect personal calls to that number. The lesson in the review was one line: a route that depends on a person is a route that leaves with them.
The After-Hours Definition and Route
The sheet below is the one Hannah wrote after Luis's first week. It is the text that goes beside the number everywhere the number appears. The first half is for the people who might call: the sentence, the list, the number, and what to do with everything else. The second half is for the people who answer. It covers the three questions, the ticket rule, the incident line and the reply for the call that is not a call. Fill in the blanks with your own scheduled list and your own number. Keep it to one page, and reprint it whenever the list changes.
AFTER-HOURS DEFINITION AND ROUTE — ONE PAGE
Desk: ______________________ Published hours: ______ to ______, ______________ In force from: ____________
FOR ANYONE WHO MIGHT CALL
The after-hours number is for work the business has scheduled at that hour which has STOPPED
and cannot wait until the desk opens.
Scheduled work covered by this number:
[ ] ____________________________ (shift / service, hours: ______________)
[ ] ____________________________ (shift / service, hours: ______________)
[ ] ____________________________ (shift / service, hours: ______________)
The number: ______________________ It reaches whoever is on call this week. Do not ring technicians directly.
Expect an answer within ____ minutes. If none, ring again; the second ring reaches the backup.
For anything else, outside hours: ______________________ (form / mailbox)
It will be the first thing the desk reads at ______.
FOR THE PERSON ON CALL
The three questions, in order. All three must be yes for a call:
1. Is this work the organisation scheduled for now? (check the list above)
2. Has it stopped, rather than slowed?
3. Would waiting until the desk opens cost something the organisation would not accept?
Every call is a ticket: opened before the work when possible, first thing after when not.
Minimum: who called, what stopped, when, what was done, when it was over, likely to recur?
A ticket written after the fact says so in the first line.
Identity is verified at night exactly as by day. No exceptions for urgency or seniority.
A manager calling for a team is the requester; list the people or the count affected.
If more than one shift or more than one listed service is affected: it is an incident.
Call the secondary: ______________________ Follow the incident routine.
The reply for a call that is not a call:
"This route is for scheduled work that has stopped. Please raise it at ______________________
and it will be the first ticket at ______. If this is on the scheduled list and I have
missed it, tell me now."
Dev raised his lockout on the form at 23:25 and had it reset at 08:04. There was a note from Hannah asking finance whether the month-end nights should go on the list. They went on the list that week. That means the next time Dev is locked out on one of them it is a call. Finance decided that in daylight rather than Luis in the dark. Carol found the number on the shift office wall the following Monday, next to the sentence. She rang it on the Thursday when the printer failed. Luis answered, logged the ticket, and fixed it in nine minutes. The ticket was the third for that printer in two months, which is where the next article begins.
Frequently Asked Questions
The caller insists it is urgent and I think it is not. Who decides?
Should the on-call person answer calls that are not calls at all, or let them go to the logging route?
How do we handle a monitoring alert that arrives at night but does not stop anything?
What if the published number is not answered?
Can a requester's reply to a daytime ticket wake the on-call person?
How often should the scheduled list be reviewed?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
