PROJECT TYPE

Bank, app, website

TEAM

1 Product Designer, 3 Engineers

MY 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 about 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:

1. A large proportion of dispute calls were not actual fraud or disputes.
   
2. Customers often:
   1. Did not understand pending transactions.
   2. Did not recognise merchant descriptors.
   3. Expected refunds to appear instantly.
      
3. The in-app dispute entry point was too easy to trigger without context, which:
   1. Encouraged premature disputes.
   2. Increased unnecessary call volume.

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.

OVERVIEW

Summary

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.