Simplifying transaction disputes with banking agent assistance
Overview
Sidekick is a CRM that helps users (banking agent) assist their customers (cardholders) when they have any concerns about the card or banking account.
Challenge
Currently whenever cardholders want to dispute a transaction, agents have to manually collect information in Excel file, which is a daunting task.
Goal
Find a solution to reduce effort for banking agents when it comes to supporting a dispute request from cardholders.
A bit about us….
Christmas was coming in but Margie were still occupied with Sidekick. She's a busy business analyst and the project is one of those that receive so much love from our clients. We'd been building it for more than a year and glad to say we nearly made it till the end.
I remember the weather was crazy in Dallas that day 🌦️. We were in a meeting room waiting for our client - Jenny to join the call. Today, we would be making the final feature for Sidekick and then we could proudly wrap it up.
Jenny had been with us since the beginning. She worked as a banking agent for more than 10 years (I don't know if she still does…). This time, she shared about her task called "Dispute transactions" which was daunting to her. And it's also the one that you're about to see in this case study.
01
Discover
Learning from research
Margie was quite knowledgeable about the field, unlike me. I didn't know much about the term "disputing a transaction" so Jenny decided to walk both of us through the process of how she assisted a cardholder in this case.
Basically, "disputing a transaction" refers to a situation where a cardholder disputes a charge on their card because they believe the charge is fraudulent, unauthorized, or not what they expected. They would make a call to the bank where a banking agent would help them with this case.
What I noticed obviously from what Jenny said was that as a normal banking agent, she wouldn't be involved in the process of investigating the validity of disputed transactions. What she did was to collect related information and make a request so another agent in the Dispute Solving Team could proceed from that.
Her biggest problem was that while authenticating and referring cardholders' information on Sidekick, Jenny would use an Excel file to note down dispute requests. There were a lot of details she would need to record before submitting it to the solving team. And this was daunting because Excel wasn't a ideal tool for that. Another big problem was that the Dispute Solving Team had their own system to keep track their progress. Therefore, when cardholders wanted to know how their request was going, Jenny didn't know how to answer them.
I also listed out other minor pain points that she encountered in the Persona.
02
Analyze
User journey
After the call with Jenny, I started to map out what actions she would need to take to complete, some pain points she might encounter while performing those tasks and the opportunity for us to create.
03
Ideate
We had a discussion with the product team to ideate how to solve problems for Jenny. At first we were thinking about building a solution for a whole dispute process on Sidekick. However, that idea means to involve the Dispute Solving Team into the app, which might cause difficulty to them. Therefore we ended up with only implementing the feature "making dispute request" on Sidekick. Then we would integrate Sidekick with SESS system. This means:
Jenny would collect information and make a dispute request form on Sidekick
When she submits the request, it will be synced in SESS system where the Dispute Solving Agent would normally work on.
When they review and investigate the request, they would update the status which now will be synced back to Sidekick
By doing this, we can remove Excel from the process. Jenny can use Sidekick 100% to perform her tasks, which reduce the effort of working back and forth between Sidekick and Excel. The Dispute Solving Team can still use their own system (SESS) and won't need to get back to updating status on the Excel file.
Margie and I got back to Jenny 2 days after that. We presented to her about what we would plan to do and she finally saw the potential that her problems could be fixed. Jenny had shared the process of transaction dispute in the previous call, everything in a high level (as you can see on the user journey). Now we knew what to do, and what we still cared then was the detail of what she would collect from cardholders to make a dispute case.
Cardholders might have thousands of reasons why they want to dispute a transaction. But for Jenny, she always categorizes them into 2 main types:
- Merchant dispute (D type): cardholders made a transaction intentionally. It can be a payment for a purchase. Now they want to dispute it because what they bought doesn't meet their expectation.
- Unauthorized (U type): cardholders didn't make a transaction. The card was stolen or lost and someone else did.
The reason why Jenny had to categorize them was because each of the type would require her to collect different piece of information to make a dispute request.
User flow
I started to create user flow. In this case, since users are responsible with both creating new request and following-up, I made two separate user flows.
04
Design
Create a dispute request
In the Dispute request page, users can see cardholder snapshot and the comment section. This lets users know the basic info of the customer they're supporting and also what other agents mentioned about them in previous calls. User can start creating a new dispute request by clicking the button on the top right.
How might we make it easier for the agent to gather transactions for a dispute request?
On the Case basic info, user would need to categorize the request (type D or U) and enter some other information.
According to Jenny, cardholders might have multiple transactions disputed in one request. Therefore, I made the page into two big sections. The right one is for transaction selection, the left one is for reviewing those that they pick.
How might we reduce the likelihood of not collecting enough dispute info?
For each transaction selected for the request, users would enter the reason for it, which will generate corresponding info. Basically, we now create a condition between the reason and the piece of information. This is helpful because the agents won't be worried if they miss any details.
How might we make the collected information intuitive so that users can find it easy to preview?
How might we reduce the step of manually noting down the cardholder's shipping address
I summarized all dispute information in the Preview page so users can take a look at all once more time before submitting the request. I also let users review cardholder's shipping address since the document will be mailed to them. Users can update shipping address if their customers want to. This navigates users to the Address page which has already been built in Sidekick.
Follow-up a dispute request
When a dispute case is created, banking agents can find it in the Dispute Case List. They can view detail by clicking on it.
How might we simplify the task of updating the dispute progress so that Sidekick agent can check in case the cardholder calls back?
As mentioned earlier, since Sidekick now is integrated with SESS, every time the Dispute Solving Team updates their progress in SESS, the status will be updated in Sidekick also. Banking agents can now answer their customers when there are any concerns regarding the request.
Jenny also helped us with some clarifications. When a request is made, it cannot be deleted by banking agents. That's why in Dispute request details, we don't see any way to delete it. That makes sense to me because at this stage, banking agents are no longer involved so much. The case is being in charged by Dispute Solving Team. Therefore, they will mark it as CLOSED if needed…
05
Evaluation
On dispute preview page
After a month launching this feature, we received positive feedback from users. However, they are some points that need more enhancement. We noticed that banking agents tended to forget to verify the address with cardholders. And that could cause some problem when documents couldn't be delivered to cardholders.
In order to solve this, I decided to add a header to separate the Mailing section from Dispute Preview. I also added a checkbox so force the address verifying action from users.
On dispute details page
On the dispute details page, some agent wanted to know whether the Dispute Solving Team engaged on the process or not. That would help them to easily follow-up with the request and support their cardholders. Beside, they couldn't regenerate the form when there was any updates on the dispute transactions.
In order to solve this, I added a progress indicator. When a Dispute Solving agent is assigned for request, the progress indicator will move to "Dispute case processing". I also added the button "Regenerate dispute form" so banking agent can print it out and mail it to cardholders.
Lesson Learned
Working on this feature has helped me to gain more insights about banking activity. I learned how to empathize more with what our clients struggled. We also accepted the fact that we didn't have chance to reach more banking agents in Discovery phase since they were busy with their daily tasks. However, we could test the usability when the feature was launched and it was interesting to see how they gave feedback on it.