Overview

Sidekick is an internal CRM used by frontline banking agents to handle card and transaction-related inquiries. At the time of this project, dispute handling was not supported inside Sidekick. Agents had to manually record dispute cases in Excel and pass them to a separate Dispute Resolution team. Case status was managed in another system (SESS), which frontline agents could not access.

This created delays, duplicated work, and limited visibility when customers called back to check their dispute status.

The goal of this project was to introduce a structured dispute flow inside Sidekick to better support agents in managing and tracking dispute cases.

My role

Sidekick evolved in two phases:

Phase 1 (2018–2019): I contributed to the foundational features of the CRM alongside a senior designer, focusing on core agent workflows and interface patterns.

Phase 2 (2019–2020): I became the primary designer for Sidekick, leading requirement clarification and end-to-end UI design across new feature initiatives. The Transaction Dispute feature was initiated during this phase while I was based in the U.S. I worked directly with the Business Analyst on requirement definition, facilitated clarification sessions, and joined live calls with frontline agents to understand real workflow constraints, something that was only possible while operating within the same timezone.

Objective

To achieve this, I focused on three core objectives:

• Build a structured dispute intake flow
• Create a transparent case tracking system
• Reduce cross-team friction by clarifying ownership and workflow transitions

Success metrics

To ensure the solution delivered measurable impact, I defined clear operational success indicators tied to efficiency and workflow clarity:

• Reduce average dispute intake time
• Reduce incomplete or incorrect case submissions
• Reduce status-related escalations from frontline agents

Hypothesis 1

We hypothesized that embedding a structured, logic-driven dispute intake flow directly within Sidekick would reduce average dispute creation time by 20–30%, as agents would no longer need to mentally track conditional data dependencies during case creation.

Hypothesis 2

We hypothesized that introducing conditional required fields and real-time validation rules would reduce incomplete or incorrect dispute submissions by at least 25%, improving downstream processing efficiency and reducing rework across teams.

Hypothesis 3

We hypothesized that providing centralized, real-time dispute status visibility would reduce status-related escalations from frontline agents and improve case tracking confidence.

Build fully inside Sidekick vs Partial Integration

However, addressing the dispute intake problem required more than a feature decision, it required a system-level architectural choice. The BA and developers needed to determine whether to consolidate the entire dispute lifecycle into Sidekick, or design a hybrid model that integrated with existing systems. Each direction carried implications for technical debt, operational ownership, and long-term platform strategy.

Faster transaction selection & reason capture

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.

On the Case basic info, user would need to categorize the request (type D or U) and enter information. To address speed and reduce call handling time, we:

• Embedded transaction search directly into the intake flow
• Enabled multi-select with real-time pinned summary
• Required dispute type selection

We introduced a reason-driven conditional form model:

• Fields dynamically adapt based on dispute reason
• Only relevant inputs are shown
• Mandatory fields are validated before submission

Instead of relying on documentation or memory, business rules are embedded into the system.

We designed a structured review screen summarizing:

• Selected transactions
• Dispute reasons
• Supporting details
• Total disputed amount
• Shipping address

This acts as a final quality checkpoint during the call.

Instead of requiring agents to manually record the address:

• We surfaced the existing address module within the dispute flow
• Agents can review or update directly inside Sidekick

By doing that, we can remove redundant documentation steps and minimized transcription errors.

Design is not just about crafting interfaces, it begins with deep curiosity about how users actually work. Understanding the full workflow, from the first trigger to the final resolution, changes how problems are framed and solved. To me, being directly involved in requirement clarification and live agent conversations was a rare and fortunate experience. Compared to the common UX setup in many outsourcing environments in Vietnam at the time, where designers often received already-filtered requirements from Business Analysts, this exposure allowed me to see the problem in its raw, uncompressed form.

I also learned that solving a large problem does not mean building everything. It means identifying what truly needs to be built. Effective design balances user pain points with technical architecture, team capacity, and implementation effort. The goal is not completeness, but clarity, impact, and feasibility.