At the Service Innovation Lab, a multi-agency team from across Local and Central Government got together in September 2017 to collaboratively work on a Rates Rebates Discovery.
'Rates Rebates’ is a subsidy (up to $620) for low-income homeowners on the cost of their residential rates. The subsidy is delivered by Local Councils and is administered by Central Government (specifically the Department of Internal Affairs).
In the Discovery phase there were a number of opportunities identified for service improvement. We also identified barriers from the prescriptive legislation, an Act written in 1973, that impacted what is possible for digital service delivery in 2018. From this we were able to set a goal of what we could create for a minimum viable product (MVP) for a better Rates Rebates service to bring into the Alpha stage of testing. This Alpha service has been designed to help make it easier for people to identify their eligibility and then apply for the rebate with less effort and stress. It was also designed to simplify service delivery for the council from the current very manual and paper heavy process to a simple, faster and digital service.
In our Discovery, we tested concepts with ratepayers showing different levels of proactive delivery. The majority of those we spoke to preferred the concept that had some proactive delivery, but had a process of consenting to ensure that they retained control of the situation, rather than having the rebate automatically applied. This was an important factor in designing an MVP as we move into the Alpha stage for Rates Rebates that doesn’t assume a fully proactive delivery in order to meet user expectations of maintaining control throughout the process.
We knew that we wanted to improve the service for people, and some constraints from the Rates Rebate Act meant we weren’t able to completely flip the process on its head. The Rates Rebate Act requires the applicant to submit a form, which is then signed and witnessed by an authorised person, usually a service centre staff member at the council when an application is submitted, similar to a statutory declaration.
With this knowledge, and knowledge of digital best practice, we were able to set our goals for a MVP. We assembled a team of subject matter experts from the initial discovery team, and brought on developers to help make this digital service a reality. This includes Auckland City Council, Tauranga City Council, Department of Internal Affairs, and the Service Innovation Lab team.
We dived even deeper into understanding the service delivery and what is possible. By examining legislation, tech systems, and modes of delivery we created detailed service blueprints of the current and future states, testing them against each other and our goals for the service improvement. We looked into how data was being submitted by ratepayers in their paper applications, and what forms this data took when digitised, transported, and processed. We looked over the form and worked on how the language could be improved to be more plain English, and how form fields could be made easier to complete. For example, when asking an applicant's income, we could provide an option to press a button to state that they are receiving NZ Superannuation, rather than asking them what dollar amount that is, as we already know the figure.
We are now in the process of building the MVP and will be testing with ratepayers and service delivery staff to ensure that the digital service flow is understandable and makes sense to those who use it. The code we are building is also open source. We are also able to leverage provisions in the recent Contract and Commercial Law Act 2017 to use digital signatures which is quite important.
This Alpha process of building and testing the service before a full launch allows us to see how a service can function in real life, test assumptions, test how we can iterate the systems and processes in place, and find issues and opportunities for improvement before a service is launched. This process is invaluable for identifying risks and mitigations before a service is delivered. This also means we can rapidly iterate, challenge our assumptions, and find out if an idea will be a success before investing in it’s full delivery. Running an Alpha is like running a pop-up coffee cart to see if people will buy your coffee before you build a cafe - if no one wants your coffee you will know not to build the cafe.
We will post regular updates on the Alpha as it progresses.
If you wish to know more about the process and the project, please feel free to get in touch with email@example.com