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.
More we can add to your workspace
- A unit, lease and tenancy entity, linking a repair to a tenancy on its own. A maintenance request is a ticket today, and which flat it belongs to is a convention you impose — a customer, a project, or a custom field.
- A 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.
- A 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.
Where we point you to a specialist
- 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 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.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsReporting 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.
