Your SLA Clock Should Tick in Business Hours, Not Calendar Hours

A vendor and a customer sign a support agreement with a four-hour response target. Two months later a ticket goes unanswered for what the customer calls eleven hours and the vendor calls three. Nobody is lying. The customer counted from the moment they hit send; the vendor counted only the hours its support desk was open. Both are reading the same clause, both believe they are right, and both are — because the clause said "four hours" without ever saying what an hour is.

Why an SLA clock should tick in business hours at all

An SLA is a promise about staffing dressed up as a promise about time. When you commit to a four-hour response, you are really committing to having a qualified human available to look at the ticket within four hours of it becoming your problem. If nobody is rostered between 5pm and 9am, those overnight hours are not hours in which the promise could ever have been kept. Counting them is not measuring service; it is measuring the length of the night.

Measured in raw calendar hours, a ticket filed on a Friday evening is already breached before the first agent logs in on Monday, even though the schedule everyone signed off on had nobody working. That produces two bad outcomes: a breach report that describes a failure nobody could have prevented, and a quiet pressure to staff hours the contract never priced. Business-hours measurement fixes both by counting only the time inside the window where the obligation actually lives.

None of this is an argument for a slower service. It is an argument for a measured one. If you want overnight coverage, buy overnight coverage and say so in the agreement. What you should not do is buy an 8x5 desk and then measure it against a 24x7 stopwatch.

"Business hours" is a contract term, not an assumption

The single most common defect in a support agreement is a business-hours clock with no definition of business hours. If the phrase appears in the SLA, the agreement has to answer four questions in writing:

• Which hours. 9am to 5pm is an assumption, not a fact. Write the opening and closing times as numbers.
• Which days. Monday to Friday is the default in most of the world, but not all of it, and a desk that covers Saturdays has a six-day SLA week that should be stated.
• Which timezone. This is where most disputes actually start. A vendor in London and a customer in Chicago can both read "9am to 5pm" honestly and be six hours apart. Name the timezone, and name it by region rather than by fixed offset, so that daylight saving shifts follow the same rule both parties expect.
• Whose holiday calendar. The vendor's public holidays are the ones that empty the support desk, so the vendor's calendar is usually the right answer — but it has to be the stated answer. A customer who assumed their own national holidays applied will be surprised exactly once a year, loudly.

When customer and vendor sit in different countries, resist the temptation to split the difference. One calendar governs; the other party needs to know which one, so they can plan around a desk that will be dark on days their own office is open. The same logic applies to company shutdown days that appear on no national calendar — if the desk closes for the week between Christmas and New Year, that belongs in the agreement, not in a surprise autoresponder.

Coverage models change the same nominal promise

"Four hour response" is not a level of service. It is a number that means completely different things depending on the coverage model underneath it:

• 8x5 — eight hours a day, five days a week. A four-hour target consumes half a working day. A ticket arriving late in the afternoon is answered the next morning; one arriving late on Friday is answered Monday. This is the cheapest model and the one most often mismatched to customer expectations.
• 12x5 — an extended day, typically bracketing two or three timezones. The same four-hour target now almost always lands inside the same calendar day, simply because there is more window to spend it in.
• 24x7 — the window and the calendar are the same thing. Business hours and calendar hours converge, so a four-hour target really is four hours, including at 3am on a public holiday. This is a staffing commitment before it is a measurement choice, and it should be priced as one.
• Follow-the-sun — continuous coverage handed between regional desks. Effectively 24x5 or 24x7, but with an extra wrinkle: the handover. If a ticket lands ninety minutes before a region closes, the agreement should say whether the clock is served by the region that received it or by the one that picks it up.

Write the coverage model into the agreement next to the numbers, not in a separate operations document nobody reads. The model and the target are one promise, and the number is meaningless without it.

Response, resolution, and update are three different clocks

A serious SLA makes at least three commitments, and they are independent of one another:

• Response — the time to a substantive human acknowledgement. This is the clock that says someone has taken ownership.
• Resolution — the time to a fix, or in many agreements to a workaround that restores service while the permanent fix is scheduled. If the agreement accepts workarounds, define what qualifies as one.
• Update — the cadence of progress reports while the ticket is open. This is the clock most often left out, and its absence is the source of the classic complaint that a vendor "went silent" on a ticket it was working furiously on.

Each of these breaches on its own. A ticket can be acknowledged in ten minutes, updated hourly, and still miss resolution by a day. Treat them as three separate commitments with three separate numbers, each measured against the same defined window.

The priority matrix is where the numbers live

Once the window and the coverage model are settled, the actual targets belong in a priority matrix. A conventional three-tier structure looks like this:

• P1 — service down or unusable for all users, no workaround. One business hour to response, four to resolution, hourly updates. At 24x7 shops this is often the one tier measured on calendar hours rather than business hours.
• P2 — significant degradation, or a major function unavailable with a workaround in place. Four business hours to response, sixteen to resolution, an update each business day.
• P3 — minor issue, question, or cosmetic defect. Eight business hours to response, forty to resolution.

Two rules keep a matrix honest. First, define the tiers by impact, not by adjective — "critical" invites an argument, "all users unable to log in" does not. Second, say who assigns the priority and how a disagreement about it gets resolved, because the tier is what selects every number in the row.

Pause provisions: when the clock legitimately stops

Some of the elapsed time on a ticket is genuinely not the vendor's to spend, and the agreement should say so rather than leaving it to goodwill. Two standard provisions cover almost all of it:

• Awaiting customer. When the vendor has asked for information, access, or a decision and cannot proceed without it, the clock pauses. The clause should require that the request be explicit and recorded on the ticket — a pause nobody can point to is a pause the customer will dispute.
• Third-party dependency. When progress is blocked on a supplier neither party controls, the clock pauses. This one needs a boundary, or it swallows the whole SLA: it should not cover subcontractors the vendor chose and manages.

Also state what restarts the clock and with how much time left on it. The usual answer — the remaining hours resume from the moment the blocker clears, or from the next window opening if it clears out of hours — is fair, but only if it is written down. For the mechanics of how a paused clock recomputes mid-ticket, and how a target agreed here lands on a real timestamp, see the companion piece on how a first-response deadline rolls over into the next working day.

Turn the clause into a timestamp

Every one of these decisions eventually has to produce a date and a time that both parties can check. The SLA Response / Resolution Deadline calculator takes the ticket's open time, your defined window and holiday calendar, and the target in business hours, and returns the exact deadline. Run it against a draft agreement before you sign it: pick the worst arrival time you can imagine — late Friday before a holiday weekend — and see what the clause you just wrote actually promises. If the answer surprises you, it will surprise your counterparty too, and it is far cheaper to be surprised now than during the argument.