How we cut an approval cycle from 4 days to same-day

A fintech ops team came to us with a problem that looked simple on the surface: their approval cycle was taking 4 days on average, and they wanted it faster.

When we dug in, the problem wasn’t speed. It was prep time.

What was actually happening

Before a reviewer could make any decision, someone had to manually pull the item from the intake system, cross-reference it with two other tools, confirm nothing was missing, and forward it to the right person by email. That process took 20-40 minutes per item. Reviewers weren’t slow. The pre-work before they even saw the item was the bottleneck.

The team had tried Zapier. It handled the straightforward cases fine. The problem was the 20% that weren’t straightforward: items with missing data, items that needed a different reviewer depending on a combination of factors, items where something looked wrong and someone needed to flag it before it went anywhere. All of that fell back to manual work, and that manual work was what was taking 4 days.

What we built

We replaced the entire process with a custom automation engine. Here’s what it does:

Intake. Every morning (and every 4 hours throughout the day), the system pulls from all three source tools automatically. No one has to kick it off.

Validation. Before anything goes to a reviewer, the system runs a set of validation checks: is all required data present, do the values across systems match, does anything look anomalous based on historical patterns. Items that pass go to the review queue. Items that fail go to a triage queue with specific flags explaining what’s wrong.

Routing. The routing rules are encoded in code, not a Zapier flowchart. Each item is assigned to the right reviewer based on type, value band, and current queue depth. If the primary reviewer has more than 8 open items, it routes to the secondary.

Review interface. Reviewers don’t open email. They open one screen that shows their queue, and each item in the queue shows everything they need to decide — data from all three source systems, the validation results, and any flags. One screen, full context.

Slack alerts. When a new item is assigned, the reviewer gets a Slack notification with a direct link. No inbox required.

Audit log. Every assignment, every decision, every flag is logged with a timestamp. Exportable for compliance on demand.

What the hard part actually was

Not the code. The hard part was agreeing on the routing rules.

The ops team thought they had simple rules. When we started documenting them, it turned out the “simple rules” had about 40 edge cases that lived entirely in one person’s head. A subset of items went to a specific reviewer not because of a rule anyone had written down, but because that reviewer had industry-specific knowledge that everyone had assumed but never codified.

We spent the first two weeks of the engagement doing nothing but process documentation. Walking through 50 historical items and asking “why did this go to this person, and not that one?” before we wrote a line of code.

That documentation work is what made the automation trustworthy. The code was 6 weeks. The knowledge capture was 2 weeks and it was the more important part.

The results

• Approval cycle: 4 days down to same-day (items submitted before noon are typically resolved by end of day)
• Manual daily prep work: eliminated entirely
• Missed approvals in the first 6 months post-launch: zero
• Reviewer time per item: roughly the same — we didn’t cut the review time, we cut the wait time before review

The reviewer who used to spend the first 2 hours of every morning routing things now opens the dashboard, sees their queue, and starts deciding. That’s the whole change.

What this applies to

If your approval process involves pulling data from more than one place before someone can decide, and that prep work is what’s creating the delay, custom routing automation is worth evaluating. The key question is whether your routing rules are actually codifiable. If they live in one person’s head and that person is the only one who can route correctly, you have a knowledge problem before you have an automation problem.

We can help with both.