Solving the disputes problem for CBA.
CATEGORY
Bank, app, website
TEAM
1 Product Designer, 3 Engineers
ROLE
Lead Product Designer
TIMELINE
6 weeks
OVERVIEW
While working at CBA I was tasked with reducing calls regarding transaction disputes.
MY RESPONSIBILITIES
I ran the research, design, and testing of this crucial Netbank and CommBank app feature.
OBJECTIVES
Business objectives
The customer service centre was receiving a high volume of calls related to transaction disputes. Many of these were not true disputes, but confusion about pending transactions, merchant names, or expected refunds.
This was creating:
- Long wait times for customers
- High operational costs
- Frustration for both customers and support staff
IMPACT
Turning the experience around
A huge increase in successful onboarding, higher transaction rate, and reduced churn.
23%
Reduction in dispute-related calls
17%
Fewer unnecessary disputes being raised
Improved
Clarity for customers around transaction status and refunds
DISCOVERY
Research participation
Instead of relying only on reports, I went directly to the source of the problem.
- Spent time at the customer support centre in Parramatta.
- Sat in on live support calls with agents handling dispute-related enquiries.
- Listened to multiple call types, including:
- “I don’t recognise this transaction”
- “Why is this still pending?”
- “Where is my refund?”
- Spoke with agents between calls to understand:
- Common call drivers
- Where customers were getting confused in the app
- Which issues were true disputes versus simple misunderstandings
This gave me first-hand exposure to real customer language, emotions, and behaviours.
DISCOVERY
Synthesising insight and data
I combined:
- Call centre observations
- Call-driver reports
- Existing product analytics
Key insights:
- A large proportion of dispute calls were not actual fraud or disputes.
- Customers often:
- Did not understand pending transactions.
- Did not recognise merchant descriptors.
- Expected refunds to appear instantly.
- The in-app dispute entry point was too easy to trigger without context, which:
- Encouraged premature disputes.
- Increased unnecessary call volume.
PROBLEM
Problems in the disputes process
These three issues drove almost all the unnecessary disputes calls.
PROBLEM
Unfamiliar business
The main driver of dispute calls were customer facing business names not matching registered trading names.
PROBLEM
Lack of guidance
Customers were unsure what options they had before calling. Rather than a last resort, the call was their first choice.
PROBLEM
Anxiety after dispute
Customers would make follow up calls due to lack of transparency about the disputes process and timelines.
RESEARCH
Synthesising insight and data
Using these insights, I redesigned the disputes flow with a focus on education, clarity, and deflection of unnecessary disputes.
Key changes included:
- Provide suggestions to help a user understand more about a transaction
- Asked why customers were making a dispute
- Clearer outcomes and expectations
- Explained what happens when a dispute is raised.
- Set realistic timelines.
CONSTRAINTS
UX phases and opportunities
I identified the three key stages of the customer user journey, and how we might assist them at each step.
BEFORE
Educate
Reduce disputes by helping customers better understand unfamiliar transactions.
DURING
Assist
Make lodging a dispute straightforward and transparent.
AFTER
Reassure
Reduce follow up calls by explaining the disputes process and give estimated timelines.
DESIGN
Mapping the journey
I mapped my proposed user journey to better understand the logic and potential pain-points. This would also help with dev hand-off.
DESIGN
Early prototype
How might we help new enterprise teams confidently move forward by clarifying where to start and how work flows across the system?
CONSTRAINTS
Risk concerns
The initial solutions made it too easy for a customer to lodge a dispute, and was flagged by risk. I added more friction by asking them to confirm they had:
- Tried to contact the business
- Checked that the payment wasn’t pending
- Asked their partner/SO if they had made the purchase
- Understood that transactions were often processed several days after the actual purchase
TESTING
Implementation
User testing
I built 4 different prototypes in total, refining them after each user testing session based on observed behaviour, user feedback, and business feedback.
Results
The final prototype was implemented into the app and Netback experience after multiple rounds of in-app testing.
DESIGN
Final designs
User testing
I built 4 different prototypes in total, refining them after each user testing session based on observed behaviour, user feedback, and business feedback.
Results
The final prototype was implemented into the app and Netback experience after multiple rounds of in-app testing.
IMPACT
Results
Validation
- Reviewed call-driver metrics after release.
- Monitored dispute initiation rates and related support calls.
- Gathered feedback from customer service teams.
Results
- Reduction in dispute-related calls to the support centre.
- Fewer unnecessary disputes being raised.
- Improved clarity for customers about transaction status and refunds.
SUMMARY
A successful solution
CBA were seeing a high volume of dispute-related calls into the customer service centre. Instead of just reviewing reports, I spent time at the Parramatta support centre sitting in on live calls.
What became clear was that many of these weren’t true disputes – customers were confused by pending transactions, unfamiliar merchant names, or refund timelines. I used those insights alongside call-driver data to redesign the disputes flow. I added clearer transaction context, a short decision tree before the dispute form, and better expectation-setting around refunds.
After release, the bank saw a reduction in unnecessary disputes and a drop in related support calls, which improved both customer experience and operational efficiency.
Selected Projects
