Sprint 2 – 9 September 2020

Another 2 weeks have flown by since our last update with lots being achieved. So lets get stuck into what we have done and what we have learnt.

We are still keen to understand what the repairs process is like at other Councils, and so would ask anyone who hasn’t already done so, from a Council, to complete a short survey – https://rebrand.ly/repairs-online-survey

During Sprint 2 we have:

  • Interviewed suppliers and council IT departments
  • Identified primary integration point for a product
  • Looked at potential approaches to adopting a common API
  • Reviewed the Hackney “Raise a Repair” codebase

Interviews with suppliers and council IT departments

During this sprint, the following interviews took place:

  • Northgate – one of the larger suppliers
  • Active Housing – a smaller repairs service supplier
  • South Kesteven District Council IT department
  • A Housing Association contact

The interviews were undertaken by a mixture of Unboxed and members from Councils on the project team. The aim was to understand more about the repairs booking processes and types of systems used, direct from IT departments, and possible integration and current processes from suppliers.

From these meetings, the team received a huge amount of data/information to process and go through, in order to help understand the feasibility of a common service pattern for all Councils.

Examples of the type of data discovered are (but not limited to) : type of repairs details needed in the system; eligibility criteria; linking back to finance and billing; Using a standard set of SoR’s to classify an issue; APIs.

Potential approaches to adopting a common API

During this sprint, two possible approaches were discovered in order to provide a common API surface for repairs.

Two possible approaches are:

  1. Build a connector on top of vendors existing APIs / web services
  2. Design an API that vendors adopt

Both would need further work and investigation in future sprints, however our initial findings, are that both are possible, just that the first is hard technically, as there are many potential housing and repairs management systems to integrate with, and the second is hard politically, as it may not be in vendors commercial interests to reduce lock-in.

Reviewing the Hackney “Raise a Repair” codebase

On a separate project that Unboxed work on, involving Hackney’s repair service, the team looked into what has already been created there, and used for this project.

It was discovered that the app that Hackney use does describe and diagnose a repairs issue, which was good news, as it meant for this project, we could re-use some of that front end logic already created, just with our own customisation.

Show and Tell

We had a great show and tell – really big thank you to everyone who attended, we really appreciate the engagement


The project team and Unboxed have continued to work in a great collaborative way, and we are starting to see results from conversations and investigations that took place during sprint 1 and 2. The team has already met to plan Sprint 3, and are eager to move forward, and continue to reach out to more suppliers and focus on the technical side to look at how something could be built in a testing environment.

Next Steps

  • Promote and analyse results of council survey
  • Supplier interviews (already in the diary) with Civica and Housemark
  • Council interviews (already in the diary) with Greenwich Housing IT team
  • Arranging more interviews with Capita, TotalMobile, repairs contractors, amongst others.
  • Reviewing technical documentation
  • Establishing costs of implementing pattern in existing systems