After onboarding, our customers are struggling to set up their accounts. Around 60% of customers who don't pay in funds close their accounts 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.
Team
Owned by the onboarding and setup team. Their responsibility is to encourage customers to 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, and took the lead on wireframing, prototyping, and design.
Research
We looked at our data for customers who were closing their accounts without getting properly set up. 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 fix our missing data problem. This will help us understand user behaviour better when we revisit this solution for another iteration.
Our next step was to speak to customers who had recently left Thinkmoney and find out why that was. We spoke with seven customers who had recently closed their accounts and asked them why.
Pain Points
The overwhelming theme in these conversations 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 that, we took the solutions into the top left quadrant and created and assigned actionable steps for them all.
Validation
We got hold of the CASS documentation and met with the department in charge of processing these requests to discuss 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 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 its direct impact on customer attrition.
Design
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.
Results
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 accounts open.
After eight 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.
