Building an efficient system for tracking and managing housing repairs

The challenge

Hackney Council manages social housing repairs for over 33,000 homes.

The back office repairs teams needed to coordinate several teams of operatives across multiple properties. They were using outdated software which led to over-complicated processes. It was hard to link related repairs and track the status of requests. This made it difficult to deliver a good service to residents, with many requiring repeat appointments and facing lengthy waiting times. For the council, it’s important to deal with leaks quickly and support people to live in safe, dry homes.

Unboxed were tasked with tracking repairs more effectively. As ‘repairs’ cover a whole range of services, we started with a rapid Discovery to understand where we could deliver the most value. The council were keen to build something that worked for their teams quickly. After spending time shadowing different teams, interviewing stakeholders and mapping user needs, we identified the Leaks Hub as the area where we could make a significant impact in a short period of time. This is a team tasked with coordinating repairs caused by water leaks.

At the time, Hackney managed over 15,000 leak-related repair visits every year. Many of these were in tower blocks where a leak in one property could be related to a problem in another. This made the service incredibly complex. The existing software was only adding to this complexity, with poor user interfaces forcing manual and often unnecessary processes.

Through a technical Discovery, we’d understood where we could extract data more quickly to deliver information to repairs teams in a much more visible and connected way. We saw an opportunity to improve the leaks service by building a new system quickly and iteratively, working alongside teams to test and implement as the new service developed.

Our approach

We knew that the Leaks Hub team was already busy and working in a high pressure, difficult environment. We needed to learn from them but also show them the value of working with us to create change.

Working alongside both back office teams and repairs operatives on site, we developed a coded prototype very quickly. This allowed us to show the council and service users what was possible, gaining buy in for our approach.

One of the biggest challenges was that much of the data around tracking leaks was ‘hidden’ and difficult to use. We prioritised building an API and rapidly prototyping a means of sharing that data with teams when they needed it. By proving early on that we could extract this data and make it more visible, we were able to let teams see and feel the potential improvements to their working processes.

Visibility of information is vital to connecting up repairs requests. In multi-tenancy buildings, the Leaks Hub needed to spend a lot of time on investigation to understand potential causes of a leak and assign the right operatives. Without good data, they were having to piece together bits of information without a consistent or holistic view of the problem.

Using the GOV.UK Design System we prototyped and tested options for the end to end tracking and management of leaks-related repairs. Through our new API, we were able to pull data from legacy databases into a responsive, one-page interface. This meant staff could quickly filter repair jobs by trade and identify repairs that might be related, making it easier to coordinate operatives, get leaks fixed quickly and reduce the amount of follow up jobs.

Through a series of sketching workshops, testing sessions and design iterations, we worked with service teams to create these prototypes. In a complex system, we’ve found that iteration is essential to draw out the nuances of user behaviour and make continuous improvements. Our designers spent time shadowing operatives, testing prototypes in context. Operatives work to tight deadlines, viewing and logging jobs on their phone as they plan their travel between jobs. They needed to trust the system to give them the right information, reliably and consistently.

Building trust

This kind of collaboration wasn’t always straightforward. Many stakeholders within the council had a sort of ‘Post It fatigue’ - they were fed up of being consulted and having ‘innovation’ done to them, rather than with them.

The teams we worked with weren’t familiar with our approach or Agile methodology. They were used to having off the shelf solutions that promise to do everything from the start. While they were experts in managing repairs, codesign and development was new to them. We needed to build up confidence in our approach and bring people on the journey with us.

Unboxed formed a single, integrated team with the Interim Head of Repairs as the product owner. We involved case management officers as advisors and Hackney ICT staff to support development.

We worked in 2 week sprints, adding new features sprint by sprint, and letting people see the impact of their involvement, rather than presenting a finished product at the end. All of this meant we slowly built up trust and engagement.

We used storytelling to share the experiences of different users within the services, helping wider stakeholders to understand what it was like to be working on the front line. At open sessions, we showed examples of the legacy systems, how case officers would have to jump between screens to find the information they needed. These stories were a powerful means of convincing stakeholders of the need for building a service around the needs of the people that use it.

Navigating a complex technical environment

The repairs environment is naturally complex. There are many stakeholders doing different types of jobs. For example, the Voids team focuses on managing repairs in empty houses to make them ready to let out again. Other teams work with properties that are occupied, supporting concerned residents who are trying to live in a property that needs repairs. Some teams work in an office, others are out on site.

Over the years, the use of multiple tools to serve these teams resulted in a very complicated technical environment. This kind of complexity rarely meets the needs of its users and often results in poor integration, increased manual tasks and greater chance of human error. Yet many councils are stuck with this kind of system as the software is too costly to replace. Often, people are hesitant to replace it for fear of everything ‘breaking’. Moving away from these systems can feel like a break up as staff are so used to doing things in a certain way and have an enormous amount of tacit knowledge of how that system works, even if it doesn’t work very well.

We spent time understanding the underlying database structure so that we could unlock data and deliver a technical architecture that worked for multiple services. We delivered design and development in two-week agile sprints, using a wide range of technologies (including Ruby, Rails, React, .NET, HTML, CSS, and JavaScript) and cloud-based AWS hosting and infrastructure, aligned with the Hackney API Playbook.

Defining MVP

We had to reassure Hackney that we could implement new and better systems without affecting day to day service delivery. We proposed a minimum viable product (MVP) approach, developing just enough functionality to make the system usable enough to test and learn how to make improvements. This comes with its own challenges, as different interpretations of what ‘MVP’ means meant that some stakeholders would still focus on the end result, expecting a finished product rather than an iterative process. We held regular scoping sessions to refine our shared definition of MVP. While these sessions could be challenging they helped us understand what we needed to prioritise to deliver value quickly.

Outcome

Unboxed successfully built and implemented a Repairs Hub that resulted in 75% fewer clicks compared to the legacy system and a 35% faster workflow. From the point that a customer reports a problem to the point of completion, repairs teams can track a job, see who is dealing with it and connect it to other reports.

The build, or ‘beta’ phase passed the assessment for meeting the Government Digital Service Standard. This means it meets best practice for an accessible service designed around the needs of the people that use it (back office teams, operatives and residents).

Unboxed extended the Hackney Repairs API with new endpoints, meaning that the council can develop interfaces for different teams that will seamlessly integrate with various housing data sources. This reduces development time and makes it easier to onboard more teams and services to the new system.

What we learnt

One of the most valuable activities for building trust was speaking to people ‘on the ground’ - we weren’t just making decisions with managers and directors. We were spending time with teams as they did their day job, giving them opportunities to talk and demonstrate the challenges they faced every day.

What’s next

Repairs Hub was so successful that Hackney Council then asked Unboxed to develop it for use by their Repairs Contact Centre, external contractors and for different types of repairs. Unboxed supported the migration of Repairs Hub away from legacy systems to a new, fully open source database and API, owned by Hackney Council. This reduced the council’s dependence on third party suppliers and gave them much more control over how their service is maintained, improved and delivered.