Home › Topics › After-Hours & On-Call Support › Measuring It

Measuring and Reducing the After-Hours Load, Month by Month

Monday, 09:30, at Fenwick Timber. The managing director stops at the desk on his way past and asks Marta, who runs it, a question. He has clearly been meaning to ask it for a while: "How bad is the on-call, actually?" Marta says "bad-ish", which is the honest answer, because she has feelings about it and no numbers. Owen had three calls last week and looks it. Sunil says the phone hardly rings on his weeks. Both are telling the truth, and neither of them is describing the rota. They are describing their own weeks, which is all anyone on a rota can see. The managing director says "let me know", and Marta realises she cannot, yet.

The after-hours load is the count, length and timing of the calls the phone takes, and what those calls do to the people who answer them. Measuring it is not a new system; it is reading the tickets the previous article insisted on, once a month, with five questions. Reducing it is the part that makes the measuring worth doing. Most night calls are caused by a small number of things that break repeatedly. A thing that breaks repeatedly at two in the morning can usually be fixed, once, in daylight. This article is part of our After-Hours & On-Call Support series. And it is the one that turns the rota from something the desk endures into something it manages.

It covers the on-call log, which is the tickets, then calls per month and what the number means. Next come the time-of-day pattern, with a worked example, and the recurring cause. It covers the proactive fix that removes a whole class of night call, then the calls that should not have come. Next come the rota-fatigue signal, the monthly review and what it produces, and reporting it upward. It finishes with a short war story and the on-call log and monthly review to copy, in that order.

The On-Call Log Is the Tickets

The on-call log is the set of tickets that were after-hours calls, plus the Monday handover notes. And it is not a separate spreadsheet that a tired person is expected to keep. Every call became a ticket at the time or first thing after, as What Counts as an After-Hours Call requires. And the log is simply those tickets found and read together. The only thing the desk has to add is a way to find them: a source or a tag that says "after-hours call". Set it on the ticket when it is opened. That makes the month's calls a filter rather than a search through everything that happened at odd hours. A ticket raised at 23:00 through the form is not a call; a ticket opened by the holder because the phone rang is. The tag tells them apart.

Each call ticket needs a handful of fields filled in for the review to work. And the list is short enough to put on the on-call sheet. Who called and from which shift or service. What stopped. The time the call came in, which may be earlier than the ticket's creation time and is written in the first note if so. What was done. When it was over. Whether it is likely to recur, in the holder's honest opinion at the time. And the holder's name, which the tool supplies. Everything else about the night can be reconstructed from those seven things, and nothing about it can be reconstructed without them.

The review reads the tickets as data, which means it needs them exported or reported, not opened one by one. Most tools can list tickets by tag and date range with their opened, claimed and resolved times, and that list is the log. If you run QuerySolv, the after-hours calls are ordinary tickets in the same queue as everything else, each with its complete event history. So the month's count and hours are read from the same place the day desk's numbers come from, without anyone keeping a second sheet. Where the tool will not report it, an export to a spreadsheet with a column per field does the job. The arithmetic below is simple enough to do by hand on a desk that takes a dozen calls a month.

Calls per Month

The first number is the count of calls in the month. It answers the managing director's question in one line once there are a few months of it. Fenwick Timber's first six months, read from the tagged tickets, were nine, seven, eleven, six, eight and six: forty-seven calls, a little under eight a month, on a three-person pair rota. The count is read as a trend rather than a month, because a month is small and lumpy. The method for not fooling yourself with small counts is the same as for daytime volume, in Trends and Seasonality. Six months is enough to see whether the line is flat, rising or falling. One month is a weather report.

Beside the count go two others: the hours of night work, from the call lengths, and the number of calls per person on the rota. The latter is the count divided by the people who held the phone that month. Forty-seven calls that took about thirty-five hours between them, spread over three people, is a load each person can picture. That is a little over two and a half calls and about two hours of night work in each of their on-call weeks, on average. The averages hide Owen's three-call week and Sunil's silent one. The per-person figure is a description of the rota's weight, not a league table. The section on fatigue below says more about how to read it without turning it into one.

The count is not a target and should not be given one. A desk that is told to get night calls under five a month will get them under five a month, by the simple method of not logging the sixth. The count is an instrument. Its job is to tell you which of the sections below to read first. And a rising count is not a failure of the rota. It is the phone pointing at something, and the rest of the review is finding out what.

The Time-of-Day Pattern

The second cut is by the hour the call came in, grouped into bands. And this one usually tells the desk something it did not know. Calls cluster, and where they cluster says what causes them. Calls in the first two hours after the desk closes are mostly a shift that starts before the desk has gone. That shift is left without cover by the handover gap. Calls in the small hours are mostly scheduled jobs: backups, imports, batch runs. These are the things the business set to run at two because nobody would be using the system. That is also why nobody notices when they fail until the phone does. Calls in the two hours before the desk opens are mostly an early shift arriving to find something broken overnight that nobody saw. The table is Fenwick's forty-seven calls in bands, with what each band pointed to and the question it raised.

BandCalls in six monthsWhat they turned out to beWhat the band usually meansThe question it raises
17:30 to 20:0012The late shift's first two hours: a printer, a lockout, the planer line's terminalA shift starts before the desk closes and nobody covers the overlapCould one technician start and finish an hour later on late-shift days?
20:00 to midnight7A mix; no patternOrdinary failures during a working shiftIs each one a one-off or a cause on the list below?
Midnight to 04:0019Fourteen were the kiln-control job failing and needing a restart; three the backup; two unrelatedScheduled jobs that fail and page a human to press a buttonWhy does the job fail, and could it restart itself or fail at a better hour?
04:00 to 06:003The kiln job again, lateJobs running longSame question as above
06:00 to 08:006The early shift finding the overnight failure, or a terminal that would not startThe desk opens later than the first shiftCould the desk open at seven on early-shift days?

Read like this, the forty-seven calls are not forty-seven problems. They are about three: a shift the desk's hours do not quite cover at either end, one scheduled job that fails most weeks, and a handful of genuine one-offs. The hours question is the cheapest to ask and the most delicate to answer. Moving a technician's start and finish touches their contract and their life. Where contracts and the people allow it, a staggered day on shift days removes more night calls than any technical fix. Where they do not, the answer is to accept those bands as the cost of the shift and to make sure the rota rules and compensation reflect it. The small-hours band is the one that is almost always fixable, and the next two sections are about it.

The Recurring Cause

The third cut is by cause, and it is the one that pays for the review. Group the month's calls by what actually failed, not by what the caller said, and count the groups. At Fenwick the kiln-control job alone was seventeen of forty-seven calls in six months, more than a third of the night work. Each one had been fixed in about ten minutes by restarting it, which is why nobody had thought of it as a problem. It was a nuisance seventeen times. Nobody had added the nuisances up, because each holder saw only their own week's one or two. A thing that happens to you once a fortnight does not feel like a pattern. It feels like Tuesday.

The rule that catches it is written on the review sheet. Any cause that rings the phone twice in a month, or three times in a quarter, gets a problem record. That is the desk's name for a ticket about the cause rather than the symptom. The hunt for repeats in daytime tickets is the subject of Finding the Repeat Tickets. And the systematic version across devices, applications and groups is in Finding Hotspots in the Ticket Data. The night version is the same method with a smaller pile and a stronger incentive, because every repeat in the night pile cost someone sleep. The problem record names an owner and a date, goes on the day desk's list, and is read at the next review. A night cause with a problem record is on its way out. A night cause without one is on its way back.

The Proactive Fix That Removes a Class of Night Call

A proactive fix is work done in daylight so that a class of failure stops happening at night. And the arithmetic for whether it is worth doing is nearly always embarrassing. Fenwick's kiln-control job failed because its connection to the database timed out when the nightly backup ran at the same time. The fix was to move the job's start by forty minutes and to give it a retry. That took Sunil about three hours on a Wednesday afternoon. Against that, seventeen calls of around forty minutes each, eleven hours of night work, seventeen protected mornings for the day desk to cover, and the slow erosion of three people's willingness to hold the phone. Three hours of afternoon against eleven hours of night and seventeen mornings. The job did not fail again that year.

The classes of night call that yield to a proactive fix are the ones that announce themselves in the small-hours band. A job that fails when it collides with another job gets rescheduled. A job that fails and waits for a human to restart it gets a retry, so that the human is only called when the retry has failed too. A disk that fills overnight gets the sweep in Disk-Space Sweeps and a threshold alert that arrives in the afternoon rather than at three. A certificate that expires on a Saturday gets a calendar entry two months before. A printer that fails every third week on the night shift gets a spare in the shift office and a label saying how to swap it. That way, the shift fixes itself and the ticket is raised in the morning. The idea and its limits are in Fixing Before the Ticket. The night is where the idea has the clearest return, because the ticket it prevents is the most expensive kind the desk has.

Put the arithmetic in the review in hours, as a worked example from your own log, and never as a benchmark. "Fourteen calls, nine hours of night work and fourteen protected mornings in six months, against three hours to fix" is a sentence a managing director understands at once. It is the sentence that gets the Wednesday afternoon protected for the work. The measure of the fix is the next six months' band table, where the small-hours row should be mostly empty. Nothing on a help desk is as satisfying as an empty row that used to be full.

The Calls That Should Not Have Come

The fourth cut is the calls that failed the three-question test and reached the phone anyway, which the holder logged as one-line redirected tickets as the definition asks. Their count is a measure of how well the definition is published and how well it is holding. And their callers are a list of conversations for the lead to have in daylight. Three redirected calls from the same manager in a month means the manager has not seen the sheet, or has seen it and disagrees. Either is fixed by a visit rather than by the holder saying no a fourth time. A rising count of redirected calls after a quiet period usually means a new shift or a new manager who was never told the route.

The redirected calls also test the list itself. If the same not-on-the-list work keeps stopping and keeps ringing, the honest question is whether it should be on the list. That is decided by whoever owns it, in daylight, with the rota cost understood. Fenwick's late shift was not on the original list because nobody had thought of the planer line's terminal as something that would stop a shift. After three redirected calls in two months it went on, and the holders stopped having to decide. The list is a living document, and the redirected-call count is how it learns.

The Rota-Fatigue Signal

The fifth cut is about the people, and it is read from the same log with care. Rota fatigue is the point at which holding the phone has stopped being a duty people accept and started being one they endure. It shows in the data before anyone says it aloud. Swaps rise, and change from single nights to whole weeks. Calls are answered later, because the phone is being left in another room. Time back is logged as owed and not as taken. Sickness lands on or just after on-call weeks more than elsewhere. And one person's weeks are consistently louder than everyone else's. That is sometimes chance and sometimes the rota landing their turn on the month-end run every time. A rota that was built holidays-first should have caught that repeated month-end assignment.

Per-person numbers are read for coaching and for fixing the rota, never for ranking, and never from a sample too small to mean anything. Three people over six months is about eight on-call weeks each. The difference between Owen's twenty calls and Sunil's eleven over that span is a fact about which weeks fell on the kiln job's bad fortnights. It is not a fact about Owen or Sunil. The lead's question on seeing the difference is "why were Owen's weeks louder?" And the answer goes into the rota rules, not into a conversation about performance. The desk's wider discipline for reading load without turning the numbers into surveillance is in Measuring Load Without Surveillance, and the on-call figures follow it exactly. A technician who learns that the night count is being read as a score will stop logging the nights. Then you will have a lovely number and no idea what is happening.

When the fatigue signal shows, the responses are the ones already written into the rota rules and the agreement. Those are the lighter week after a bad one, the time back actually scheduled, and the protected morning actually taken. If the count has grown past what the model was designed for, there is a conversation about the model itself. That may mean more people on the rota or a narrower list. The compensation principles in Compensation and Recovery Time are what the review checks against. Did the hours come back? Were the mornings protected? Is the frequency people lived the one the agreement assumed? A review that reads the calls and never reads the people has measured the phone and missed the point of measuring it.

The Monthly Review

The monthly on-call review is a fifteen- to twenty-minute meeting of the people on the rota, held in the first week of the month. The five cuts are read from the log, and each produces at most one action. The meeting is short because the log has already done the work. And it is attended by the rota members because they are the people the numbers describe and the people who know what the small-hours calls actually were. The lead brings the log in the five cuts; the holders bring what the tickets do not say. The review is not a post-mortem of anyone's week. It is the desk reading its own night.

Each cut has an output, and the sheet at the end of this article names them. The count and the trend produce a line for the monthly report. The band table produces, at most, one question about hours or one job to look at. The cause table produces a problem record for anything that rang twice. The redirected calls produce a conversation and perhaps a change to the list. The fatigue signal produces a rota adjustment, a scheduled piece of time back, or a note that nothing is needed. That last one is also an output and should be said aloud. A review that ends with six actions has over-reached; one that ends with one or two, done, has earned the twenty minutes.

Remember: every call is a tagged ticket, and once a month the rota members read them in five cuts. Those are the count, the hour, the cause, the calls that should not have come, and the people. Any cause that rings twice gets a problem record. Any class of call that a daylight fix would remove gets the fix, with the arithmetic in hours.

Reporting It Upward

The managing director's question gets a one-line answer in the monthly report. And the line is the same shape every month so the trend reads itself. It gives the count, the hours, the top cause and what is being done about it. "Eight after-hours calls in the month, about six hours of night work, five of them the kiln-control job, which is being rescheduled this week." Beside it, when there is one, goes the arithmetic from the proactive fix, in hours, because that is the sentence that buys the next fix. The report's format and the discipline of saying one true thing per line are in The Monthly Report They Will Actually Read. The on-call line is one of its shortest and, in my experience, the one leadership reads first.

When the review shows the load has outgrown the model, the report is where the case is made. It is made with the same log: the count over a year, the hours, the causes that were fixed and the ones that cannot be. It includes the frequency people lived and the fatigue signals, with the honest statement that three people cannot carry what the log shows. A request for a fourth person on the rota that arrives with twelve months of tagged tickets is a request with evidence. The same request made with "bad-ish" is a feeling, and leadership, reasonably, funds evidence.

A Short War Story: The Button at Kestrel Payroll

Kestrel Payroll's desk of three ran a rota for a client payroll system whose nightly calculation run failed, on average, once a week for eight months. Each failure came at around 02:00 and was fixed in under ten minutes by whoever held the phone restarting it. The three technicians came to describe this as "pressing the button". Nobody counted the button presses, because each holder saw only two or three a month. A ten-minute fix did not feel like a problem worth a ticket, so about half of them were never logged at all. Ruth, the most senior of the three, began swapping out of her weeks in the spring. She said in a one-to-one in the summer that she was sleeping badly and was thinking about whether the job was right for her. Her lead pulled every ticket and every phone record for the eight months and counted thirty-four night calls, twenty-nine of them the button. The lead asked the vendor's engineer why the run failed. The engineer found in an afternoon that the run's database timeout was shorter than the nightly backup's lock, and changed one setting. The run did not fail again. The lead's review put the cost at twenty-nine nights' sleep across three people, around twenty hours of night work. The cost also included a senior technician who had come within a month of resigning over a number nobody had added up. Against that was an afternoon of a vendor engineer's time that could have been bought in the first month. Count the button presses, the review said, because the cause that is fixed in ten minutes every week is the one that never gets fixed at all.

The On-Call Log and Monthly Review

The sheet below is the one Marta uses at Fenwick Timber, and it is in two halves. The first half is the log. It lists the fields every call ticket carries. The log is really a reminder for the holder at one in the morning. The second half is the review: the five cuts, each with its one allowed output. It also has the line for the monthly report at the end. Run it in the first week of each month with the rota members present, and keep each completed sheet. Read the last six together once a year when the agreement and the model are reviewed.

ON-CALL LOG AND MONTHLY REVIEW — ONE PAGE
Desk: ______________________   Month: ____________   Rota members present: ______________________

PART 1 — THE LOG (every call is a ticket, tagged "after-hours call", with these fields)
   Who called and which shift or service: __________________________________
   What stopped: ______________________________________________________________
   Time the call came in (in the first note if earlier than the ticket): ______
   What was done: _____________________________________________________________
   Time it was over: ______        Holder: ______________
   Likely to recur?  yes / no / unsure     Redirected (not a call)?  yes / no
   Monday handover note written?  yes / no

PART 2 — THE REVIEW (five cuts, one output each)
   1. THE COUNT
      Calls this month: ____   Hours of night work: ____   Per person on the rota: ____
      Trend over the last six months: ____ ____ ____ ____ ____ ____   rising / flat / falling
      Output: the line for the monthly report (below).

   2. THE HOUR
      Desk close to +2h: ____   Evening: ____   Midnight to 04:00: ____   04:00 to 06:00: ____   Before open: ____
      Output (at most one): a question about hours ______________ or a job to look at ______________

   3. THE CAUSE
      Causes with two or more calls this month, or three this quarter:
        ____________________  calls: ____   problem record: ______   owner: ______________   by: ________
        ____________________  calls: ____   problem record: ______   owner: ______________   by: ________
      Fix arithmetic, in hours: calls prevented ____ x average length ____ = ____ h, plus ____ protected
      mornings, against ____ h to fix.

   4. THE CALLS THAT SHOULD NOT HAVE COME
      Redirected calls: ____   From: ______________________
      Output: conversation with ______________ / list change proposed to ______________ / none

   5. THE PEOPLE
      Swaps this month: ____   Whole-week swaps: ____   Time back owed and not yet taken: ____ h
      Protected mornings due: ____  taken: ____   Loudest weeks and why: ______________________
      Output: rota adjustment ______________ / time back scheduled ______________ / nothing needed

   LINE FOR THE MONTHLY REPORT
   "____ after-hours calls, about ____ hours of night work, ____ of them ______________,
    which is being ______________."

   Next review: ____________

Marta answered the managing director eleven days later with one line and a table. They showed eight calls a month on average over six months and about thirty-five hours of night work. More than a third of it was one job, which Sunil had rescheduled the previous Wednesday. The following month there were four calls. The month after that, three, and the small-hours row of the band table was empty for the first time since the rota began. The managing director asked what the desk had changed. Marta said it had counted.

Frequently Asked Questions

We have months of night calls that were never logged. Can we still start?
Start from the next call and accept that the first month's count is the baseline, not the history. If phone records exist, a one-off reconstruction of the last quarter's call times is worth an afternoon, logged honestly as reconstructed. It gives the band table something to show at the first review. Do not try to rebuild causes from memory; the tickets from now on will show the recurring ones within two or three months anyway.
How many months of data before the pattern means anything?
Three months shows the recurring causes, because a cause that rings twice a month will have rung six times. Six months shows the time-of-day pattern and the trend well enough to act on hours or model. A single month is useful only as a line in the report and as a trigger for a problem record where something rang twice. Treat anything else in it as weather.
Should the count include calls the holder redirected because they were not calls?
Log them, tag them as redirected, and report them separately from the count of real calls. They matter for a different reason. They measure how well the definition and route are known, and they name the conversations the lead needs to have. Mixing them into the main count hides both the real load and the definition problem.
What if the recurring cause is something we cannot fix, like a vendor's system?
Then the problem record's owner is the vendor relationship. The review's arithmetic in hours is what goes into the conversation with them and into the next contract discussion. In the meantime, ask whether the symptom can be made to wait. Options are a retry, a different schedule, or an agreed decision that this failure becomes a morning ticket rather than a night call. Not every recurring cause can be removed, but most can be moved out of the small hours.
Is it fair to show per-person call counts to the team?
Show them in the review as a fact about the rota, with the reason for each loud week beside the number, and never as a standing list. The question the numbers answer is whether the rota is landing the hard weeks evenly. And the people on it deserve to see that answer. The moment the numbers are read as a measure of anyone's performance, logging will fall off and the measure will be worthless.
The count has fallen to almost nothing. Do we still need the rota?
Possibly not, and that is the best outcome a review can produce. Re-run the need assessment from the first article in this series with the last year's log as the ticket read. If the count points at the escalation-only model, change at a quarter boundary and announce it as the achievement it is. Keep logging whatever still rings, because the count that fell can rise again when the business adds a shift.

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.