DAVID EATON: Right, hello everybody, thanks for joining us today for the third and final of our three lightning webinars of our Housing Repairs Online. I wanted just to do a quick few introductions as to who we are. I’m David Eaton, I’m a Client Partner at Made Tech. I’ll hand over to Fraser really quickly.
FRASER TRICKETT: Morning, or afternoon, even. I’m Fraser Trickett, Client Partner, similar role to David. Just to give some background for questions later on, I was also involved in local government for over 20 years. If there are any questions around how this fits in or existing processes, or anything around the background research to this, feel free to ask away.
DAVID EATON: That’s a good point. As we are recording the session, we will leave questions until the end once the recording has finished but feel free to ask throughout the webinar. You can use the chat bar as well. I’m going to run through a few slides before I hand over to Fraser, which is the more exciting bit.
I thought I would start with our mission, which is really simple, at Made Tech. We want to positively impact the future of the country by using technology to improve society. We think the software in local government is broken with exorbitant contracts, bloated products and failed needs. There has to be a better way.
We want to build disruptive new products that solve the shared challenges for local government. You are finding the same challenges wherever, whichever council you may be at. We want to free councils from the burden of vendor lock in, and we want to provide affordable products that we can build once and ship everywhere to deliver real value.
Our initial focus is on housing. We have carried out extensive user research. When we look at how repair reporting is handled around the country, we can really see evidence of these legacy systems that have been built without consideration for the resident.
There are three specific observations which are important to you today. Often, there is no online provision to log repairs. Which means an inconvenient call for the resident, and delays or long time periods for a fix.
Often there is provision, but it is poor, with clunky, inaccessible and confusing web forms, forms behind logins and pictorial triaging which offers a poor user experience and can’t be accessed easily on mobile devices. Or, if there is an online tool, it produces an email that still needs to be handled and rekeyed, requiring a heavy manual process for officers, with lots of back and forth to book appointments. Some of those may sound familiar to you today.
That’s why we have developed our SAS Online Housing Repairs. It is built on a user centred design. It is built on an intuitive and easy to use interface for residents, offering an issue diagnosis that allows for the easy triaging of un-urgent reports.
Being multi-talented, it is easy, quick to adopt, bringing a lower entry point cost with seamless upgrades. It is designed to deliver value from day one, helping councils achieve savings through channel shift, and bring efficiencies for officers.
Our Online Repairs conforms to the highest data security and interoperability standards, whilst meeting accessibility guidelines, being easily accessible to all users across a range of devices. We don’t want users just to have the latest, new, shiny technology to be able to use it.
Our user research tells us that forcing users to log in to make a non-urgent repair causes unnecessary friction. That shifts residents away from a self-serve channel back onto the phones or other traditional reporting routes that take longer, with higher handling costs.
It’s really important that residents are reassured that they are reporting through safe websites. We’ve built ours using the GDS design styles and patterns and this allows for a customisable template with familiar branding and council colours.
To create a works order, or to show customers live appointment dates, we integrate with housing management and scheduling systems, allowing data to flow seamlessly. You need your data to be able to get to the right place.
To give you, the council, the confidence and reassurance that help is on hand for a service area that is under tremendous demand, we offer a comprehensive support wrapper. Our commitment is continual product development, with all feature releases included in the annual fee, supported by research and feedback with our clients and their residents. Allowing us to keep ahead of changes in user expectations, or perhaps any legislation that comes in as well.
For example, in June we released communal repairs to complement residential, and we will continue to develop this based on some of the findings that we make throughout our user research.
There is a little bit more about that on our Roadmap slide at the end of the webinar, after the actual demo, that we will take you through. It’s worth noting here that what we have built for communal also supports leaseholder repairs as well.
Enough of the boring slides. I’m going to hand you over to Fraser, who is now going to share his screen, and he is going to take you through the demo. Over to you, Fraser.
FRASER TRICKETT: Cheers David. The promise of being exciting. I’ve got a lot to live up to here, but I will see what I can do.
Hopefully that screen has come through for people. Is that a full screen, or just the Repairs Online that you can see?
ANA SANTOS: It’s not in full screen. We can see the back of your calendar.
FRASER TRICKETT: Let me just try that again then. I don’t think that did what I wanted it to. Hopefully that’s coming through a bit better now. Perfect. This is our test environment that we are looking at on here. Just to replay a couple of bits that David said, what you are seeing on here is designed from the GDS toolkit.
It gives everybody that familiar look and feel. Residents are more comfortable with this look, and it builds that trust that this is a real and valid service that they are using.
As David also mentioned, we don’t enforce a login around here. The reason for that is that as also mentioned, this is built on user needs. What we found, after talking to over a hundred real council residents is that the number one barrier for them to using existing online council services is that they are forced to input a username and password.
We also know that if a customer rings up, there isn’t that same level of validation done there, so we are putting that trust back into the users.
Just to allay any fears for where this has been live and for authorities that have been running this principle prior to our product, we haven’t had any experiences around anybody creating rogue repair types without that log of logging in here. It’s a fallacy that people will be creating lots of different repairs to cause chaos with an authority.
However, this is a secure product so things like denial of service are monitored in here should anybody try to use it for that route.
Now into the exciting stuff. We have landed on this homepage where a resident can request a repair. Because there is no login, this can also be used by members of staff or family members and people in shared accommodation such as wardens.
What we try and do at this first point is just to call out for emergency repairs. We don’t want them to be using these services if they have something like a gas leak. It’s safer that they ring the authority or the emergency services.
When I click on this now, it does a check so that if I say that I can smell gas, it gives me the number to ring and also starts to call out some advice and guidance.
For the purposes of this demo I’m going to say it’s something else. As you can see, we have the ability to log communal repairs through this portal, opening that up for the use of leaseholders as well, so that they can use this tool.
I’m going to say this is not a communal repair. Now we get to the first bit of integration. We ask the resident to put in their postcode. That can look back to your housing management system or you can provide us with a list of the properties that you want to be able to allow repairs on.
It could be for example, that you want to exclude things that are under right-to-buy, and not allow residents to log repairs on those. That kind of work can be done with you.
So, I’ve got my postcode in here, it brings up the list of properties, and then we jump into the triaging process and the repairs. What we have done on here, after lots of testing with real users, people with different accessibility and digital literacy needs, is that the easiest and best way for residents to report a repair is using this textual process. It is nice and easy to use and understand and also translates really well for people that need other languages. It also integrates well with screen readers.
We’ve got a nice simple process. The resident first of all picks their room, I’m going to say it is a problem in the kitchen. They then get this next tier that is a higher-level grouping. If I say it is something like damp and mould and it was caused by a leak, we still class that as an emergency, so we give them the details to run through that.
This is customisable by each authority. I am going to say we’ve got a problem with the sink area, and then we’ve got the elements that are reportable underneath here.
As part of the config and setup, you can configure these end points to map to a schedule of rate that is relevant to your work. We know that there are over 2,000 authorities, you sometimes create your own, you can configure these in here. Ultimately, the SOR that is created at this point is used for the further integration to get the appointment time, length, cost, and the relevant trade.
I’m going to say here that it is a problem with pipe work. The resident gets the ability to enter some text, hopefully a bit better and more detailed than I am putting in here, and then gives you some guidance around the type of thing we are looking for.
They can also upload a photo that can be shared back to your systems as well.
I’m going to pick a photo, I don’t know if you can see that screen there. It’s worth calling out at this point that this is fully responsive design. We know that 70% of the time, residents are accessing services from a mobile phone. All of this scales back and they can use the real-time camera feature on a smart phone.
I’m going to upload that photo, it has been successfully uploaded on there, then the authority can use that information as part of the diagnosis process.
This first number that is called out for on here is utilised if we need to call back for information around the repair itself. The resident gets the option to have the receipt sent to them. That can be either sent by text message or via email.
If I continue on there, that is where the SOR has now been passed to whichever scheduling system you have. It’s pulling back real-time information for the relevant trade, for the appropriate amount of time to complete this work. It also displays the repair slots that are available. You can see that Saturday and Sunday are showing on here. Again, this is customisable, and is running off our test data on here at the moment. We can also utilise, if the software has logic built into it for showing only green appointments where it’s more effective, then we can leverage that functionality as well, so that it only displays those.
As a resident, I can pick the time that is most convenient for me, and I can request more days as well. I’m going to go for Tuesday 24th October. I then get a nice overview of all of the information that I’ve entered, and I get the ability to go back and change and update these if I need to as well.
At that point, I’m going to request my repair. That has then triggered a couple of bits of integration behind the scenes. One is to create the works order in the housing management system, passing that job number through to the scheduling integration and actually booking that appointment slot in the tradesperson’s diary. It has also triggered out that email or SMS depending on the information that was entered by the resident. They have this reference number in here should they need to make any amendments or speak to the authority in the future about the repair.
We have found that by sending that receipt, the resident is more informed about the process. On a telephone, after that phone has been put down, it’s reliant quite commonly on the resident writing that down or putting it into a calendar. Whereas, through this method, they have that thing to refer back to.
In early stages of our findings, it has started to drive down missed appointments because that resident has that better information to hand.
I’m just going to see if my email has come through and if I can share that. Hopefully you can see the reply on there. Here’s that information on the product, letting me know the appointment date and time. So, the resident is left with that information which is great.
I can go around that process again and report another issue. I’m just going to show you very quickly the communal repair process.
I’m just going to enter a different postcode for that. Again, this is integrating with the housing management system or flat file if you would rather provide that. It brings back only relevant addresses that are communal areas.
This is a different triage system, but it uses the same principles. I am going to say that there is a problem in the corridor or lift, that it’s a problem with the lift and it is out of order.
You can see on here that there is an additional step where the resident gets the ability to describe the problem in terms of the location. I get that ability to upload the photo. I’m going to skip that step for now.
They get the same functionality of providing a contact number should we need to get in touch around the repair, and also the receipt information. Then the summary information is displayed.
That repair request point on there, we don’t integrate with the scheduling software because quite commonly, these elements are passed out to a third party such as with lifts or fire alarms. This is then passed through as an email to the contact centre, for them to be able to book this information in. We can look at doing integration, if need be, through this route.
At that point I will stop sharing. Back to you, David.
DAVID EATON: Yes, thanks Fraser. I think there is just one more slide we were going to share. I think it is important to let you know that our Housing Repairs is live with Redbridge Council. We are just onboarding Camden right now. Different systems that we integrate with in both councils, of course. We are talking to lots of other councils as well, which is great.
Here is a really quick sneak preview of our development roadmap. I think it’s important to say that we take an agile approach to our product development. That is driven by user research, feedback and suggestions from our customer to help us prioritise our focus.
That user research has been something that we have talked about quite often throughout this webinar. On our Roadmap here, you can see some of our initial thoughts. We know, as we have already explained, that the quality of information that the councils receive is limited by poor reporting processes.
We want to empower residents – they are, after all, your eyes and ears on the ground – by improving the data that they send you. Uploading photos helps improve the diagnosis accuracy. That leads to speedier resolution times and increased first fixes. Fraser has shown you this already. We should be in a position to release this very soon. There are just a couple of things we are looking at now around P2.
We already integrate with scheduling systems to choose live appointment dates. Obviously, resident’s circumstances change, so we will be adding the ability to reschedule or cancel appointments online, and therefore reduce that demand on contact centres.
Following our communal repairs research, there are a couple of areas we want to start designing. Firstly, offering residents a view of already reported issues, to reduce duplicate reports. That is a big thing, a big thing that was thrown up from the research.
Secondly, keeping residents up to date about the progress of an issue, close that feedback loop and take away the demand on call centres. So, we are going to be looking at those two areas in the next column over the next few months.
Further round, you can see in the other column there that we will be looking to prioritise areas such as for example chatbots, resident satisfaction, AI assisted diagnosis. Again, that column, the items in that column there are very much led by what we are finding in our own research but also, what our clients are saying they want us to focus on.
Onto the final slide, which is the end of our session.
We would love to hear your thoughts on what you have seen or heard, or anything that you think we are missing. You may well have undertaken your own research for your own repairs and think, well actually, there’s a big gap over there.
I think it’s worth pointing out right now that we have also conducted extensive research on voids, and how we can reduce the re-let times for vacant properties to increase the revenue for councils and bring that revenue forwards for them. Really importantly, to get residents back into their homes quicker.
We’ve got about ten minutes left of the session available if there are any questions you have. I don’t know if any have come through the chat? Over to you.
ANA SANTOS: I would like to go over a few of the questions we got asked in a few of the previous live webinars, if that’s okay.
Fraser, would you be able to tell me what work has been done to make sure that Housing Repairs meets the needs of end users?
FRASER TRICKETT: Of course, Anna. What we have done in this area is engaged with real tenants. By that, I’m talking about people that actually live in council properties, that have to log repairs day to day in their properties. We have engaged with different spectrums of people with digital literacy needs, people with accessibility needs and people with different cultures and backgrounds. What we have done with that information is feed it all into the design of the product, and made those iterations based on that genuine feedback from those residents.
ANA SANTOS: Thank you, that makes sense. Another question, Fraser. Why doesn’t Housing Repairs require users to login? Is it related to the needs of the end users?
FRASER TRICKETT: Exactly that. The number one frustration and friction point from residents for accessing council services, with the over a hundred that we spoke to, was that having to remember a username and password to log a repair was the number one barrier to them doing that online.
ANA SANTOS: Thank you, makes sense. David, can you tell me why RSS products are a good choice for local authorities and related to that, why is Housing Repairs a SAS product?
DAVID EATON: Yes, absolutely. We think that SAS products are good choices for local authorities because they are easy to adopt and easy to roll off from. They are very easy to deploy, and they are affordable as well. We know that councils are really struggling with finance.
ANA SANTOS: Finally, Fraser, the last question. How customisable is the product?
FRASER TRICKETT: There are two key elements that are customisable by you as the authority. That is the colours and the CSS on here. You can do your own logo and branding on there. More importantly, in the triage system you can add your own schedule of rates to each of those end points. There are over 2,000 schedules of rates in the Nat fed book and councils quite often create their own versions of that too, so all of those elements are customisable.
I think it is worth calling out that we don’t allow customisation of the elements that we have tested with users. The language and tone in there are part of the reason that we control and deploy that through SAS, so that you are always benefitting from that latest feedback from residents.
ANA SANTOS: Perfect, thank you both, that is all for today.
Back to the episode
