Within One Working Day
A tenancy agreement promising a response "within one working day" and a system counting twenty-four wall-clock hours agree perfectly from Monday to Thursday. On Friday afternoon they part company, and only one of them is right.
The tenancy agreement says urgent repairs get a response within one working day. The system says the ticket is due in twenty-four hours. For most of the week these are the same promise, which is why nobody notices they are not the same rule.
A blocked drain reported at four on Friday afternoon is due, on the wall clock, at four on Saturday. The contractor is not working on Saturday, the office is not open, and by Monday morning the ticket has been red for two days. Under the agreement it was not late at all — one working day from Friday afternoon is Monday afternoon.
Both figures are computed correctly. They are measuring different things, and a managing agent who reports on the wrong one is either apologising for breaches that did not happen or missing the ones that did.
Two clocks, and the promise decides which
A response target can be counted in two ways, and the right choice comes from how the obligation is worded rather than from a preference about how the business should feel.
The elapsed clock
- Counts real hours, continuously, including nights and weekends.
- Correct for anything with a physical consequence that does not pause — a burst pipe, a lift with somebody in it, no water to a block.
- Correct when the promise is worded in hours: "restored within four hours".
- Unforgiving of a Friday afternoon, which is exactly what you want when the obligation genuinely is unforgiving.
The business clock
- Counts only the organization's working hours, on the days it works.
- Skips weekends and public holidays entirely.
- Correct when the promise is worded in working days, which is how most tenancy and service agreements word it.
- Stops a Friday report from being reported as a breach that nobody could have prevented.
The clock is chosen per ticket category, which is the right level — because a property portfolio has both kinds of obligation running at once and no single answer serves them.
A blocked drain reported at four on Friday is due at four on Saturday, and nobody works on Saturday. The system is not wrong. It is answering a different question from the one the lease asked.
Sorting your categories by clock
This is a half-hour exercise done once, and it is the whole of the setup. Take your maintenance categories and put each one against the promise it actually carries.
| Category | Clock | Why |
|---|---|---|
| No water, no power to a block | Elapsed | The consequence does not pause on a Sunday |
| Lift entrapment or failure | Elapsed | Safety, and the obligation is worded in hours |
| Burst pipe, active leak | Elapsed | Damage accumulates continuously |
| Blocked drain, faulty fitting | Business | The agreement says working days |
| Routine repair request | Business | Nobody expects a Sunday response |
| Lease query, statement request | Business | An administrative promise, not an operational one |
The test is simple: read the obligation as written. If it says hours, the elapsed clock is correct. If it says working days, the business clock is correct. Where nothing is written down, decide what you would be willing to defend to a tenant at a tribunal and use that.
What else the category carries
The clock is the interesting part but not the only part. A category also sets default routing — a department and an assignee — applied only when the ticket has not already specified its own.
For a managing agent this is more useful than it sounds, because the person who should see a leak and the person who should see a service-charge query are different people, and the sorting is the part that gets done badly when a portfolio is busy. Routing by category means the report itself decides where it goes.
Both the clock and the routing are reapplied when a category changes, which matters for the common case: a ticket logged as a general repair that turns out to be a burst pipe. Recategorising it moves it to the right team and recomputes its due dates rather than leaving it under the target it was originally given.
Due dates are anchored on when the ticket was created
Not on when it was categorised, not on when somebody looked at it. So recategorising a ticket that has been sitting for two days does not restart its clock — the new target is computed from the original report. That is the right behaviour and it does mean a ticket can be recategorised straight into breach, which is a fact about the delay rather than about the recategorisation.
What AWRA OpsHub does today
- Two clocks, chosen per category — elapsed wall-clock time, or business hours that skip weekends and public holidays.
- First-response and resolution targets set separately, so acknowledging a report and fixing it are measured as the different obligations they are.
- Anchored on the ticket's creation time, so a delay in categorising does not quietly buy back the time it consumed.
- Default routing per category — department and assignee — applied only when the ticket has not set its own.
- Reapplied when the category changes, so a recategorised ticket gets the right team and the right target.
What it does not do
- No unit, lease or tenancy entity. A maintenance request is a ticket, and which flat it belongs to is a convention you impose — a customer, a project, or a custom field. Nothing links a repair to a tenancy on its own.
- No contractor-side SLA. The clock measures your response to the tenant. When you pass the job to a plumber, their turnaround is not separately targeted or measured.
- No pause or clock-stop. A ticket waiting on the tenant for access, or on a landlord to authorise a spend, keeps consuming its target — so a delay that is genuinely not yours still reads as yours.
Not ours, by choice
- We will not let a category quietly overwrite a target somebody set deliberately on a ticket. Routing defaults apply only where the ticket has not made its own choice, because a person who set an assignee had a reason.
- We will not restart a clock on recategorisation. The tenant reported the problem when they reported it, and a system that resets the target when somebody relabels the ticket is measuring the office rather than the obligation.
A clock-stop for tickets awaiting tenant access or landlord authorisation, and a separate contractor-side target, are both scope rather than ceilings. The two clock modes, the working-hours calendar and the per-category configuration all exist and work.
The clock-stop gap is the one that will bite a managing agent first, because "waiting for the tenant to give access" is the single most common reason a repair takes three weeks. Until it exists, record those waits in the ticket so the reason is on the record even though the clock keeps running.
Reporting on it without misleading yourself
Once targets are being counted properly, the numbers become worth showing to a landlord — and that is exactly when it becomes important to be careful about what they say.
Before a breach figure goes to an owner
- Check that each category is on the clock its obligation is worded in. A portfolio reporting elevated breaches is often reporting weekends.
- Separate first response from resolution. Acknowledging a report within a working day and fixing it within a working day are wildly different promises and lumping them hides which one you are failing.
- Look at what proportion of breaches are tickets waiting on access. Since the clock does not stop, those inflate your figure and are not a performance problem.
- Check for tickets recategorised late. A ticket that sat uncategorised for two days is measured from its report, which is correct — and it means the delay shows up against the new team rather than the sorting.
- Report the median as well as the breach count. One repair that took eleven weeks and forty that took a day is a different business from forty that each took a fortnight.
The third item is where most of the noise sits in property specifically. A repair cannot proceed without access, access depends on a tenant being at home, and the resulting delay belongs to nobody in particular but is currently counted against you.
What a target is actually for
It is worth being clear about this, because response targets get treated as a performance-management instrument and that is not their most valuable use.
A target's first job is to make a queue self-sorting. In a portfolio with sixty open repairs, the question every morning is which ones to do today, and the honest answer without targets is whichever tenant complained most recently. Targets replace that with a due date, and the person who shouts loudest stops being the person who gets served first.
Its second job is to make a promise legible. A tenancy agreement that says "reasonable time" is not a commitment anyone can act on; a category with a written target is. And a portfolio where the targets are visible to the tenant is a portfolio with far fewer chasing calls, because the most common reason a tenant calls twice is not knowing whether the first call landed.
The work-order side of this is in maintenance and work-order control, the modelling constraint underneath it in no such thing as a unit, and the recurring-maintenance discipline in the inspection that stopped recurring.
Our take
Spend half an hour putting each maintenance category onto the clock its obligation is actually worded in — hours means elapsed, working days means business — and most of the phantom weekend breaches disappear immediately. Then be honest with yourself about the clock-stop gap: a repair waiting on tenant access keeps consuming its target, so before any breach figure goes to a landlord, check how much of it is access rather than performance. The targets are worth having mainly because they stop the loudest tenant being the first served, which is what a queue does without them.
See response targets on a real queue
Elapsed or business-hours clocks chosen per category, separate first-response and resolution targets anchored on the report, and routing that sends each kind of request to the right team.
Explore the SLA engineFrequently asked questions
Why do our weekend repairs always show as breached?
Almost certainly because that category is on the elapsed clock, which counts real hours continuously — so a report at four on Friday is due at four on Saturday, when nobody is working. If the obligation is worded in working days, put the category on the business clock, which counts only your working hours on the days you work and skips weekends and public holidays. It is a per-category setting and it takes minutes; most phantom breaches in a property portfolio are weekends being counted.
Which clock should we use?
Read the obligation as written. If it says hours — "restored within four hours" — use the elapsed clock, because the consequence does not pause overnight and neither should the measurement. If it says working days, use the business clock. A portfolio needs both: no water to a block is an elapsed obligation, and a routine repair request is a working-days one. Where nothing is written down, pick what you would be prepared to defend to a tenant and write it down.
What happens if we recategorise a ticket?
The clock and the routing are both reapplied — the ticket moves to the right team and its targets are recomputed under the new category. The dates are anchored on when the ticket was created rather than when it was categorised, so recategorising something that sat for two days does not buy that time back. It can therefore move straight into breach, which is a true statement about the delay rather than an artefact of the relabelling.
Does the clock stop while we wait for the tenant to give access?
No, and for a managing agent this is the limitation that matters most, because waiting for access is the single most common reason a repair takes three weeks. The target keeps running, so a delay that is genuinely not yours reads as yours. Until a clock-stop exists, record the waits in the ticket so the reason is on the record, and check what proportion of your breaches are access before you report a breach figure to a landlord.
Can we set a target for the contractor as well?
Not separately. The clock measures your response to the tenant, and once the job is passed to a plumber their turnaround is not independently targeted or measured. In practice most agents handle this by keeping the ticket open against the original target and recording contractor dates in the ticket, which preserves the tenant-facing promise even though the contractor-facing one is not computed.
How do we link a repair to a specific flat?
By a convention you choose, because there is no unit, lease or tenancy entity — a maintenance request is a ticket, and nothing ties it to a tenancy on its own. The workable options are the tenant as a customer, the building as a project, or a custom field carrying the unit reference. Pick one before you start logging repairs and apply it consistently, because a portfolio with three conventions cannot report on any of them.
