A
Work / AI Dispute Intake deep dive
100% ▾
SECTIONS
00 · Cover
01 · The Problem
02 · Why Not Automate
03 · The Model & Its Boundary
04 · Confidence, Done Right
04.5 · Try it yourself
05 · The Trust Boundary
06 · Audit Log as Intelligence
07 · Metrics This Enables
08 · The Trust Loop & Learnings
PROJECT
AI-Assisted Dispute Intake
clientFiserv
roleUX Designer
domainCard disputes
focusAI & trust
relatedDWS
THE PRINCIPLE
AI classifies. Humans confirm. Every decision is auditable.
RELATED CASE STUDY
Disputes Workspace →
the workspace this lived inside
◇ 00 · Cover
CASE STUDY · FISERV AI & HUMAN ACCOUNTABILITY
Related case study: Disputes Workspace

AI-Assisted Dispute Intake

I redesigned a regulated workflow so AI could accelerate intake without weakening human accountability.

AI-Assisted Dispute Intake was an LLM-supported flow inside Fiserv's Disputes Workspace. The model pre-filled dispute attributes, each field carried a plain confidence cue, and the agent accepted or corrected the result. The audit log recorded both sides of the decision: what the AI suggested and what the human chose. That made the flow defensible under FCBA and Reg E, and gave the team a way to see where the model was trusted, corrected, or overconfident.

AI classifies
Pre-fills the dispute attributes per case
Humans confirm
Accept or correct every field
Always auditable
Every decision recorded and traceable
PLAIN LANGUAGE "Charged twice for one ride." AI SUGGESTS Duplicate charge HIGH HUMAN DECIDES Accept · Correct · Override the agent owns it AUDIT LOG every override feeds the next improvement
the whole idea in one line: plain language in, an AI suggestion with a confidence cue, a human decision, an audit record, and a loop back to a better model
◇ 01 · The Problem

Intake was manual, error-prone, and impossible to trace

Every dispute starts with intake. An agent listens to a cardholder, decides what kind of dispute it is, and types in the details by hand. They do this while the customer waits on the line, against FCBA and Reg E clocks, holding 30 to 50 open cases at once. It is the highest-pressure, lowest-margin moment in the whole lifecycle, and it sets everything downstream.

A wrong turn here does not fail loudly. A misclassified dispute clears intake, sits in the wrong queue, and resurfaces weeks later as a missed regulatory deadline. By then the bank eats the loss, the cardholder is still out their money, and a reviewer is reconstructing what happened from notes that never quite agreed.

THE REAL DEBT

This was not a speed problem dressed up as a compliance problem. It was the reverse. The decisions made at intake were invisible: who decided what, on what basis, and where the judgment came from. In a regulated workflow, a decision you cannot reconstruct is a liability, no matter how fast you reached it.

DEBT 01

Manual classification

Agents read the dispute and chose a type from memory, under time pressure, with no second pair of eyes.

DEBT 02

Errors surface late

A small mistake at intake compounds quietly downstream, where it is expensive to find and slow to correct.

DEBT 03

No trace of the decision

When a reviewer asked why a case was handled a certain way, the answer lived in someone's head, not in the system.

◇ 02 · Why Not Just Automate

A fast answer with no visible reason is an answer no one uses

The obvious move was to automate intake outright. Let the model read the dispute, classify it, fill the fields, and move on. We rejected that, and the reason is the whole point of this case study.

That is the trap in a lot of agentic UX: the system can act, but the person cannot tell whether it should have. Speed helps only if the user can inspect the reasoning, correct the output, and explain the final decision later.

Picture the trust-breaking moment. The model returns a classification in under a second. It is probably right. But the agent has no way to see what it read, why it landed there, or how sure it is. So the agent does the only safe thing under a regulatory clock: they ignore it and start over by hand. A suggestion you cannot inspect is a suggestion you cannot defend, and in this domain that means it gets thrown away.

⚡ THE TENSION

Automate the decision and agents stop trusting the system. Hold every case for full manual review and the speed gain disappears. Push the model harder and you take accountability away from the person the regulator holds responsible.

✅ THE BET

Design for calibrated trust. Trust the AI when it is right, review when it is uncertain, override when it is wrong, and make the boundary between AI and human explicit at every step. The human in the loop is not a concession. It is the design.

Pure automation optimizes for the wrong thing. In regulated work, the goal is not to remove the human. It is to make the human faster and more sure, with a record of why.

the design bet that shaped everything after it
◇ 03 · The Model & Its Boundary

What the AI does, and the line it never crosses

The model reads the dispute in plain language and pre-fills the attributes of the case: the amount, the date, the merchant, the dispute type, and the rest. Each populated field carries its own confidence. From there the agent takes over. The closed loop below is the spine of the whole system, and the order matters.

DEVICE A · THE CLOSED LOOP
1 AI AI suggests a value The model pre-fills each field from the dispute description. 2 AI Agent sees confidence Each field shows High, Medium, or Low, with a next step. 3 HUMAN Accept or correct The agent decides per field. Overrides are documented. 4 AUDIT Audit log captures it Suggestion, confidence, action, final value, and reason: logged. 5 PRODUCT Patterns get analyzed The team reads the log for weak fields and confidence bands. 6 IMPROVE Prompts & UX improve Extraction rules and the UI get tuned. The product earns trust. loops back
WHERE AI ACTS

Reading, extracting, classifying, and showing how confident it is. Steps 1 and 2. The model proposes. It never disposes.

WHERE THE HUMAN ACTS

Deciding. Step 3 is the boundary. Every field is the agent's call, and the audit log records that it was theirs.

◇ 04 · Confidence, Done Right

A number tells you nothing. A label tells you what to do.

The first version showed raw percentages. "85% confident." It read precise, and it failed in practice. A probability gives an agent no instruction. Worse, a high-looking number invited automation bias: people accepted "85%" without checking, even when the underlying field was wrong.

I replaced the number with a plain confidence headline, and paired each level with a next step. The reader engages the reasoning before they ever reach a score. The raw value is still available for anyone who wants it, but it is de-emphasized on purpose.

DEVICE B · HEADLINE FIRST, EVIDENCE NEXT, RAW SCORE LAST
HIGH
Review and accept
EVIDENCE
Amount and date matched the cardholder's own words exactly.
raw · 0.91
MEDIUM
Verify before continuing
EVIDENCE
Merchant name is close but not an exact match to a known biller.
raw · 0.64
LOW
Manual review recommended
EVIDENCE
The description supports more than one dispute type.
raw · 0.38
The progression is deliberate: the headline says what to do, the evidence says why, and the raw score sits last, for the rare reader who wants it. Action over precision.
RECREATED SCREEN
illustrative rebuild

The intake screen: every AI field wears its confidence

The agent describes the dispute in plain language. The model pre-fills the attributes, and each one carries its own confidence chip, so the agent knows at a glance which values to accept and which to check. Nothing is committed until the agent decides.

Cases / New dispute / Intake
AI-assisted
CARDHOLDER'S DESCRIPTION
"I was charged $47.50 twice for the same Uber ride on March 3rd. I only took one trip."
AI PRE-FILLED 6 FIELDS accept all · review each
Dispute type
Duplicate charge
HIGH Accept
Disputed amount
$47.50
HIGH Accept
Transaction date
Mar 3, 2026
HIGH Accept
Merchant
Uber Technologies
MEDIUM Verify
WHY MEDIUM
The descriptor reads "UBER *TRIP HELP.UBER.CO", which maps to Uber but is not an exact biller match. Confirm the merchant before the duplicate-charge rule applies. raw · 0.64
Sub-reason code
10.4 vs 12.6.1 (ambiguous)
LOW Override
3 high · 1 medium · 1 low · agent reviews each
Edit details Confirm intake
recreated intake screen: per-field High / Medium / Low chips, one field expanded to show the evidence behind its level, and a confirm step the agent owns
▸ 04.5 · Try it yourself
▶ INTERACTIVE · DRIVE IT YOURSELF

Try the AI intake yourself

This is the same screen a Fiserv agent saw, rebuilt in the DWS design system. The AI has already read the cardholder's complaint and pre-filled five fields, each tagged with how sure it is. Press start and do the agent's job yourself. Nothing is submitted for you.

For the next minute, you're the bank agent.

A guided 90-second walkthrough of the AI intake: accept what the AI nailed, verify what it is unsure of, and catch the one thing it got wrong. Every decision you make writes itself into a live audit log.

AI classifies pre-fills the fields
You confirm every single field
All auditable watch the log fill up
⤢ Open this page on a laptop to drive it
D
Disputes Workspace
PORTFOLIO DEMO
AR
A. Rivera
Dispute Agent · you
WORKSPACE
Cases
Work Queues
Reports
Admin
YOUR QUEUE
34 open cases
3 near Reg E deadline
Cases / New dispute / Intake
✦ AI-assisted
⏱ REG E · 9 DAYS LEFT
case draft · DIS-8842-013
✦ GUIDE · STEP {{ guideStep }} OF 6
{{ guideTitle }}
{{ guideBody }}
WHY I DESIGNED IT THIS WAY  {{ guideNote }}
CARDHOLDER'S DESCRIPTION · RECEIVED VIA CALL CENTER
“I was charged $47.50 twice for the same Uber ride on March 3rd. I only took one trip.”
The AI read these words and pre-filled the 5 fields below. Each one is rated by how sure the AI is. The rating tells you what to do next.
HIGH the AI is sure → review & accept
MEDIUM a maybe → check the evidence first
LOW a guess → a person decides
✦ AI pre-filled 5 fields
{{ decidedCount }} of 5 decided by you
Tempting, right? That one-click urge is called automation bias, so the design only lets “Accept all” touch the green fields. The amber and red ones still need your eyes.
DISPUTE TYPE
Duplicate charge
HIGH
Matches the cardholder's own words: “charged twice”. → Review and accept.
Accepted ✓
DISPUTED AMOUNT
$47.50
HIGH
The exact amount stated on the call. → Review and accept.
Accepted ✓
TRANSACTION DATE
Mar 3, 2026
HIGH
Stated directly: “on March 3rd”. → Review and accept.
Accepted ✓
MERCHANT
Uber Technologies
MEDIUM
The AI is only partly sure. → Verify before continuing.
Verified ✓
✦ THE AI'S EVIDENCE. READ THIS BEFORE THE SCORE
The card statement reads UBER *TRIP HELP.UBER.CO, a messy “descriptor”, not a clean name. It maps to Uber, but it is not an exact match to a known biller. If you agree it's Uber, verify it. raw score · 0.64 (kept last, on purpose)
SUB-REASON CODE
{{ subValue }}
LOW
This code decides which card-network rules the case follows. The AI is guessing between two. → Manual review.
Overridden ✓
YOUR CALL. WHICH CODE FITS “CHARGED TWICE FOR ONE RIDE”?
10.4
Fraud, card-absent environment · the AI's guess (raw 0.38)
12.6.1
Duplicate processing, same charge billed twice
13.1
Merchandise / services not received
Re-read the cardholder: “charged twice for one ride.” One real charge, billed twice. That is duplicate processing.
your correction is logged with a reason. It becomes training signal
Intake confirmed. Case DIS-8842-013 created
Routed to the duplicate-processing queue with the correct code. The Reg E clock starts with clean data.
YOUR SESSION, READ BACK
3 HIGH accepted as-is. The AI earned trust on the easy calls.
1 MEDIUM verified, but only after you opened the evidence and agreed.
1 LOW overridden, 10.4 → 12.6.1. The strongest signal of all.
★ WHY THIS IS THE HERO IDEA
The log you just wrote satisfies a compliance reviewer (who decided what, when, on what basis) and it teaches the product team. A thousand agents making your same 10.4 → 12.6.1 correction is not a thousand errors. It is a precise instruction for what to fix next. The record built for the regulator is the same record that makes the AI better.
See the real audit log ↓
{{ footerHint }}
▶ DRIVE IT YOURSELF · ~90 SECONDS
For the next minute, you're the bank agent.
New to disputes? When you spot a charge on your card that's wrong (billed twice, never received, fraud) you call your bank. That call is a dispute. The person answering has a customer on the line, 30 to 50 other open cases, and federal deadlines ticking.
A cardholder just said: “charged twice for one Uber ride.” The AI already read their words and filled the form, but it decides nothing. Your job: accept what it nailed, verify what it's unsure of, and catch the one thing it got wrong.
AI classifies
pre-fills the fields
You confirm
every single field
All auditable
watch the log fill up
AUDIT LOG · LIVE
{{ logCount }} / 5
every decision is recorded the moment you make it. This is what makes the AI defensible
your decisions appear here
one row per field
{{ row.field }}
{{ row.time }}
AI: {{ row.ai }}
{{ row.conf }}
{{ row.action }}
→ {{ row.final }}
reason: {{ row.reason }}
✦ SIGNAL DETECTED
Your override is exactly what the team learns from. One agent correcting 10.4 → 12.6.1 is a data point. A thousand doing it is proof the extraction rule is wrong, and a to-do list for the next model.
FCBA · REG E COMPLIANT TRAIL
suggestion → confidence → human action → final value → time
↑ recreated in the DWS design system: semantic color, per-field confidence, explicit human boundary
AI suggests · human decides · audit log remembers
◇ 05 · The Trust Boundary

Three actors, one clear line of accountability

"Human in the loop" is easy to say and easy to fudge. To hold up under a regulatory review, the boundary has to be explicit: who assists, who automates the already-approved, and who actually decides. Here is the split.

ASSISTS
The AI

Reads the dispute, extracts the attributes, classifies, and shows its confidence. It assists the judgment calls. It never closes one.

AUTOMATES
The rules

Rule-bound automation handles the approved, repetitive actions a human already signed off on. Deterministic, bounded, and never a judgment call in disguise.

DECIDES
The human

Owns every judgment. The agent accepts or corrects the AI output, and that decision is theirs on the record. The regulator holds a person accountable, so a person decides.

THE BOUNDARY, IN ONE SENTENCE

AI assists the judgment calls, rule-bound automation handles the approved repetitive actions, the human owns every judgment, and the audit log records who decided what. The boundary between the three is always explicit, never blurred to make a demo look smarter.

◇ 06 · The Audit Log as Product Intelligence
★ THE HERO IDEA

The audit log became the product's memory

Compliance needed a record: who decided what, on what basis, when. That much was a requirement. But because the AI intake was a brand-new feature, there was no historical baseline to measure it against. There were no past accuracy numbers, no prior override rates, nothing to compare to.

So I designed the audit log as the place where the product could learn. The record still satisfied the regulator, but it also showed the team where the AI was trusted, corrected, or overconfident. An override was no longer only a correction. It was a signal about what to fix next.

BEFORE · LEGACY NOTES
// free-text note
"classified as dup, looked right"
// free-text note
"changed type, see email"
// no note
No way to reconstruct who decided what, or why. Not traceable. Not measurable.
AFTER · STRUCTURED LOG
AI SUGGESTION
Duplicate charge
CONFIDENCE
HIGH
HUMAN ACTION
Accepted
FINAL VALUE
Duplicate charge
TIMESTAMP
14:02:11 UTC
REASON
matched on accept
Every decision reconstructable. Traceable for compliance, and countable for the product team.
RECREATED SCREEN
illustrative rebuild

The audit-log table: one row per decision

Each row captures the full interaction: what the AI suggested, how confident it was, what the human did, the value that was committed, and when. A compliance reviewer reads it top to bottom. A product analyst reads it down the columns.

Reports / Audit log / Case 8842-013 6 fields · 1 override
FIELD AI SUGGESTED CONF. HUMAN ACTION FINAL VALUE TIME
Dispute type Duplicate charge HIGH Accepted Duplicate charge 14:02:11
Amount $47.50 HIGH Accepted $47.50 14:02:14
Merchant Uber Technologies MEDIUM Corrected Uber Trip 14:02:31
Sub-reason code 10.4 LOW Overridden 12.6.1 (reason logged) 14:03:02
every row is reconstructable end to end · the override on row 4 carries a logged reason
recreated audit-log table: AI suggestion, confidence, human action, final value, and timestamp, one row per field decision
A SECOND LAYER OF VALUE

The log made every AI suggestion traceable, and it gave the team a practical way to learn from real decisions.

Read down the override column and the model tells on itself. If high-confidence fields are often overridden, the calibration is wrong. If low-confidence fields are often accepted, the model is under-confident. If one field is corrected again and again, its extraction rule or prompt needs work. If one dispute type drives most of the overrides, it needs more domain support. The audit log turns each correction into a piece of evidence about what to fix next.

◇ 07 · Metrics This Design Enables

What the log makes measurable

Because every decision is structured, a whole class of measurements becomes possible. These are the questions the design lets the team ask once enough cases flow through. They are framed as what the instrument can read, not as numbers I am claiming.

These are metrics this design enables, not measured results.
AI acceptance rate
How often agents accept a suggestion as-is.
Override rate
How often agents reject the AI value and supply their own.
Acceptance & override by confidence
Whether High, Medium, and Low actually predict behavior.
Most-corrected fields
Which attributes get corrected most, pointing at weak extraction.
Confidence calibration accuracy
Whether a High really is more reliable than a Low.
Override patterns by dispute type
Which dispute categories drive the most corrections.
DEVICE D · OVERRIDE HOTSPOTS
ILLUSTRATIVE · sample shape, not real data

Where the AI gets corrected most

Darker cells mean agents corrected the AI more often. A dark cell under High confidence means the model may be too sure. A dark cell under Low confidence means the field may need better extraction support.

Read: High-confidence corrections point to calibration risk. Low-confidence corrections point to extraction gaps. The action changes based on where the dark cell lands.
◇ 08 · The Trust Loop & Learnings

The Trust Loop: auditability as a learning system

Put the pieces together and a cycle appears. The AI suggests, the agent decides, the log records, the team learns, and the next suggestion can be tuned with real behavior behind it. The record that keeps the work compliant also shows where the AI needs to get better. That is the idea I most want this case study to carry.

THE AI TRUST LOOP
The cycle runs continuously: a pulse travels the loop and lights each stage in turn. Hover or tap a node to read what gets recorded.
SUGGEST AI suggests a value
The model reads the agent’s plain-language description of the dispute and pre-fills each field with its best guess. Nothing is committed yet. It’s a starting point, not a decision.

What the loop tells the team to fix

High-confidence fields overridden a lot? The calibration is probably wrong. The model is too sure.

Low-confidence fields accepted a lot? The model is under-confident, hiding good answers behind a cautious label.

One field corrected again and again? Its extraction rule or prompt needs work.

One dispute type driving most overrides? That category needs more domain support.

What this taught me about designing AI

01

In regulated AI, auditability is not overhead. It is how the product learns. The record you build for review is also the record that shows where the model needs work. Design those needs together.

02

Confidence has to tell you what to do. A probability is not guidance. Pairing a plain label with a next step beat a precise number, because it changed behavior instead of just reporting it.

03

The boundary is the product. The problem with agentic UX is not autonomy by itself. It is unclear accountability. In high-stakes work, people need to know what the AI did, what they decided, and what gets recorded.

THE THROUGHLINE

I redesigned a regulated workflow so AI could accelerate intake without weakening human accountability. The AI classifies, the human confirms, and every decision stays auditable. That record is what let the team learn from real corrections instead of guessing where the model needed work.

SEE THE FULL PRODUCT
Disputes Workspace: the redesign this AI lives inside