Rates Rebates Discovery Week 2 – mapping pain points

TL;DR

Within the Service Innovation work program at the Department of Internal DIA, we have a range of service delivery initiatives where we work collaboratively with other agencies, organisations and companies in our Lab to design, prototype and build better public services. This helps us to identify user needs without a specific agency or government view, as well as to identify reusable components that could support multiple services (in public and private sectors). A couple of weeks ago our team kicked off a three week discovery sprint exploring how subsidies are provided to New Zealanders and what this could that look like in the future, with a focus on Rates Rebates.

In this post we outline some pain points and "Aha!" moments we found. Please find all the Rates Rebates related posts from LabPlus here.

Making a Map

An important part of this week's work was to understand the entire process flow. We are creating a living document that aims to represent the process, people involved, the pain points and the inefficiencies. This will not only create a useful artefact at the end of the process but will also aid in the cross-pollination between organisations. We will publish this in the coming weeks after we have tested and validated it with users.

Multi-level definition of pain points

Previous work in this area highlighted a number of pain points from the applicant's perspective; these pain points have continued to come through strongly in our findings to date. Additionally we are collating pain points from council and agencies involved in the process.

A sample of our findings:

User Pain Points

Becoming Aware

  • Lack of awareness across the eligible groups
  • Hard to find information about eligibility and interpreting that data
  • Can forget to apply at the right time
  • Stigma in talking about it
  • Lack of awareness/clear expectations of timeframes
  • Not clear who owns the process and where people should start as there are lots of different government agencies involved (local and central government).

Receiving the form

  • Hard to find the form online
  • Need to physically pick up the form from councils or their offices
  • Same form for new applicants and those reapplying
  • Expense of the journey to pick up the form.

Filling out details

  • Having to reapply every year despite situation not changing
  • Form is hard to understand
  • Small print is hard to read
  • Having to get help to complete the form.

Finding more information

  • Not sure why so much information is needed to complete the process
  • Waiting time.

Completing the Statutory Declaration

  • Inconvenient to find, and go to, physical witness
  • Justice of the Peace overburdened by requests to witness declarations
  • Travel time and expense
  • Whether requiring a witness to the declaration adds any value.

Submitting the form

  • Travel time and expense
  • Customers sometimes submit the form twice in one year
  • Customer doesn’t know what is happening with their application.

Council pain points

  • Resourcing and finding space for extra service points to manage influx of applicants
  • Customers want to know the effect on their regular payments as it is not on council letters
  • Double handling of applications between councils and DIA extends processing timeframes
  • Customers don’t understand eligibility rules, income definitions and timeframes.
  • Staff are often filling in most of the form for customers
  • Many customers apply twice in one year. Once ~ August another ~ February
  • Confusion around difference in rating year, calendar year, tax year
  • Customers confused by financial declaration, what are they are declaring and why e.g. superannuation
  • More staff required to reduce queues in Customer Service Centres
  • Processing systems crash and/or cause delays
  • Visually checking form is filled correctly takes time
  • Staff watching people sign forms is "not core business”
  • “Wouldn’t it be great to not need a 50 page handbook” to understand Rates Rebate Act (1973) and DIA rules
  • Resource heavy (storage, scanning, lots of paper letters)
  • Manual data entry, very time consuming
  • Postage costs of batches to DIA
  • Processing refunds to those in credit
  • Many types of payments to process:
    • Direct Debit coordination
    • Spreading payments on rate payer's account
  • Contact with applicant is only done via post - high cost and not eco-friendly.

Agency Pain points

  • Few inconsistencies found during audit
  • Councils not referring to the handbook before contacting DIA
  • Inconsistency between councils' processes
  • Sending piles of paper to and from various locations - nothing digital
  • Complex queries requiring interpretation of the Rates Rebate Act can be very difficult and time consuming as it is vaguely worded in places. Can require advice from legal team.
  • Confusion around who applicants should contact - DIA or Council
  • Huge amounts of paper handling
  • Lawyers often make enquires about income rules in regards to trusts. Trusts add complexity to auditing applications and create questions around hidden income
  • High waste and cost
  • Easy to get staff up to speed on auditing but much more difficult to train them in answering enquiries competently. They have often moved on to another rotation before reaching a satisfactory level
  • Can feel pointless, extremely repetitive and dull
  • Staff rotate into role for short time periods
  • Liaising with suppliers to get new forms, posters etc printed
  • Rebate becoming harder to get as income and dependents amounts are being out paced
  • Claims can be misplaced or missing from batches
  • Lots of technical support (largely a fault of the outdated processing system)
  • Paying for the storage and recall of files
  • Cross checking funds received with funds expected
  • Lots of back and forth between council and DIA when issues arise
  • High level of staff training, especially in August - October.

Uncovering complexity

The collaborative analysis of these pain points and our teams process mapping is bringing to the surface the complexity, multiple handling, and lack of verification of data and the need to build bridges over the process silos.

"Aha!" moments

Although our discovery has only just begun we are already collecting “Aha!” moments. A couple of examples are:

  • “Differing understandings of the eligibility criteria definitions, eg What income is included? What is an Owner/Occupier? Who is a dependant?”
  • “The complexity of the process gets in the way of people applying and the central and local government agencies efficiently processing”
  • “There are two applications here, one between the resident and the local council and another between the local council and Central government”

Whats Next?

  • Continue to gather and analyse insights from agencies providing the services and resident applying.
  • Continue to form our global trend picture
  • Socialise our initial thought concepts

If you would like to be involved in our research please email us.

3 comments

  1. Comment #1. Phinny Didla:

    I am no expert in IT to comment, but I have seen clean, clear, plain english and it made me curious to read. I’ve read User pain points and I will read Council and Agency pian points. They do look too long to read but I will give it a try. I would like to be involved in your research or do you want me to contact your research email- serviceinnovation123@gmail.com

  2. Comment #2. Clare Toufexis:

    Another great blog Pia, nice work!

  3. Comment #3. Pia Waugh

    Thanks Phinny, in the first instance we encourage people to drop in to our Friday OpenLab events in Wellington. If you aren’t in Wellington, then join our mailing list and feel free to email. We are still spinning up our work program and team cadence so there will be more opportunities to get involved over the coming months.

    Cheers,
    Pia and the LabPlus team

Leave a Comment

Your email will never be published.

Your comment may include these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Your comment will be held for moderation before being published.




Navigate Posts