R Recoup

Product design case study — chargeback representment for payment operations

Winnable disputes are lost to the clock, not the merits.

Recoup is a response desk for payment-operations analysts. It triages incoming chargebacks by what is actually at risk, assembles the evidence a card network will accept, and gets the packet out before the representment window closes.

Representment window for a single Visa dispute
Dispute opened — day 0 Deadline — day 30

Analysts get weeks. They use the last few days. The orange sliver is when the work actually happens — after the case surfaces in a spreadsheet, after evidence is chased across four systems, and often after the window has already closed.

My role
End-to-end product design
Scope
Triage → evidence → submit
Duration
6 weeks, concept
Surface
Desktop web app
Deliverables
Research, IA, flows, UI kit, prototype
Read this first

Recoup is a self-directed concept project, not shipped client work. The interviews, personas and measurements below are synthesized composites built to make the design reasoning legible — treat every figure as illustrative rather than as reported data. Card-network rules referenced in the UI (deadlines, reason codes, decision windows) vary by network, region and merchant agreement, and would need verification against current scheme documentation before any real build.

01

The problem

When a cardholder disputes a charge, the money is pulled out of the merchant's account first and argued about second.

To get it back, a payment-operations analyst has to file a representment: a written argument plus documentary evidence, sent to the issuing bank through the card network, before a fixed deadline. Miss the deadline by an hour and the case is closed on the merits of nothing at all. The chargeback stands, the debit is final, and the merchant also eats the network fee.

So the job looks like adjudication but behaves like logistics. Analysts I spoke to were rarely unsure what the winning argument was. They were unsure whether they could physically assemble it in time — and which of the forty cases sitting in front of them was the one about to expire.

The tooling made that worse. Cases arrived as a CSV export or a portal list ordered by date received. Deadlines lived in a side spreadsheet. Evidence lived in the order system, the shipping carrier's site, the 3-D Secure logs and a shared drive. The submission portal itself gave no signal about whether a packet was strong enough to bother sending.

Anatomy of one response

Finding the case8%
Reading the reason code5%
Hunting evidence46%
Writing the argument12%
Formatting & attaching18%
Submitting11%
Illustrative proportions from four contextual sessions. The part of the job that requires expertise — deciding the argument — is the smallest slice. Everything around it is retrieval and clerical work.

Problem statement

A payments analyst can tell in two minutes whether a dispute is winnable. Recoup has to close the gap between knowing that and having filed it — before the window shuts.

Deliberately out of scope

  • —Chargeback prevention — fraud scoring, 3-D Secure tuning, alert networks like Ethoca or RDR. Real, valuable, and a different product.
  • —Arbitration and pre-arbitration. A tiny share of volume with a completely different rule set.
  • —Merchant-facing self-service. Recoup is an internal desk tool for trained analysts, so it can assume domain fluency and optimise for speed over hand-holding.
  • —Mobile. This work happens on two monitors. A responsive read-only view is a follow-on, not a launch requirement.
02

What the research said

Five findings, each of which survived into the interface. Anything that did not change a screen is not listed here.

MethodSampleWhat it was for
Depth interviews9 analysts, 3 ops leads, 5 merchantsHow the work is actually sequenced
Contextual observation4 sessions, full case start to submitWhere the time physically goes
Loss teardowns12 rejected packetsWhy filed cases still fail
Competitive teardown5 dispute tools, 2 network portalsConventions worth keeping and breaking
Rule-set reviewVisa, Mastercard, Amex representment docsConstraints the design cannot negotiate with
F1

The judgement is fast. The assembly is slow.

Every analyst observed named the likely outcome within the first two minutes of opening a case — usually straight off the reason code plus the order record. The remaining forty-plus minutes were spent retrieving artifacts from systems that do not talk to each other, then re-typing their contents into a narrative field.

Design implicationPre-assemble the packet. Show the analyst a checklist already populated with retrieved artifacts, and let them confirm rather than fetch.

F2

The queue is ordered by arrival, not by risk.

Default sort in every tool reviewed was date received. Analysts worked top-down. That means a $90 case with 42 hours left is handled before a $2,140 case that expires in three hours, purely because it arrived first. Two of the twelve loss teardowns were expiries caused by exactly this.

Design implicationMake deadline and amount first-class columns, colour the last hours, and default the queue to Needs response rather than All.

F3

Evidence sufficiency is tacit knowledge.

Veterans knew that a Visa 10.4 fraud case is usually carried by the 3-D Secure result and prior undisputed history, while a 13.1 not-received case lives or dies on signed delivery proof. Analysts under a year in the role attached everything they could find, which slowed them down without improving outcomes. None of this was written anywhere.

Design implicationBind the evidence checklist to the reason code, mark items required or optional, and score the packet against the reason code's own threshold.

F4

The deadline lives outside the tool.

Deadlines were tracked in a shared spreadsheet, a calendar reminder, or an analyst's memory. The portal where the work happened showed a received date and nothing else. One lead described her Monday as "opening the sheet to find out what we already lost over the weekend."

Design implicationPut time remaining in the queue row, in the case header, and in a persistent panel beside the submit action. Count down, never count up.

F5

A loss teaches nobody anything.

Outcomes came back weeks later as a line in a settlement report. Analysts could rarely connect a specific rejection to the specific packet they had sent, so the same mistakes repeated. Nine of twelve teardowns had a rejection code the analyst had never seen surfaced.

Design implicationGive every case a permanent result screen with the issuer's stated reason, a timestamped activity trail, and one recovery action.

03

In their words

Composite quotes, assembled from the interview set.

I know within thirty seconds whether we win this. Then I spend the rest of my morning proving it to a system that already has all the evidence somewhere.

Analyst, 4 years — subscription commerce

The spreadsheet is the real product. The portal is just where I paste things at the end.

Analyst, 2 years — marketplace

New joiners attach nine documents because they are scared. It doesn't help. For a 10.4 you need the 3-D Secure result and the history. That's it.

Payment operations lead, 8 years

We lost a twenty-one hundred dollar case because it sat behind four small ones. Nobody made a bad call. The list was just in the wrong order.

Payment operations lead, 5 years

When a packet gets rejected you get a code. Nobody explains the code. You just feel slightly worse and move on.

Analyst, 1 year — travel

I'd trade every dashboard in this tool for a number that tells me this packet is good enough to send.

04

Who this is for

One person does the work under time pressure. One person owns the recovery number. Recoup has to serve both without becoming two products.

DF

Dayo Fashakin

Chargeback analyst · North America desk
31 · 4 years in payments ops

“Give me the case that's bleeding and the four files that win it. I'll do the rest.”

Daily volume
18–25 cases
Peak
Monday, post-weekend
Tools open
6 tabs, 1 spreadsheet
Measured on
Win rate & expiries

Goals

  • Clear the response queue before anything expires
  • Send packets strong enough to actually win, not just filed
  • Stop re-explaining the same evidence in a free-text box

Frustrations

  • Deadlines are in a spreadsheet, cases are in a portal
  • Chasing delivery confirmations across carrier sites
  • Finding out weeks later that a packet was rejected on a technicality

Behaviour

  • Works top-down through whatever list is on screen
  • Keeps a personal doc of winning phrasings per reason code
  • Batches submissions at end of day — the riskiest habit in the role

What Recoup owes DayoThe next right case, its evidence already gathered, and an honest read on whether the packet is worth sending.

PR

Priya Raman

Payment operations lead · 11-person desk
38 · owns the recovery target

“I don't need a prettier dashboard. I need to know what we're about to lose by Friday.”

Team
11 analysts, 3 regions
Reviews
Weekly win rate
Reports to
VP Finance Ops
Worst metric
Expired, unfiled

Goals

  • Zero cases lost to expiry — a loss on merit is defensible, an expiry is not
  • Bring new analysts to competence without shadowing for a month
  • Defend the desk's value at renewal with a credible recovery figure

Frustrations

  • No forward view of value at risk, only backward-looking reports
  • Quality varies wildly by analyst tenure
  • Audit asks for evidence of what was sent and when; reconstructing it takes days

Behaviour

  • Starts the week by scanning for anything near deadline
  • Spot-checks packets from junior analysts before submission
  • Trusts numbers she can trace back to a case ID

What Recoup owes PriyaA desk-level read on exposure and deadline risk, plus a permanent, timestamped record of every submission.

05

The journey we inherited

Dayo, one $428.90 dispute, before Recoup. Mapped from the observation sessions.

NoticeMon 09:10
TriageMon 09:25
GatherMon 09:40
ComposeMon 10:20
SubmitMon 10:35
Wait+30–45 days
Doing
Opens the overnight CSV from the processor and pastes new rows into the tracking sheet.
Eyeballs the list top-down. Picks the oldest case, not the one closest to expiry.
Order record, carrier tracking page, 3-D Secure log, shared drive for the invoice.
Types a narrative into a plain text box, re-stating facts already in the attachments.
Uploads five PDFs to the network portal, clicks submit, hopes the size limit holds.
Nothing. The case leaves her screen and her control.
Tools
Processor export · Sheets
Sheets · portal list
OMS · carrier site · auth logs · Drive
Portal text field · personal phrasing doc
Network portal
Settlement report, weeks later
Thinking
“How bad is the weekend backlog?”
“This one's old, start here.”
“The delivery proof has to be somewhere.”
“Have I said enough? Is this the phrasing that works?”
“Did that actually go through?”
“I'll find out eventually.”
Pain
No single source of truth; deadlines calculated by hand.
Ordering by age quietly buries the expensive, expiring cases.
Four systems, four logins. This is where the time goes.
No guidance on what a strong packet looks like for this reason code.
No confirmation, no packet summary, no idea if it is complete.
Outcome arrives detached from the packet that caused it.
Feeling
in control exposed
Opportunity
Ingest cases and compute the deadline automatically.
Rank by time left and value at risk, not arrival.
Pre-fetch evidence and attach it to a reason-code checklist.
Score the packet against what wins this reason code.
Summarise, gate on a confirmation, then receipt it.
Return the issuer's reason to the case, permanently.
The two deepest troughs — gathering evidence and receiving an unexplained outcome — became the two screens I spent the most time on: Build and Result.
06

What to build

Every feature below traces to a finding. Where it didn't, it went to the backlog — the fastest way to blow a deadline-driven tool is to fill it with things that are merely nice.

FeatureFromWhat it does for the analystRelease
Deadline-ranked queueF2Time left and amount are columns, not metadata. The last hours turn red, overdue turns emphatic, and the desk opens on Needs response.v1
Desk snapshotF2 · F4Open disputes, value at risk, due within 24 hours, past deadline. Four numbers a lead can act on before her coffee.v1
Reason-code evidence checklistF3The document list changes with the reason code. Required items are marked required; optional ones are offered, not demanded.v1
Pre-fetched artifactsF1Each checklist row arrives with the retrieved fact attached — tracking number, 3-D Secure result, invoice line count — so confirming replaces fetching.v1
Packet strengthF3A score out of 100 read against the threshold for this reason code, with a sentence explaining the verdict. Ends the guessing about “is this enough”.v1
Persistent deadline panelF4Sits beside the submit button through the whole build. States the network rule and what happens after the cut-off.v1
Pre-submission checksF3 · F5Four machine-verifiable checks — code matches evidence type, required docs present, inside deadline, amount matches — run before the packet can go.v1
Confirmation gateF5Submission is irreversible, so the button stays inert until the analyst affirms accuracy. The gate is a checkbox, not a modal.v1
Result & activity trailF5Confirmation number, document count, and a timestamped history. On rejection, the issuer's own reason code in plain language plus one recovery action.v1
Bulk importF4Ingest the processor's export so deadlines are computed on arrival instead of transcribed by hand.v1.1
Narrative starters by reason codeF1 · F3A drafted argument from the retrieved facts, which the analyst edits. Kept out of v1 because a wrong draft is worse than a blank field.v1.1
Win-rate trendF5Recovery rate over 90 days, so the desk can argue its own value. Read-only in v1, sliceable by reason code later.v1.1
Deadline exception workflowF5Structured request when a packet is rejected for lateness. Rarely granted, but it's the only move left and analysts currently make it over email.Later
Desk-level SLA alertsF2 · F4Notify a lead when a case crosses six hours unassigned. Deferred until the queue ordering proves itself — alerts on a bad sort just add noise.Later

How the cut was made

Do first Plan properly Fill gaps Resist Persistent deadline panel Deadline-ranked queue Pre-submission checks Confirmation gate Desk snapshot Reason-code checklist Pre-fetched artifacts Packet strength Win-rate trend Bulk import Narrative starters Deadline exceptions Low effort High effort Low impact High impact
The three amber items were expensive but non-negotiable: they are the features that attack F1 and F3, which is where the time and the losses live. Everything in the lower half waited.
07

Information architecture

Four destinations, one of which is a queue and three of which are stages of the same case. The top navigation doubles as a progress indicator, so an analyst always knows how far into a response they are.

  • Recoup — North America desk
    • Overviewthe queue; the only page not tied to a single case
      • Desk snapshotopen disputes · value at risk · due within 24h · past deadline
      • Win rate90-day recovery rate and trend
      • Case queue
        • Needs responsedefault tab
        • Submitted
        • Resolved
        • All
      • Search & filterscase, merchant, cardholder
      • Bulk import · New response
    • Buildstep 1 of the case workspace
      • Case context stripcase ID · status · cardholder · reason · network · step
      • Representment narrative1000-character argument to the issuer
      • Evidence documentschecklist bound to the reason code
      • Packet strengthscore, threshold, explanation
      • Deadlinetime left and the network's rule
    • Reviewstep 2 — read-only summary before an irreversible act
      • Evidence packetmerchant · cardholder · amount · reason code · documents
      • Pre-submission checksfour automated verifications
      • Confirm & submitattestation gate
    • Resultstep 3 — the case's permanent record
      • Outcomesubmitted · rejected, with recovery actions
      • Case factscase · disputed amount · status
      • Activitytimestamped trail, newest first
    • Notificationsdeadline and outcome events
    • Accountdesk assignment, preferences

The nav labels are verbs-as-stages — Build, Review, Result — rather than nouns like Case detail or Submission. In testing this did more work than the “Step 2 of 3” badge: people described their place in the task using the nav word without being prompted.

08

The task flow

One case, from landing in the queue to a permanent outcome. The two loops on the right are the only places the analyst is sent backwards — and both of them are cheap.

Dispute lands in the response queue Queue ranks it by time left and value at risk Open case · Build All required evidence attached? Yes No Attach the missing document Packet strength meets the reason-code threshold? Yes No Add supporting evidence returns to Build Review & submit Analyst confirms the evidence is accurate? Yes No Submit stays inert Transmit packet to the network Received before the response deadline? Yes No Result — Submitted Confirmation number issued Result — Rejected Issuer reason shown in full Activity trail records it Request deadline exception or return to the queue
Both rejection branches end somewhere useful. The design principle: a failed submission is still an event the analyst can act on and learn from, so it gets a screen of its own rather than a toast that disappears.
09

Sketches

The first pass, made to settle three arguments: where the deadline lives, whether evidence is a list or a canvas, and how much of the queue survives into the case view.

01 — Queue: deadline column earns its own rule 02 — Build: checklist left, decision rail right 03 — Result: verdict, facts, then history time left, in red, always last column score + deadline share the right rail one verdict, one recovery action
Two things settled here and never changed. The deadline gets the second-to-last column in the queue so the eye lands on it before the status chip, and on the case screen it is pinned into the same right-hand rail as the submit button — the analyst cannot decide to send without seeing how long is left.

Discarded: the evidence canvas

The second sketch round tried a drag-and-drop board where documents were tiles to arrange. It looked better and tested worse. Analysts do not compose a packet spatially; they answer a question — is the required set complete? — and a checklist answers that in a glance, which a canvas never did.

Discarded: deadline as a countdown clock

A live ticking timer in the header read as a game show. It also created a perverse effect in testing: two participants rushed a weak packet out rather than let the number get smaller. A plain “5h left” with the network's actual rule underneath produced urgency without panic.

10

Low-fidelity wireframes

Structure locked before any styling. The test here was whether a new analyst could name the next action on every screen without a tooltip.

A — Overview, the queue B — Build, evidence and decision rail C — Review, the irreversible step D — Result, verdict and history Deadline column carries colour; nothing else in the table does. Submit sits below the score and the clock, never above them.
Greyscale on purpose. Colour was withheld until the hierarchy held up without it — which is also how the deadline column earned the right to be the one red thing in a queue of forty rows.
A

Two numbers, then the list

Exposure and win rate sit above the queue because Priya reads them and leaves. Dayo scrolls past them to the table, which starts on Needs response.

B

Left builds, right decides

Everything editable is in the left column; everything that judges the work — score, deadline, submit — is in a rail that never scrolls out of relevance.

C

Read-only on purpose

No field on this screen is editable. It exists to make the analyst look at the packet once more, and to make the submit button expensive to reach.

D

Verdict before detail

The outcome, the recovery action, then the facts, then the history. A rejection is never allowed to hide inside a timeline.

11

The interface

Five screens carry the whole product. Each one is annotated with the finding it answers — if a decision isn't traceable back to the research, it shouldn't have survived this far.

01

Overview — the desk

Exposure first, then the queue. Priya can read the top of this page and leave; Dayo can ignore it and start working the table. The default tab is Needs response, so the page opens on work rather than on history.

Recoup overview screen showing desk snapshot, win rate and a case queue table with deadline and status columns

  • Four numbers that change behaviour

    Open disputes, value at risk, due within 24 hours, past deadline. Value at risk is the one that gets a lead out of her chair; past deadline is deliberately shown rather than hidden, because a desk that can't see its own expiries can't fix them.Answers F2 · F4

  • Deadline is a column, not a tooltip

    “5h left”, “19h left”, “Overdue 3h” — the only coloured text in a forty-row table. Resolved cases show an em dash instead of a zero, because a resolved case has no deadline, not a deadline of nothing.Answers F4

  • Cardholder under merchant

    Analysts search by cardholder as often as by case ID, so the masked card and name sit in the merchant cell rather than in a column nobody would scan.Observation sessions

  • Status chips stay quiet

    Four states, four tints, no icons competing with the deadline column. Won and Lost use green and red only at chip scale, so the eye still lands on time remaining first.

  • Populated / Empty toggle

    A state switcher kept in the design file so the empty desk was specified alongside the full one. An empty queue reads “nothing needs a response” — a result, not a blank slate.

02

Build — the part that used to take an hour

The screen that carries the whole thesis. Evidence arrives pre-fetched with the retrieved fact attached, the checklist knows which reason code it is serving, and the deadline sits in the same rail as the button that ends the case.

Recoup build screen with representment narrative, an evidence document checklist, packet strength score and deadline panel

  • Evidence rows carry their proof

    Under “Signed proof of delivery” sits the actual tracking number and delivery timestamp. The analyst confirms a fact rather than going to find one — this single pattern is what collapses the 46% slice.Answers F1

  • Required is marked, optional is offered

    Two items here are tagged Required. The last two are available but not demanded, which gives the over-attaching junior analyst permission to stop.Answers F3

  • Packet strength explains itself

    “100 / 100. Strong. This packet exceeds the win-rate threshold for 10.4 fraud reason codes.” The score is worthless without the sentence; the sentence is what transfers the veteran's tacit knowledge.Answers F3

  • The deadline states the rule

    Not just “5h left” but the network's actual cut-off and the consequence: submissions after the deadline are auto-declined. Urgency with a reason attached is the only kind people act on twice.Answers F4

  • Narrative has a character budget

    214 of 1000. The counter is framed as room remaining, and the helper text says exactly where the text will appear — on the cover sheet the issuer reads.

03

Review — an expensive button, on purpose

Submission cannot be undone, so this screen is entirely read-only. Its job is friction of the useful kind: show the packet as the issuer will receive it, run the checks a machine can run, then make the analyst affirm it.

Recoup review screen with an evidence packet summary, pre-submission checks and a disabled submit button behind a confirmation checkbox

  • Four checks, stated as outcomes

    Reason code matches evidence type · required documents attached · submitted before the network deadline · amount matches the original transaction. Each is machine-verifiable, which is exactly why a human shouldn't be doing them.Answers F3 · F5

  • The button is inert until it isn't

    Submit stays visually present but disabled behind the attestation checkbox. A greyed-out button that explains its condition teaches the rule; a modal that appears afterwards just startles.

  • Expectation set before the wait

    “Issuers typically return a decision within 30–45 days.” The most common support question at every desk I spoke to, answered at the moment it occurs.Answers F5

  • Step 3 of 3, still in the header

    The case context strip — ID, status, cardholder, reason, network — persists across Build and Review, so nobody has to go back to check what they are arguing about.

04

Result — submitted

The confirmation analysts said they never got. A number they can quote, a document count they can verify, and an explicit note that the case has left their queue.

Recoup success result screen confirming the evidence packet was transmitted, with case facts and an activity timeline

  • Confirmation number, first class

    VCB-2249-8831 lives in the activity trail, not in an email nobody keeps. This is the artifact audit asks for.Answers F5

  • “Removed from your response queue”

    Stating the side effect explicitly stops the analyst going back to check. Small line, measurable reduction in backtracking during testing.

  • Back to queue is the primary action

    The successful path returns to work. Download confirmation is secondary — useful, but not what the next fifteen minutes are for.

  • Activity reads newest first

    Submitted, moved, opened. The trail is short by design; a case with forty events means something has gone wrong upstream.

05

Result — rejected

The screen I spent longest on, because it is the one the research kept pointing at. A late packet is the most common avoidable loss, and until now it arrived as a code in a settlement file weeks later.

Recoup error result screen showing the submission was rejected by Visa for arriving after the deadline, with a request deadline exception action

  • Say what happened and what it cost

    Visa declined the packet because it arrived after the deadline; the chargeback stands and the amount has been debited. No apology, no hedging — the analyst needs the fact, not a feeling.Answers F5

  • The rejection code is translated

    E-0421 appears in the activity trail with its plain-language meaning beside it. Analysts told me they had been seeing codes for years without ever being told what they meant.Answers F5

  • One recovery action, honestly framed

    Request a deadline exception. It rarely succeeds, but it is the only remaining move, and analysts were already making it over email with no record. Giving it a button also gives it an audit trail.

  • Red is reserved for this

    Vermilion is the product's working accent and appears on buttons and deadlines throughout. True red appears exactly once in the system — on a lost case — so it never gets diluted.

  • Status goes to Lost, not Failed

    The case is lost; the submission didn't fail. Naming the outcome from the desk's perspective keeps the vocabulary consistent with the queue's own Won / Lost chips.

12

The system underneath

A small palette, one typeface, and a vocabulary that stays the same from queue row to result screen.

Colour, and what each one is allowed to mean

Ink#17120E
Desk#E4EAE0
Surface#FBFAF7
Action#E4552B
Won#134A38
Lost#B0381A

Vermilion is the only colour permitted on an interactive control, which is why a deadline in vermilion reads as something you can still act on, and a lost case in deep red reads as something you can't.

Status vocabulary

Needs response Submitted Won Lost

Four states, no synonyms. A case is never pending in one place and submitted in another, and the word on the queue chip is the word on the result screen.

Type

Chargeback Response Desk
Page title · 800 · tight tracking · two lines maximum
68% · $3,949.39 · 100
Figures · tabular numerals so columns align while values change
Evidence documents
Card title · 700
FedEx tracking 7742 1180 3391 — delivered Sep 08, 2:14pm
Retrieved fact · 500 · always sits under the item it proves
CARDHOLDER · REASON · NETWORK
Context strip labels · the one place small caps are allowed, because these are field names in a record

Three rules the UI never breaks

  • 1Time remaining is visible on every screen where a case can be acted on. If you can submit it, you can see the clock.
  • 2Irreversible actions state their consequence in the sentence above the button, not in a confirmation dialog after it.
  • 3Every retrieved fact shows its source. An analyst who cannot trace a tracking number back to the carrier will go and look it up anyway.
13

Did it work

Eight moderated sessions on a clickable prototype, each participant running one full response against a live countdown. Baseline was the same task on their own tools, described aloud.

What we watchedTheir toolsPrototypeWhat actually changed
Time to submit one response~47 min~12 minAlmost all of it came out of evidence retrieval. Nobody wrote a faster narrative; they just stopped leaving the screen to find things.
Picked the highest-risk case first3 of 88 of 8With time left and amount in the table, every participant chose the overdue $2,140 case without being asked to prioritise.
Submitted missing a required document4 of 80 of 8The pre-submission checks caught what the checklist didn't. Two participants said the checks were the first thing they trusted.
Could explain a rejection unprompted1 of 87 of 8Translating the network code next to the event did the work. The eighth participant read it and disagreed with the issuer, which is arguably the right response.

These are prototype observations from a synthesized study built for this case study, not production telemetry. They describe the direction of the effect and the reason for it; they are not a claim about what the software would do at a real desk.

14

How a real desk would judge this

The prototype numbers are a hypothesis. These are the four things I would instrument on day one, and the one I would watch to make sure speed wasn't being bought with quality.

Primary

Expiry rate

Share of disputes that pass their deadline without a filed representment. This is the number the whole product exists to move, and it is the only loss type that is entirely self-inflicted. Target: below 1% of eligible cases.

Primary

Median time to submit

Case opened in Build to packet transmitted. Segmented by reason code, because a 10.4 and a 13.1 are not the same amount of work and a blended average would hide a regression in one of them.

Secondary

First-submission completeness

Share of packets that pass all four pre-submission checks on the first attempt. Rising completeness means the checklist is teaching; falling completeness means it is being clicked through.

Secondary

Win rate by reason code

Lagging by 30–45 days, so useless for weekly steering but the only real proof that stronger packets produce recovered revenue rather than just faster filings.

Guardrail

Packets submitted below their strength threshold

If Recoup makes filing fast, the obvious failure mode is analysts firing off weak packets to clear a queue. If this number climbs while time-to-submit falls, the design has optimised the wrong thing and the score needs to become a soft block rather than a label.

15

What I'd fix

  • 1Packet strength is a black box. A single number with one sentence of explanation was enough to be trusted in testing, which is exactly what worries me. It needs to show its components — which evidence contributed what — before analysts start treating it as an oracle.
  • 2I designed for one dispute at a time. Real desks batch. A multi-select in the queue that runs the same evidence pattern across twelve identical 13.1 cases would probably beat every individual-case improvement here, and I only understood that late.
  • 3The empty state is underspecified. I specified an empty desk, but not the more common state: a queue where everything left is genuinely unwinnable. That is a real editorial job the interface currently ducks.
  • 4No accessibility pass on the deadline colour. Time remaining currently relies on vermilion to signal urgency. It needs a non-colour carrier — weight, an icon, or position — before it goes anywhere near a real desk.
16

What I learned

The brief I was handed described a triage problem. It was a retrieval problem wearing a triage costume. Analysts were not bad at deciding — they were fast and unusually confident at deciding — and if I had designed better filters, sorting and prioritisation logic, I would have shaved a few minutes off the smallest part of the task and declared victory.

What changed the work was the least glamorous decision in the project: putting a tracking number underneath a checkbox. Everything else on the Build screen is arrangement. That one pattern is the product.

The other thing I would carry forward is that a deadline is not a design problem you solve with urgency. Two participants made worse decisions when the interface made them feel rushed. The version that worked stated the rule, stated the consequence, and then got out of the way — urgency that informs rather than pressures.