So its our final sprint, as a project team we cant believe how quickly the time has flown by. We have learnt so much during the time and hope, for those of you that have followed us, that you have found it useful and interesting.
In particular we have found the collaboration between the partner councils and Unboxed to have worked really well, especially given the difficulties of remote only meetings. If there has been anything we have learnt from this digital fund project, it is that there is so much we can learn from and help each other. In honesty we are all quite sad to be nearing the end of the project.
During this sprint we have:
- Completed interviews
- 1 housing management system provider
- 1 repairs management system provider
- Ran a session for suppliers with TechUK
- Added communal repairs to our prototype
- Described the API calls required to support the service pattern
- Started work on the alpha report
Events
We co-hosted (with MHCLG) a session for TechUK suppliers, the aim was to understand the role suppliers can help play in scaling transformation and digitising how social housing repairs get reported
This event centred on 2 workshops:
- The 1st workshop involved the attendees discussing their experiences dealing with councils and the social housing sector.
- The 2nd workshop was around what this project could deliver that would be of value to their companies. Elements such as service patterns, API design, common connectors for API’s , open source and “white label” repairs ordering products were debated.
These workshops highlighted the importance and impact that an introduction of standards would bring to the sector. The adoption of a common service pattern and reporting product would be much easier if a common API and reporting method could be agreed.
Interviews
We virtually met with Orchard with a mixture of Unboxed and members from Councils on the project team. The aim was to understand more about the repairs booking processes and how their system could be used with our CSP.
A recurring message from our supplier interviews was that Councils ask for authentication to log repairs, driven by a risk adverse nature. In addition, the numerous implementation methods of SoR’s further drives disparities between Council configurations.
It is also clear that often systems and processes are built around the needs of councils, not residents.
The role of SoR’s
What might seem like a standard for reporting repairs appears to be anything but. As previously mentioned out of the 4 partner councils only 2 used the standard schedule of rates, and of those used only 12 were common in the top 50 uses. This is a recurring theme in the responses to our surveys, we all seem to have adopted either a different subset of the codes, created our own set, or a mixture. Although the use of SoR’s can be useful post completion the project is questioning their effectiveness at the reporting stage and found generating a specific SOR code involves more complex diagnosis. Doing this online pushes responsibility onto tenants, increasing risk of error.
When logging a repair, we only need to know 3 things. The property, trade and estimated job duration.
We are also investigating how technology may help in diagnosis, using video call inspections and better asset management meta data.
API’s
We have described the API calls required to support the service pattern.
We know the service pattern requires each council’s backend system to respond to three main messages:
- Return (GET) a set of eligible addresses for a given postcode (so the user can choose their property)
- Return (GET) a set of available appointments for given repair information – results paginated
- Make (POST) a booking for a repair with given repair, property and supporting information – and send back a reference code and confirmation of the times
An initial version of this has been specified here, which shows each message along with example arguments and return values.
Thinking about options
You can hear about the pros and cons considered for each in the show & tell
Support what’s available
There was willingness amongst smaller suppliers to adopt the service pattern where possible. They should be supported in doing so and guidance should be produced to support their conversations with clients..
Build a new product
Create an open source repairs ordering and tracking product. Over time this could be expanded to cover more of the repairs journey for council staff and demonstrate new ways of working.
Design a common API
Design a common API schema for repairs that system suppliers could implement in their products to improve interoperability.
Build a common API connector
A common connector could help share data between systems. This requires back-engineering APIs onto existing web services, but the concept is proven at Hackney and Bristol Councils.
Alpha Report
We have started work on the Alpha report and the recommendations from this will determine the future of this project. The report will be available on the website once finished.
Final Show and Tell
The final ‘Show and Tell’ was well attended, with good representations from all the Councils involved and interested parties. We thank everyone that has taken the time to support this project, your time and input has made the outputs of this project possible and has given us real insights and options for progress.
We hope that we will be able to make real improvements to repairs online as a service and look forward to working with you again soon.
Repairs Online 