Awaab’s Law Is an Operations Problem, Not a Compliance Problem

Most of the discussion around Awaab’s Law has focused on what social landlords are now legally required to do. That’s understandable, and the duties are clear enough. But the social housing repairs process underneath is what actually determines whether a provider can meet those duties.

That’s understandable, and the duties are clear enough.

Far less has been said about the thing that actually determines whether a provider meets them — whether the social housing repairs process underneath is capable of running at the speed the law now demands.

Awaab’s Law isn’t asking landlords to care more. It’s asking their operations to move faster than many repairs processes were designed to handle.

What the law actually requires

The statutory timeframes are specific, and it’s worth setting them out plainly because the operational implications follow directly from them.

Phase 1 came into force on 27 October 2025, covering damp and mould plus all emergency hazards. Phase 2 extends it during 2026 to excess cold and heat, falls, structural collapse, explosions, fire, electrical hazards and hygiene issues. Phase 3 follows in 2027, covering all remaining HHSRS hazards except overcrowding.

The direction is unambiguous. The scope widens every year, and the clock does not.

Why this is a process problem

Read that table again as an operations person rather than a compliance officer.

In practice, a 24-hour investigation deadline means the process from tenant report to surveyor on site must complete within one working day, every time, including on a Friday afternoon.

Similarly, the three-working-day deadline for a written summary means the findings must move from the surveyor’s head into a document and out to the tenant, through whatever review sits in between, in three days.

Finally, a five-working-day repair deadline means materials, operative availability and access must all align within a week of the investigation concluding.

None of those are achievable by trying harder. They are achievable only if the underlying process is designed for them.

If your repairs process has any step where work waits for a weekly meeting, you cannot meet a 24-hour deadline. The maths does not work.

Where the time actually goes

In repairs processes we’ve reviewed, the delay almost never sits where people assume. It’s rarely the operative on site.

It sits in the gaps:

• Triage. A report arrives and waits for categorisation because the person responsible has other duties.
• Allocation. Once the team categorises the job, it waits for someone to schedule it, often as part of a batch.
• Access. The team makes the appointment, but the tenant isn’t in, and the re-book goes to the back of the queue rather than retaining its original priority.
• Handover to the surveyor. A distinction between an inspection and a repair creates a queue between two teams with different systems.
• When the investigation identifies work beyond the original scope, that work re-enters the process as if it were a new report.
• The written summary. A genuinely new administrative step that most repairs processes had no equivalent of before.

Each individual delay is defensible. However, taken together, these delays are what turn a five-day duty into a three-week outcome.

The data problem underneath it

There’s another issue, too. It surfaces immediately when providers start measuring against these timeframes.

Traditionally, most repairs systems were built to report on volume and completion – how many jobs raised, how many closed, average time to complete. Awaab’s Law requires something different: the ability to demonstrate, per case, that specific clocks were met, with an auditable trail of when each stage started and finished.

That is a different data model. A monthly average that looks healthy can conceal a significant number of individual cases that breached. Under the old reporting regime nobody would have noticed. Under this one, each of those is a compliance failure.

An average tells you how the service performed. Awaab’s Law asks about every single case.

Providers need case-level tracking against each statutory clock, exception reporting that flags a case approaching a deadline rather than after it has passed, and the ability to evidence the full timeline retrospectively.

The tenant side of the same process

There is a second effect worth naming, because it changes how the process should be designed.

Every one of these statutory clocks starts with a tenant reporting something. Which means the quality of that first interaction determines whether the clock starts at the right time, against the right category, with the right information.

In practice, reporting routes are often the least examined part of a repairs operation. A tenant describes a problem in their own words to somebody working from a fixed list of categories. The translation between those two things is where mis-categorisation begins – and a mis-categorised case is measured against the wrong deadline from the outset.

On top of that, the written summary requirement compounds this. Providers now have to communicate findings back to the tenant within three working days, in a form the tenant can understand. That is a genuine new capability for many operations, and it is not simply an administrative task. A summary that is technically accurate and incomprehensible will generate a follow-up contact, which generates further work.

As a result, designing the tenant-facing end of the process properly reduces load everywhere downstream. Teams usually treat it as a communications question. In reality, it is an operations question.

What we’d do first

If a provider asked us to help, we’d start with this sequence.

Map the process against the clocks. Take each statutory timeframe and walk the current process against it. Where does the current design make the deadline impossible rather than merely difficult? Those points are the priority.

Find the queues. Identify every point where a case waits for a batch, a meeting, or a person with competing priorities. Batching is the single biggest enemy of a 24-hour deadline.

Fix triage first. Getting categorisation right immediately and accurately determines which clock applies. If categorisation happens late, the clock has already been running. A wrong categorisation means you’re measuring against the wrong deadline entirely.

Design the exception route. Most cases will flow normally. The ones that breach will be the ones that hit an obstacle, no access, unavailable materials, works exceeding scope. Design those routes deliberately rather than letting them default into the standard queue.

Instrument it. Build case-level measurement against each clock, with alerts before breach rather than reports after.

What to measure

If we were setting up reporting for this, these are the measures that would matter.

More importantly, the critical distinction is between reporting that tells you what happened and reporting that tells you what is about to happen. A monthly breach report is a record of failures you can no longer prevent.

The wider point

Ultimately, everything above is standard business process improvement work. Reduce waiting. Remove batching. Clarify ownership at handovers. Measure at case level rather than in aggregate. Design for exceptions rather than pretending they won’t occur.

The regulation is new, but the operational discipline it demands is not. Treating this as a compliance exercise means adding reporting on top of a process that may still struggle to meet the deadlines. That approach risks continued breaches.

A process redesign takes a different approach. It focuses on meeting the deadlines while improving how the repairs service works for every tenant, not only those reporting a hazard.

Our work with believe Housing  → /case-studies   on repairs and maintenance transformation followed exactly this logic — the process first, the reporting second.

Read more about our business process improvement  → /business-improvement   work, or get in touch  → /contact   to discuss your repairs operation.