Operations · Fintech · Automation
From a manual spreadsheet to an automated refund engine
Crypto refunds relied on a shared spreadsheet, manual decisions and constant coordination across five teams. I led the redesign into a rule-driven refund engine that automated routine refunds, surfaced only true exceptions and gave every team full visibility into the process.
The Symptom
The spreadsheet wasn't the problem.
When customers' banks rejected crypto transactions, those funds had to be returned.
Over time, every team involved had created its own workaround. Support tracked customer updates. FinCrime manually checked compliance conditions. Treasury monitored wallet balances. Engineering relied on tribal knowledge to understand what the process actually looked like.
The spreadsheet wasn't causing the complexity.
It was where all of that complexity ended up.
Our goal wasn't to automate a spreadsheet. It was to understand why the spreadsheet had become necessary in the first place.
The Real Problem
No one owned the end-to-end
The spreadsheet wasn't the problem — it was the symptom. Five teams each owned a slice of the refund process, but no one owned the outcome. FinCrime checked conditions. Compliance reviewed flags. Treasury managed wallets. Support handled customers. Engineering built what they were asked.
Without end-to-end ownership, each team optimised locally — and the gaps between them became the bottleneck. The spreadsheet filled the gap that a system should have covered.
The Investigation
We talked to everyone who touched this
Rather than designing a solution immediately, we started by interviewing every team involved in the refund process.
My initial assumption was that Support was the bottleneck. Those conversations quickly proved otherwise.
Each team experienced a different version of the problem, but together they revealed something much bigger: there was no shared understanding of how refunds should work end to end.
Instead of documenting individual pain points, we mapped every decision the system expected people to make.
The spreadsheet wasn't the problem. It was compensating for a system that couldn't make decisions on its own.
The Insight
The real problem wasn't manual work
The investigation changed how we thought about automation.
Most of the refund process didn't require people because it was complex.
It required people because the system had never been taught how to make predictable decisions. Once we separated routine refunds from genuine exceptions, the architecture became much simpler.
The Solution
Designing around decisions, not tasks
Once we understood where every manual decision came from, designing the solution became surprisingly straightforward. The goal wasn't to automate every step — it was to ensure the system made predictable decisions automatically, while giving people everything they needed to resolve genuine exceptions quickly.
The Outcome
Zero manual steps on clean cases
The Refund Engine went live across the full transaction flow. Clean cases resolved automatically. Exceptions surfaced to the right team with full context. Treasury finally had visibility into liquidity before it became a problem.
The Lesson
What this project changed for me
This project fundamentally changed how I think about operational tooling.
Before discussing another internal tool or workflow, I now ask three questions:
Can we avoid the work altogether?
If not, can we automate it?
If people still need to be involved, how can we make those decisions as fast and effortless as possible?
That way of thinking has shaped almost every operational product I've worked on since.