What we’ve been doing this sprint:
Again we have had some great discussions with suppliers to understand how their products might support our development and to identify potential barriers. A big thank you to everyone that has taken the time out to engage with us in such open discussion. In this sprint we have spoken with:
- Total Mobile
- Active Housing
- Smith and Byford (repairs contractor)
- OCO (repairs contractor)
Using the data in the surveys that have been completed and using the 4 partner authorities we have confirmed there is a wide variance in their use:
- Of the four partner councils only two of us are using nat fed SoRs for categorising repairs. Looking at our top 50 used codes we only had 12 overlapping codes.
Out of the 12 councils that responded to our survey:
- 4 use NHF SoR codes (but they could vary which they use)
- 6 use a mixture of NHF SoR codes and their own codes
- 2 do not use NHF SoR codes at all
Questioning the purpose of SoR codes they are important for the council (e.g finances), but less so for residents (reporting repairs). So is there a better way to diagnose repairs that makes reporting easier?
Knowing councils have very different implementations for SoRs (or equivalent), we will offer a level of customisation in any product that we prototype, however a level of compliance will be required. Allowing too much flexibility could allow a diluted version of the CSP, moving away from the importance of delivering to customers needs.
We have had some long discussions on the importance of being able to report communal and lease holder repairs in the product. We concluded that an MVP that only allows the reporting of selected “simple” repairs could undermine the value of the service. Even if we at least match the existing back-end service for more complicated cases, such as communal repairs and leaseholders, allowing the reporting of such repairs would build resident confidence in the tool.
We did reach out to some of the suppliers we have engaged with to see if a sandbox environment could be created for us to test integration. Unfortunately due to the tight timescales of our project this isn’t something that can be achieved.
Some of the other things we’re thinking about… 🤔
- How can we ensure consistency in the way repairs are logged, regardless of whether it’s online or over the phone?
- Who else could use the ‘Report a repair’ service?
- Customer service agents
- Tenancy officers
- How do ‘self help’ tutorials play a part? style guidance for simple repairs? E.g. how to fix a broken toilet seat.
- How could the pattern support further innovation in the repairs world?
- Video appointments with operatives
- Internet of things devices for e.g leak detection