The Friday-Afternoon Ticket: When Is First Response Actually Due?

A customer files a ticket at 4:50pm on Friday. Your support policy promises a first response within four business hours. So… when is it due? Not 8:50pm Friday — the working day ends at 5. Not Saturday. The honest answer is somewhere around lunchtime Monday, and the fact that most people can't produce that answer quickly is exactly how response deadlines get missed without anyone deciding to miss them.

This is the arithmetic side of the problem. It assumes you have already settled the argument about why the clock should run only while the desk is staffed, and what your window and priority tiers ought to say — if you haven't, start with what a business-hours SLA has to define in the agreement itself, then come back here to turn those numbers into timestamps.

The rollover arithmetic, step by step

Here is the mechanic that makes business-hours deadlines non-obvious. Take a 4-hour target and a 9am–5pm window, and walk three arrivals through it.

Mid-afternoon Tuesday, 3pm. Two working hours remain today, 3pm to 5pm, which consumes half the target. The remaining two hours spill into Wednesday and start counting at 9am, so the deadline is 11am Wednesday.

The same time on Friday, 3pm. Identical arithmetic, but the two leftover hours have nowhere to go until the window reopens, so they land at 11am Monday. Sixty-eight calendar hours have passed; four business hours have passed. Both statements are true, and only one of them is the promise.

The 4:50pm Friday ticket from the opening. Ten minutes tick off before close of business. The remaining 3 hours 50 minutes resume Monday at 9am, putting the deadline at 12:50pm Monday. Notice what that means in practice: the ticket has burned about 4 percent of its target and the customer has waited an entire weekend. The number is defensible; the experience is not, which is why late-Friday arrivals are worth watching even when they are nowhere near breach.

The pattern never changes: spend whatever is left of today's window, then resume at the next working day's opening bell, and keep resuming until the target is exhausted. Every business-hours deadline you will ever compute is that loop.

Tickets that arrive outside the window

A ticket filed at 10pm, or at 6am, or on Sunday doesn't start burning SLA time on arrival. The clock starts at the next window open. A 10pm Tuesday ticket begins its four hours at 9am Wednesday and is due at 1pm Wednesday — exactly the same deadline as a ticket filed at 8:59am that morning.

Take the awkward case: a ticket arriving at 8pm on Saturday. Nothing happens Saturday. Nothing happens Sunday. The clock starts at 9am Monday and the four-hour target expires at 1pm Monday — roughly 41 calendar hours after the customer hit send, and not a breach, because the clock never ran. Now put a public holiday on that Monday: the start slides to 9am Tuesday and the deadline to 1pm Tuesday, some 65 hours after arrival, still not a breach.

This is the rule your customers most need explained, and it is worth explaining at arrival rather than in a breach review. "We received it Saturday evening" and "the clock started Monday at 9" are both true, and an autoresponder that states the window and the next opening time defuses most of the arguments the raw number would otherwise cause.

A clock that spans a holiday

Holidays behave exactly like weekends in the arithmetic — they are simply days with no window — but they are far easier to get wrong, because weekends are in every calendar and holidays are in a list somebody has to maintain.

Work an example. An 8-business-hour target, a 9am–5pm window, a ticket opened at 2pm on the Wednesday before a Thursday public holiday. Three hours burn on Wednesday afternoon, leaving five. Thursday is closed, so nothing burns. Friday opens at 9am and burns the remaining five, putting the deadline at 2pm Friday. Move the holiday to the Friday instead and those five hours roll across the weekend to Monday, landing the deadline at 2pm Monday — the same ticket, the same target, three days apart, decided entirely by which day the holiday fell on.

Two practical consequences. First, the holiday list in your helpdesk has to be the list that actually empties your desk, including company-specific closure days that no national calendar knows about. Second, the weeks either side of a holiday are where SLA reporting goes strange, so when a breach rate spikes there, check the calendar before you check the team.

Clocks paused mid-ticket

Most helpdesk platforms stop the SLA clock while a ticket waits on the customer — the pending state. That is the right behaviour, and it means a deadline computed once at ticket creation is wrong for any ticket that has ever sat in pending.

The clean way to think about it is remaining hours, not fixed timestamps. When the clock pauses, record how many business hours were left. When it resumes, compute a fresh deadline from the resume moment using only those remaining hours. Concretely: a 4-hour clock starts at 10am Tuesday; at 11:30am the agent asks the customer for a log file and the ticket goes pending with 2 hours 30 minutes left. The customer replies at 4pm Wednesday. The clock restarts at 4pm with 2:30 on it, spends one hour before close, and finishes the last 90 minutes from 9am Thursday — deadline 10:30am Thursday. Had the customer replied at 9pm instead, the resume would slide to 9am Thursday and the deadline to 11:30am.

The habit that keeps this honest is recomputing on every state change rather than trusting the number your helpdesk stamped on the ticket at creation. A stale deadline is almost always wrong in the direction that makes your team look slower than it was.

Set the window to the hours you actually staff

The working window in the calculation should match reality, not the website footer. If support is genuinely covered 8am to 6pm, use 8 and 18. A window narrower than your real coverage makes every deadline later than it needs to be and hands the team slack it never asked for; a window wider than your staffing quietly promises hours nobody is working, and every out-of-hours arrival gets scored against a desk that was dark. The same goes for the workweek: a team that covers Saturdays has a six-day SLA week, and its deadlines should reflect it.

The priority tier matters here too, because it selects which target you are counting — the one-business-hour response or the eight — and a top-tier incident running on round-the-clock coverage is measured against a window that never closes at all. Pick the row first, then run the numbers.

Get the timestamp, not the guess

The Support Ticket Response Deadline calculator does the rollover math directly: enter when the ticket was opened, the target in business hours, and your working window and workweek, and it returns the exact deadline timestamp. Run it once for the first-response clock and once for resolution. It is also the fastest way to audit a helpdesk configuration — take last month's late-Friday and around-a-holiday tickets, compute their deadlines independently, and compare. Where the two disagree, the business-hours schedule in your platform is wrong, and it has probably been wrong for every ticket like it.