Emeka OkonkwoDesigning an agentic duplicate vendors workflow
Open clickable prototypeDesigning duplicate vendor review to cut hours of manual checking and let an agent do the first pass.
The Problem
Companies often hold the same supplier more than once, under slightly different names and bank details. A duplicate can mean an invoice paid twice or money sent to the wrong account, so a person must confirm each one before records merge. Research with finance teams at Currys, DS Smith and Liberty Global showed AP users losing 3–4 hours a day switching between Xelix and their ERP, with little context and only an Acknowledge action. A new ML model would surface richer evidence, which had to fit a workflow users already knew.
The Solution
I designed an AI agent-led hybrid review. The familiar AG Grid queue stays for scanning and sending groups in batches, and a comparison workspace opens when a user needs to investigate: records side by side, the evidence for the match, and what differs. In the agent-led version, the agent does the first pass and proposes answers with its reasons. A person decides, a second person approves, and nothing merges without approval.
My Approach
- 1
Researched. AP teams at Currys, DS Smith and Liberty Global.
- 2
Explored. Three directions prototyped in v0 and tested with clients.
- 3
Aligned. A design studio with Product, Engineering and AI.
- 4
Designed the split. What the agent does alone, what a person decides, who approves.
- 5
Built and tested. A prototype tested with customers, then the shipped feature.
- 6
Iterated. FullStory analytics feeding the next round.
Decisions, trade-offs and what I'd change
How much the agent does on its own. If the agent closes a case by mistake, a real duplicate can go unnoticed, but a false alarm only costs a reviewer a few seconds. So the agent only closes matches that are based on the vendor name alone, and only when a team has switched that on.
Suggested answers. Suggested answers make review quicker, but they can also make people stop looking closely. When the evidence points in different directions, I label the group “Check first” and show a count, rather than stopping the reviewer from carrying on.
Merges that can't be undone. Setting a batch up for merging can be undone with one click, so I don't ask for confirmation. The extra checks go where a merge can't be undone: a second person approves it, and the reviewer picks which details to keep before approval.
Working with AI tools. I started in v0 to explore the different directions quickly, then moved to Claude once we had decided which route to take. I also used Claude Code alongside the engineers, to check what was feasible before we committed and to build the prototype. The tools had real limits. Their summaries flattened the odd comments that mattered most, so I went back to the original research notes. They would also fix one screen and break another, so I checked every screen by hand each time.
Lessons from launch
I'd start on Claude now, as I do today, and use it as my main tool once the route is decided. After launch I watched what people actually did in FullStory. About six in ten groups got a “Why this record?” check, and nine in ten of those ended with the agent's suggestion accepted anyway. People used it to feel safe, not to investigate. The surprise came at approval. Managers had to choose a value for every field where records disagreed, and about 94% picked the main record's value within a few seconds. The step I'd added to make them stop and think had become one more click. For the next iteration I'd pre-select the main record's value, make only the risky fields (bank details, payment terms) a real choice, and track whether anyone ever changes their mind.
Inside the design
The old design
The old user journey
User interviews
Design iterations
The design studio
The drawer
Comparison workspace
The new user journey
Final solution
