SLA deadline mistakes: the blind spots that make two teams read the clock differently

Most SLA disputes are not arithmetic errors. They are two parties correctly calculating two different things, because the agreement gave them two different things to calculate.

Below are the failures that produce that outcome, in rough order of how much money they move.

What to take away

1. Three units in one document

A resolution target in "hours", an escalation trigger in "business days", a reporting period in "calendar days", and a termination notice in "days". Each clause was written by someone thinking about that clause.

Over a short window the units look interchangeable. Over a long one they are not remotely: a thirty-unit period is thirty days, or six calendar weeks, or something in between depending on closures. Anyone reconciling the clauses afterwards will find that the escalation fires after the report is due, or before the target expires, and nobody intended either.

Fix it by counting the distinct units in the document. If there is more than one, that is a decision someone has to have made deliberately.

2. "Working days" and "business days" used as synonyms

They are frequently used to mean different things: one the days a particular organization works, the other the days on which business generally is transacted, which is closer to banking or court days. Neither meaning is universal.

The specific danger is a document that uses both. Drafting convention presumes that different words carry different meanings, so a contract containing both terms has handed a future opponent an argument that they are distinct. Pick one term, define it in the definitions clause, and use only that one throughout.

3. The clock starts at the wrong timestamp

There are usually at least three: when the event occurred, when it was reported, and when someone on the receiving side saw it. Systems tend to record the third and contracts tend to mean the second.

The gap is small on a Tuesday morning and enormous for anything arriving overnight or at a weekend. Decide which timestamp governs, and make sure the field the report reads is the field the contract names. The timestamp that governs the trigger also decides which day starts the count in these add business days examples.

4. Pausing the clock with no rule for pausing

"Waiting on customer" is the most expensive undefined term in service management. Both sides agree the clock should stop sometimes; almost no agreement says when it stops, who may stop it, whether it stops retroactively, or what reopens it.

Without that, the provider's clock and the customer's clock diverge from the first pause onward, and every subsequent breach calculation inherits the difference.

5. A target in hours, a report in days

The target is exact. The report rounds. A response that took four hours and eleven minutes against a four-hour target is a breach, but on a report that buckets by day it is comfortably inside a same-day commitment.

Two dashboards then disagree, both are correct, and the argument becomes about the dashboards rather than the service. Report at the granularity the target is written in.

6. Using the tool's calendar instead of the contract's

Whatever holiday list your ticketing system shipped with, it was chosen by a vendor for a general audience. It has a level (national, regional, sector), and a vintage.

The contract's calendar governs. If the contract does not name one, that is the actual defect, and the tool's default is quietly filling a gap the parties never agreed on. Pinning down which calendar applies is a drafting job, not a configuration job.

7. Recomputing an old deadline with a current calendar

Six months later somebody re-runs a breach calculation to check it. The holiday list has been amended since, the working-hours configuration has changed, and the recalculation returns a different answer than the one everyone acted on.

Both numbers are right for their own inputs. Store the inputs alongside the answer (the trigger instant, the window, the calendar and its as-of date), so that "what was the deadline" and "what would the deadline be today" stay separable questions.

8. The window itself changes mid-term

Offices change hours. A site closes. A closure is declared with little notice. Almost no agreement says what happens to a clock already running when the window underneath it moves.

Say whether in-flight clocks use the window in force at the trigger or the window in force now. Either is workable. Neither is the default.

9. Sent, or received?

A response due "by" a moment can be met at the instant of sending or the instant of receipt. For anything routed through a queue, a moderation step or a mail relay, those differ. Name one.

Fixing a contract that already mixes units

You rarely get to redraft from scratch. Two additions do most of the work:

A definitions clause with one unit in it. Define the working week, the calendar and its publisher, the zone, the business-hours window, and the pause rule. Then use one term for the unit everywhere else.

One worked example inside the agreement. A single sentence (a trigger at a stated instant, and the deadline it produces), settles more ambiguity than a page of definitions, because it forces every convention into the open. If the parties cannot agree the worked example, they were never going to agree the clause.

The habit that prevents the rest

Where a specific deadline matters, write the instant next to the interval, with its zone: not "within four business hours" alone but "within four business hours (by 14:00 Europe/London on [date])".

It costs a clause. It converts a disagreement that surfaces at breach into one that surfaces at drafting, and it gives you a free consistency check every time: if the interval and the stated instant ever disagree, one of your assumptions is wrong and you have found it before it cost anything.

For what a tool has to model before it can apply any of this, see what an SLA clock has to get right.

Common questions

Which unit should a service level use?

Whichever matches the obligation, stated once and used everywhere. Business hours suit response work; open days suit anything measured in whole working periods; elapsed time suits availability. Mixing two in one document is the failure. The clock model itself is under service level deadlines.

Can a target be restated in a different unit for reporting?

Only with a stated conversion, and the conversion is an assumption rather than arithmetic. Forty business hours is five days on an eight-hour window and more on a shorter one, as set out under working hours.

Who should be allowed to pause a clock?

Whoever the agreement names, and nobody else. An unnamed pause right is the same defect as an unnamed calendar: both are defensible when written down and disputed when not. The general shape of what belongs in the drafting is described under service-level agreement.

Should an old deadline be recomputed with today's calendar?

No. Recompute it with the calendar version it was measured against, which is why the version has to be stored with the answer. This is ordinary software versioning discipline applied to calendar data.

What is the single cheapest safeguard?

One worked example inside the agreement: a trigger at a stated instant and the deadline it produces. It forces every convention into the open at drafting time.