4x customers going all-in with thinkmoney
After onboarding, our customers are struggling to setup their accounts. Around 60% of customers that don't pay in funds close their account within the first 30 days. In the next 60 days that number is still as high as 40%.
To get the most value from a thinkmoney account you need to transfer over your payments, Direct Debits, and Standing Orders.
That way our budgeting engine can make sure your bills get paid on time every time. And the customer is getting the service they're paying for.
Owned by the onboarding and setup team. Their responsibility is to encourage customers complete their application and get it set up.
In the team we have:
- Product Manager
- Business Analyst
- Data Analyst
- Engineering Manager
- 4 Developers
- 2 QAs
- 2 UX Designers
My role is to help the team solve the problem through research, workshops, and design. I spoke to customers, ran the workshops, took the lead on wireframing, prototyping, and design.
We looked at the data we had for customers that were closing their account without getting properly setup. This data gave us some insight but it wasn't great. While it told us there was a problem it wasn't detailed enough to give us the level of insight we needed.
So the first thing we did, was to fix our missing data problem. This will help understand user behaviour better when we revisit this solution for another iteration.
The next step for us was to speak to to customers that had recently left thinkmoney, and find out why that was.
We spoke with 7 customers that had recently closed their accounts and asked them why.
The overwhelming theme in these interviews was that customers didn't understand how budgeting worked. And they didn't understand that transferring direct debits and standing orders made the budgeting system kick in.
When we workshopped ideas to solve this problem. The solution we felt was likely to have the most impact and was the least effort was to turn our existing manual Current Account Switching Service and automate it so customers can self-serve and are prompted automatically in the app. Here's the effort/impact scale we used to prioritise our ideas.
Following on from that we took the solutions that made it into the top left quadrant and created and assigned actionable steps for them all.
We got hold of the CASS documentation and met with the department in charge of processing these requests to talk about our approach and how the team felt it would be a good candidate to solve the customer problem.
We created some shorthand UI flows, a technique that comes from shape-up methodology, and workshopped the journey with the team.
Once we had a good idea of what we wanted to present, we created the wireframes and prototype in Figma.
We tested this with a small sample of users internally and externally to validate that it was clear what needed to be done, and that the process was simple.
With that success we began development work on the flow and built it in such a way that we could A/B test the feature to measure it's direct impact on customer attrition.
With an existing style guide to use as our starting point we're able to use a lot of existing UI components.
The initial release version uses a unique header image to create a visually interesting flow.
Some small changes to the copy alignment make the content much easier to read. And clear, fixed position call to actions buttons help guide the customer through the process.
We've also specifically added a page for sentiment gathering. If you decide switching isn't for you, we ask why so we can try and understand where we can improve timing, information, or anything else.
We rolled out the experience to a targeted subset of customers as part of an A/B test. We wanted to learn if adding this feature made it more likely for customers to keep their account open.
After 8 weeks we're now processing 4x the number of switch requests. And our data shows a 23% increase in the number of customers opting to use the switching service.