Your SLA is breaching on tickets that arrived outside working hours

Before anyone argues about staffing, pull the last 90 days of first-reply breaches and chart them by hour of arrival, converted into the timezone the schedule is defined in. Overlay the schedule window. If breaches cluster outside that window, the SLA policy is measuring elapsed calendar time and no amount of night cover will fix it. If they cluster inside it, the configuration is right and you have a real gap.

Almost every overnight breach report resolves into 1 of 5 configuration faults, and all 5 are visible in that chart. The distinction that matters throughout is between what the clock was told to measure and when the team was told to work — this page is about the gap between those 2, not about how the timer itself starts and pauses, which is set out in when the first-reply clock starts and pauses.

The chart that settles it, and the one mistake in drawing it

1. Take breached tickets for 1 metric only. Mixing first-reply with resolution breaches produces an unreadable chart: 2 clocks, 2 targets, often 2 policies.
2. Convert created-at into the schedule's timezone. Helpdesks store UTC and reporting tools render the viewer's local zone, so a chart built elsewhere is shifted before you read it.
3. Bucket into 24 hour-of-day bins and 7 day-of-week bins, then divide by arrivals in the same bin. Breach rate per hour, not breach count, or the chart just tells you when customers write.
4. Split by group and by SLA policy. One group with an inherited policy is the commonest cause, and it vanishes the moment you aggregate across the helpdesk.
5. Read the change log for the window. Schedule, policy and holiday-calendar edits are rarely announced and are the fastest explanation for a step change on a date.

Calendar hours and business hours are two different promises

An SLA policy carries at least 3 independent settings: which metric it measures, what target it sets, and whether that target counts elapsed time or only time inside a schedule. The third is a dropdown most teams never revisit, and it converts a reasonable target into an impossible one without changing the number on screen.

A 4-hour first-reply target on business hours means the reply is due 4 working hours after arrival, so a ticket that lands at 22:00 on Friday is due mid-morning Monday. The same target on calendar hours is a promise to answer at 02:00. Both display as 4 hours in the policy list. The only way to tell them apart is to open the policy, or to read the chart above.

Nobody agreed to answer at 2am. Somebody agreed to a four-hour target, and a dropdown quietly decided which four hours those were.

Five places the schedule stops applying to the ticket in front of you

The reassignment row produces the most confusing version of this. A ticket that starts in one group and moves to another may keep the first target, recompute against the second, or pause entirely. If your tickets move between teams routinely, read tickets bouncing between two groups all day first: the ping-pong and the breach are usually the same incident.

Whose timezone is the timer actually in?

There are 4 candidate timezones on any ticket — the requester's, the assigned agent's, the account default, and the schedule's — and only the last is defensible. The schedule encodes when somebody is at a desk, so it is the only clock that can decide whether time should be counting. The account default, worth checking precisely because nobody remembers setting it, is usually whatever the person who created the helpdesk had on their laptop.

• The requester's timezone is a display preference. Using it for the timer makes one target stricter for some regions than others, which nobody intended and nobody can defend in a renewal conversation.
• The agent's timezone changes on reassignment. A clock that depends on who currently holds the ticket can move backwards, and it makes historical breach reports irreproducible.
• Your reporting tool's timezone is a fourth clock nobody counts. A 5-and-a-half-hour gap between an Indian team and a UTC-rendered dashboard moves the whole distribution before anyone reads it.

Daylight saving is an outage you can put in the calendar

Store a schedule against an IANA zone name — the identifiers in the time zone database, of the Asia/Kolkata or Europe/London form — and never against a fixed offset. An offset is correct for part of the year by construction, and the failure it produces is subtle: everything runs exactly 1 hour early or late for several months, which reads as a mild staffing problem rather than a bug.

Two details make this worse than it sounds. Regions that observe daylight saving do not all switch on the same date, so a team supporting several of them gets weeks where the overlap matches neither the before state nor the after. And a team in a zone with no daylight saving — India among them — experiences the shift entirely as their customers' hours moving, which is the version nobody tests. Confirm current transition rules against the time zone database rather than from memory.

The holiday list nobody owns, and what it does to the chart

A missing holiday is indistinguishable from a coverage gap in every report you have: the office is shut, the clock is running, and the breach lands on a day the chart treats as ordinary. The holiday table is almost always maintained by hand, entered once for the year, and forgotten in October.

• Give it an owner and a renewal date. A list that ends on 31 December silently converts January into a full-coverage month.
• Keep 1 list per schedule, not 1 per helpdesk. Multi-site teams observe different days, and in India the gazetted list varies by state, so a single national list is wrong for at least 1 office.
• Reconcile against the payroll or HR calendar once a year. Those lists are maintained for a reason people care about, which is more than the helpdesk's can claim.

Order of work, once the chart has spoken

1. Read the clock type on the breaching policy. It is 1 dropdown and it explains the flat-rate signature outright. Change nothing else until you have looked.
2. Confirm the schedule is attached to the group that owns the tickets, and that the policy's conditions select those tickets. Scoping errors present exactly as coverage gaps.
3. Check which timezone the calculation reads, then which one your chart rendered in. Fixing the second alone gives you a chart that agrees with a policy that is still wrong.
4. Look for a 1-hour shift in the historical series at the daylight-saving boundaries, and diff the holiday list against the real calendar. Every unexplained spike should land on a day nobody was at work.
5. Only then discuss staffing. If breaches sit inside the window after those checks, the configuration is telling the truth.

One contaminating input to rule out first: automated mail. Two systems answering each other overnight manufacture tickets at near-constant intervals and light up every hour of the chart, which looks precisely like an uncovered night — the pattern diagnosed in a mail loop manufacturing tickets between your system and theirs. The same distortion comes from 1 customer emailing 3 times before morning: 3 tickets, 3 clocks, 3 breaches for 1 problem, which is why the merge test for two requests that look alike changes the breach count as well as the queue depth.

When the honest answer is that nobody was there

Sometimes the chart shows breaches inside the schedule window, and the finding is that the team is thin at the edges of the day. That is a commercial decision, not a bug, and there are 3 honest responses: extend the window and hire for it, differentiate targets by priority so the overnight promise is one you can keep, or publish a narrower response window.

• Differentiated targets are usually cheapest. An urgent lane with a tight target and everything else on business hours protects what matters without pretending to cover the rest — the trade-offs are in priority lanes or round-robin assignment.
• Overnight volume is often geographic before it is temporal. If after-hours arrivals concentrate in one region, the question is language and routing, not hours — the decision in translating into one queue or routing to a speaker.
• Morning triage recovers most of the loss. A queue correctly classified and ordered at 09:00 clears a night's backlog far faster than one read top to bottom, which is the low-risk start across ticket and shared-inbox triage.
• Be straight about your own cover. Ours is business hours IST, Monday to Friday, with no overnight rota, and every system we build has to work for a team in the same position.

None of this changes what the customer was promised. If the contract says a 4-hour response and the team works a 9-hour day, no configuration reconciles those 2 numbers; someone renegotiates the target or funds the cover. Configuration only decides whether the report is telling you the truth about which you have. Getting that instrumentation right, and building the morning triage that absorbs the backlog, is ordinary MVP and product build work inside our SaaS and customer support practice.

• sla
• business hours
• timezones
• helpdesk configuration