Payments · Remediation · Shipped to GA
Rescuing returned checks
Turning a silent, support-dependent failure into a guided fix.
- Summary:
- When a paper check comes back undelivered, almost always because of a wrong vendor address, AP customers were left with a failed payment, an unpaid vendor and no way to fix it in the product. I designed an opinionated, end-to-end workflow that walks them through the fix in the order experts use: correct the address, then reissue.
- Design process:
- Audit of the legacy experience → customer call, journey-map research → every address-validation outcome mapped to a user story with engineering → concept flows → a full-day walkthrough with PM and engineering → shipped in two phases.
- Team:
- 1 product manager, 1 product designer, 1 front-end engineer, 1 back-end engineer.
- AI Concept:
- View prototype
01Where it got hard
"I just wanted to make sure that a check wasn’t sent out.”
Our AP customers move a huge volume of payments, and success was never the number of payments sent, it was whether they arrived. A returned check is a remediable payment: it failed in flight, but it can still be completed once the problem is fixed. In practice, it usually wasn’t.
Here is the legacy experience, which failed customers in three connected ways:
- It was passive. Customers heard about a returned check by email, then had to chase a fix through support. Nothing in the product let them resolve it.
- It had no opinion. “Void and credit” (give up) and “void and reissue” (fix it) had the same weight, so customers had to work out the right move at the worst possible moment. Journey-map research found people felt “reactive rather than empowered” around voids and returned payments.
- It left them unsure afterwards. With no clear, lasting status, customers couldn’t tell whether their fix had worked, as the quote above shows.
02Understanding the problem space
Listening to a customer call, then comparing it with the journey map, support patterns and escalations, gave one root cause: a returned check is almost always an address problem, and it can’t be reissued successfully until the address is fixed. A support specialist put the expert sequence plainly: “you want to make sure that your team is updating the vendor’s address first.”
Check remediation couldn’t be a single “reissue” button.
It had to follow the order experts used: fix the address, then reissue.
03The decision I made, and why
- Be opinionated about fixing, not voiding. For the first time, the product took a point of view: guide customers to fix the address and complete the payment.
- Put the address fix inside one remediation drawer. A single action now orchestrates several operations behind the scenes.
- Validate automatically, and suggest strongly rather than block. The drawer runs address validation and, when something is off, makes an explicit recommendation and asks the customer to confirm.
- Make the outcome explicit and persistent. A “Fixed on [date]” marker and a “Reissue pending” status.
Awareness and action moved into one place: inline error icons, a single “Fix now” entry point for each returned check, and a persistent inline status that gets updated in real time.
04What I tried and dropped
- Two equal void options. Presenting “void and credit” and “void and reissue” side by side was neutral, and left customers to decide alone. The fix became the default; giving up became a clearly labeled exit.
- A bare “Void” button. Not giving users a way to fix the address goes against their best practice.
- Designing only the happy path. I walked every address-validation result with engineering (valid, corrected, missing, unconfirmed, warning and exception) and gave each one a defined behaviour. That is what made a strong suggestion safe to ship instead of a hard block.
PM, design and engineering then spent a full day walking the flows end to end, to catch logic gaps before they became expensive in code. We shipped in two phases: an awareness layer first, then the end-to-end workflow at general availability three months later.
05What changed
The awareness phase alone, which surfaced returned checks and created urgency, moved the check remediation rate up 20%, from 18.3% to 22%, against the prior half. Once the guided workflow was live, checks fixed in the flow were remediated at roughly twice the portfolio average.
| Measure | Before | After |
|---|---|---|
| Check remediation rate | 18.3% | 22% (awareness phase) |
| Guided check workflow vs. portfolio | ~21% portfolio | ~52% in the workflow |
We accepted one risk openly: making fixable checks visible could raise support contacts in the short term, because customers would finally notice checks they used to miss. Next steps were already scoped: guide only users with permission to void, and record exactly why a reissue fails, including the remaining address exceptions.
06AI concept: a payment assistant that does the legwork
The guided workflow still asks the customer to know the right address. Often they don’t, and finding it means digging through invoices, W-9s and email. In this concept an assistant does that legwork. Here are the 4 main steps:
- Triage. It lists every returned check with how many days are left before it voids, so the most urgent comes first.
- Gather evidence, then recommend. For each check it compares the address that was mailed with recent invoices, the W-9 and the inbox, and recommends a validated address.
- Ask the vendor. A reissue needs the vendor’s confirmation. The vendor can approve, correct the address, or switch to electronic payment.
- Screen the reply and follow up.
Guardrails: It never reissues on its own recommendation, contacts vendors only through details already on file, never takes bank details by chat or email, and holds the payment at the first sign of fraud.
