Two Clocks, One Promise
A support promise measured in working hours has to know when you work — in both directions. A clock that knows in only one direction can put a Friday deadline at eleven at night.
Almost every support contract worth signing is written in working hours. "One working day" for a general enquiry, "four hours" for an outage, and the difference between those two phrasings is the whole reason the distinction exists: one of them means four hours at two in the morning and the other does not. A system that measures both against the same clock is wrong about one of them, always. Many systems get half of this right, and the missing half does not show until somebody pauses a ticket.
The half everybody builds
Each ticket category chooses its own clock. Leave it on elapsed time and a four-hour promise means four real hours, counted through the night and the weekend, which is exactly what an outage promise should mean. Switch it to working hours and the countdown stops at closing, skips the days your organization does not work, skips your public holidays, and starts again when you open.
That calendar is not ours to guess at. The working week is a setting, because it is genuinely not the same everywhere — a business whose weekend falls on Friday and Saturday is not an edge case to be handled, it is a Tuesday. The same setting already governs leave calculations and workflow due dates, so an organization answers the question once and everything downstream obeys it.
Why this is worth a whole post
Because a feature can be real, shipped, tested and demonstrable, and still produce a wrong answer the first time anybody uses it in anger. A capability that is right in the demonstration and wrong in the second week is more expensive than one that was never built, because you have already stopped checking.
The half that gets missed
Support tickets spend a lot of their life waiting on the person who raised them. You ask a question, they are in a meeting, and the ticket sits. That time should not count against you, so the clock pauses while a ticket is waiting on its requester and the deadline moves out when it comes back.
In a system with only half a calendar, the pause moves the deadline by the amount of real time that has passed. Not working time. Real time — the same wall clock the working-hours setting exists to stop using.
One ticket, one question asked, one deadline
Read the fourth row again, because the size of the error is not the interesting part. The deadline lands at eleven o'clock on a Friday night, on a promise whose entire purpose is to only count hours somebody is at work. An organization that switches to working hours specifically to stop getting weekend false breaches gets a worse one, and gets it the first time an agent asks a question — which is to say, almost immediately, and on the ticket where they were being diligent.
Where the defect lives
Not a rounding bug and not a calendar with a wrong holiday in it. The countdown is computed in one place and the pause is refunded in another, and only the first place has been taught about the working week. The second does arithmetic that is correct for an elapsed clock and quietly wrong for a working one, which is what makes this class of defect survive: the wrong half is not broken, it is out of date.
The underlying cause is smaller and more general than the symptom: a working calendar that can only count forwards — give it a starting point and an allowance and it tells you when that allowance runs out. It cannot answer the opposite question, which is how much working time lies between two moments. So the code that needs to give back an interrupted allowance has no way to measure one, and does the only thing available.
The general version, which is not about helpdesks
A clock you can only count forward on is half a clock. Any system that computes deadlines against a business calendar will eventually need to measure a span against that same calendar — for a pause, a hold, a suspension, an appeal window. If only one direction exists, the other one gets written with whatever arithmetic is to hand, and it will look right for exactly as long as nobody pauses anything.
How AWRA holds the deadline
The deadline is held as remaining time rather than as a span to refund. At the moment the clock pauses, the ticket has some amount of its allowance left; when it resumes, it gets exactly that much again, counted from now, on whichever clock its category runs. A ticket that was already past its deadline when the pause began stays past it — waiting on a requester does not un-miss a deadline you had already missed.
One property of this design is worth stating: on an elapsed clock, giving back what was left, measured from now, lands on the identical instant as pushing the deadline out by the length of the pause. The two methods disagree only on a working-hours clock — which is exactly where they should. That is asserted in a test rather than believed.
The question to ask anybody, including us
Vendors demonstrate the countdown. It is the part that looks good in a demonstration — a clock that visibly stops at five and starts again at nine. Almost nobody demonstrates the pause, and the pause is where two clocks get a chance to disagree.
- Whose calendar is the working week? If it is the vendor's and not yours, the answer is already wrong for anybody whose weekend is not Saturday and Sunday.
- What happens to a working-hours deadline when a ticket waits on the customer overnight? Ask for the resulting date, not a description. A date can be checked against a calendar; a description cannot.
- Does the pause use the same calendar as the countdown? This is the actual question, and it is worth asking in exactly these words, because a system can answer yes to the first two and no to this one.
We publish our own answers because a post that tells you to interrogate everyone else and never answers first has told you nothing. Ours are: yours, Monday 15:00, and yes. The measured figures in the table above are from our own test suite, because a claim about accuracy is worth what its worst example is worth.
