Client
A regional UK housing association managing several tens of thousands of social rented homes across multiple local authority areas
Sector
Social Housing
Engagement
Repairs and asset management data platform build, hazard timescale tracking and compliance reporting - multi-quarter programme.
What the client needed
The client's repairs operation ran across a contact centre, several regional maintenance teams and a network of contracted trades, each logging progress in a different way - a legacy repairs case management system for some jobs, spreadsheets maintained by regional teams for others, and paper-based sign-off from some contracted trades that only reached head office days after a job was actually completed. Establishing how long a reported damp or mould hazard had genuinely been open, from first report to a contractor confirming remediation, meant manually cross-referencing several of these sources, and the answer was frequently uncertain even after the exercise. With Awaab's Law's fixed statutory timescales for investigating and fixing emergency and significant hazards now in force, and further hazard categories due to be brought into scope during 2026, the client's compliance team could no longer treat "we're generally pretty quick" as an adequate answer. They needed a system that captured a hazard from first report, tracked it against the applicable statutory clock without manual calculation, escalated automatically as a deadline approached, and could produce a complete, defensible timeline for the housing ombudsman or a tenant's legal representative without days of manual reconstruction.
How we worked
- Mapped every point a repair or hazard report could enter the organisation - contact centre calls, the tenant portal, regional maintenance teams and contracted trades - to design a single intake model that all channels fed into rather than replacing any channel tenants were used to using.
- Built a hazard classification step at the point of intake that applies the correct Awaab's Law category and statutory clock automatically, based on structured triage questions rather than leaving classification to individual judgement calls made under time pressure.
- Designed automated escalation rules that notify the relevant manager as a statutory deadline approaches, with a separate, more urgent path for emergency hazards requiring action within 24 hours.
- Integrated with the client's existing asset management system so property-level history - previous repairs, known building defects, vulnerable resident flags - is visible to whoever is triaging a new report, rather than requiring a separate lookup.
- Built a contractor-facing mobile update flow so trades working on site could log job status and completion evidence directly against the relevant case, closing the gap that previously left head office waiting days for paper paperwork to catch up.
- Delivered a compliance reporting layer that reconstructs a full, timestamped case history for any hazard on demand, including every escalation, contact and status change, for use in board reporting, regulatory returns and individual case reviews.
Measured results
All figures verified with the client. Specific identifiers, property locations and individual case details withheld in line with our standard confidentiality terms and tenant privacy obligations.
- Average time to first investigation of a reported significant hazard fell to comfortably within the statutory 10 working day window, with full visibility of every case still in progress against its clock.
- Emergency hazard response, previously tracked manually against the 24-hour requirement, is now monitored automatically with real-time escalation, removing reliance on a single coordinator remembering to chase.
- Time to assemble a complete, audit-ready case history for a housing ombudsman enquiry or board compliance report dropped from several days of manual reconstruction to a matter of minutes.
- Cases where hazard classification was disputed or corrected after initial triage fell substantially, as structured intake replaced inconsistent individual judgement calls.
- Contractor-reported job completion delays reaching head office dropped from a multi-day paper-based lag to same-day visibility for the large majority of jobs.
- The client's board now receives a monthly statutory compliance position drawn directly from the platform, rather than a manually compiled summary assembled from multiple source systems.
"We used to find out a hazard had breached its timescale when a tenant or their solicitor told us. Now the system tells us three days before the deadline, not three days after we've missed it. That change alone has shifted how our repairs team works day to day, and it's given our board something they can actually stand behind when they're asked how confident we are in our compliance position."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
Awaab's Law changed what "good enough" repairs practice looks like for social landlords, moving from a general expectation of reasonable responsiveness to specific, statutory clocks: 24 hours to investigate and make safe an emergency hazard, 10 working days to investigate a significant hazard such as damp, mould, excess cold or fire risk, with further categories being phased in through 2026 and 2027. That shift matters operationally in a way that isn't obvious from the regulation text alone. A housing association can run a genuinely responsive repairs service and still fail an audit, if the evidence proving responsiveness doesn't exist in a form that can be produced on demand. The client's underlying performance, on discovery, wasn't actually poor - most hazards were investigated reasonably quickly. The problem was that "reasonably quickly" was an impression held by experienced staff, not a fact the organisation could demonstrate to a regulator, an ombudsman, or a tenant's legal representative without a multi-day reconstruction exercise pulling data from several disconnected sources.
The client's environment added real complexity to solving this cleanly. Repairs entered through several channels that had each grown up independently - a contact centre with its own scripts and system, a tenant portal added more recently, regional maintenance teams with local ways of working, and a network of contracted trades who, reasonably, wanted a simple way to log a completed job from a phone on site rather than learning a full case management system. Any solution that forced all of these into a single rigid interface risked being quietly worked around within months, which would have recreated the exact fragmentation problem we were there to fix.
Designing intake and classification that survives real triage pressure
The most consequential design decision was building hazard classification into the intake step itself, rather than leaving it to a case worker's judgement recorded informally afterwards. Contact centre staff and portal submissions are guided through a short structured triage that maps directly onto the statutory hazard categories, so the applicable clock starts correctly and automatically from the moment a report is logged, rather than being assigned retrospectively by whoever eventually reviews the case. This took real care to get right during discovery: triage questions had to work for a stressed tenant reporting a leak at 8pm as well as for a trained contact centre agent, and had to fail safe, meaning any ambiguous case defaults to the more urgent classification and shorter clock rather than the reverse.
We deliberately avoided using the AI-style triage shortcuts some vendors in this space were pushing at the time, where a model attempts to infer hazard severity from free-text description alone. For a system whose classification decision starts a legally significant clock, a structured, auditable decision path that a compliance team can fully explain to a regulator was the right trade-off over a model-driven classification that might be marginally faster but harder to justify case by case if challenged.
Bringing contractors into the data flow without adding friction
Contracted trades were the weakest link in the original process, not through any fault of their own - paper-based job sheets and end-of-week reporting cycles simply weren't built for a same-day compliance clock. We built a lightweight mobile update flow that let a tradesperson log arrival, findings and completion evidence directly against the relevant case from a phone on site, deliberately kept to the minimum fields needed rather than replicating a full desktop case management interface. Adoption was a genuine concern going in, and we worked directly with several contracting partners during a pilot phase to refine the flow before wider rollout, treating their feedback on friction points as seriously as the client's own requirements. That investment paid off in the completion-reporting lag figures, which dropped from days to same-day for the large majority of jobs without requiring contractual changes to force compliance.
Lessons learned
The first lesson was that compliance with a statutory timescale regime is a data architecture problem before it is a process problem. The client's repairs practice was already broadly compliant in substance; what it lacked was a system capable of proving that, continuously and automatically, rather than through periodic manual audit. Organisations facing similar statutory clock regimes elsewhere - whether in health and safety, financial services complaint handling, or other timescale-driven compliance regimes - tend to underestimate how much of the real work is in intake and classification design, not in the reporting layer that gets built last and gets most of the attention.
The second lesson was about where not to introduce automation. The temptation to let a model infer hazard severity from free text was real, and resisting it in favour of a slower, structured, auditable triage path was the right call for a system whose output starts a legally meaningful clock. Faster is not always better when the thing being sped up needs to be defensible afterwards.
The third lesson was that a compliance platform which ignores the experience of the people entering data at the edges - contractors on site, contact centre staff mid-call - will be worked around, however well it satisfies the compliance requirement on paper. Treating contractor adoption as a design constraint from the start, not an afterthought, was what made the completion-reporting improvement stick rather than quietly decay after go-live.
If you are managing statutory timescale compliance across a fragmented set of internal teams and external partners and want a system built to prove compliance rather than merely support it, we would be glad to discuss what a programme like this might look like for your organisation. Email sales@halfteck.com.