Measuring after-hours ticket volume before adding coverage

Question and scope

This study asks how much work arrives outside the team's normal support hours and how much of it requires action before the next business day. The unit is one ticket, and the population is the tickets created or updated during a declared month. The result is a demand estimate for that month, not a forecast for the year. Freeze the calendar and the definition of normal hours before exporting data.

Include every channel that can create a ticket, including email, chat, phone notes, and the self-service form. Exclude automated alerts that never became human work, but keep them in a separate count so the reader can see the monitoring load. Record the system that produced the timestamp for each ticket. A study that mixes creation time with last-update time will misread the queue.

Define an after-hours ticket

An after-hours ticket is one that a person created outside the published support window in the company's operating time zone. That definition is simple, but it hides two different cases. A user may be working late and logging a non-urgent request, or a customer may be reporting an outage that is actively losing money. The study must separate those cases rather than treating every timestamp as equal.

Record the business calendar, including public holidays and planned closures, before calculating the window. A ticket created on a holiday is after hours even if the clock says nine in the morning. Use one time zone for the primary count and note the regions that fall outside it. If the company supports several time zones, publish a small table instead of forcing every reader to convert in their head.

Build the frame from timestamps

Export the ticket identifier, creation time, first human response time, resolution time, channel, priority, and the service affected. Add a field for whether the ticket was created by a person or by a monitoring tool. Reconcile the total with the monthly ticket count before sampling. Any unexplained difference is a data quality finding and belongs in the report.

Do not use the last-modified timestamp as a proxy for creation. A routine comment can make an old ticket look new and inflate the overnight count. If the system stores times in UTC, convert them with a documented rule rather than a spreadsheet formula that someone may overwrite. Save the converted export with the study so a reviewer can reproduce the frame.

Separate demand from delay

A ticket created at 8 p.m. may not represent evening demand if the user simply waited until the end of the day to report a problem from the morning. Compare the creation time with the first sentence of the request and any earlier message in the thread. Where the request clearly describes an earlier event, record the earlier time as the demand time. Keep both timestamps in the file so the distinction is visible.

Delay also appears on the response side. A ticket created at 11 p.m. and answered at 8 a.m. has a nine-hour wait, but that wait may be acceptable under the published service promise. Do not label every wait as a coverage failure. The report should show the distribution of waits and the business impact of the longest ones, not only an average that hides the tail.

Sample the ambiguous cases

If the export is large, sample tickets from each after-hours bucket and read the request text. Include every ticket that triggered an incident, a customer escalation, or a same-night fix. The sample is not there to produce a precise rate; it is there to test whether the timestamp definition matches the work. Record the reason for each inclusion and exclusion.

Ask the on-call person to review a short list of the most disruptive cases. Their memory can identify a ticket that looks routine in the system but required a late-night call. Treat that memory as a discovery source, then verify it against the call log or the message thread. A recollection that cannot be verified should be reported as context, not as a counted case.

Estimate coverage without overclaiming

Present the after-hours volume as a range, with the assumptions written beside it. Show the number of tickets that needed action before the next business day and the number that could have waited. A small team can then compare the cost of coverage with the cost of delay. Avoid turning a few dramatic examples into a universal staffing rule.

Model two or three coverage options rather than one. An on-call rotation, a shared morning triage, and a part-time evening shift have different costs and different effects on response time. For each option, state which tickets it would actually cover and which would still wait. The decision is about risk and budget, not about the elegance of the schedule.

Report and decide

Lead the report with the count of urgent after-hours tickets, the longest waits, and the services affected. Put the total volume and the channel mix in a small table. Add one sentence about what the data cannot show, such as the work that users did not report at all. End with the specific decision the owner needs to make.

Name the person who can approve the coverage change and the date of the next review. If the answer is to keep the current hours, record that decision and the evidence behind it. A documented decision is better than repeating the same debate after every late-night message. It also gives the next review a baseline to compare against.

Turn the count into a staffing decision

Bring the after-hours count to the person who owns the support budget, not only to the IT team. Show the urgent cases, the services they touched, and the waits that exceeded the published promise. Ask what the business would have paid to avoid the worst two or three of those waits. That question converts a ticket count into a risk conversation that a non-technical owner can join.

Compare the cost of each coverage option with the cost of the current delays. Include the management time needed to run a rota, because an on-call schedule is not free even when the same people cover it. Include the cost of turnover if the team is already stretched. A cheap option that burns out the only engineer is expensive in the next quarter.

Choose one option for a trial period and define what would make it a success. A shorter response time is not enough if the urgent volume does not justify the schedule. Set a review date and a small set of measures, such as urgent tickets answered within two hours and the number of overnight wake-ups. Stop the trial if the measures do not support the cost.

Limits and next use

The study measures recorded tickets, not all after-hours work. Calls that were resolved without a ticket, messages sent to a personal phone, and problems that users simply tolerated are invisible. The result also depends on the accuracy of the calendar and the time zone conversion. State those limits so the reader does not treat the count as a complete demand model.

Repeat the measurement after any coverage change and compare the same months. If the volume looks lower, check whether the new process changed how people report rather than how much work exists. The next study should add one missing source, such as the phone system log. A stable method makes that comparison possible without starting over.

Keep the original export and the report together in the operations folder. A new manager should be able to see the assumption, the calendar, and the cases behind the recommendation without asking the analyst. If the data must be deleted under a retention rule, keep the aggregate and the method note. The decision record is useful long after the ticket details are gone.