Straight-through processing — a transaction going end to end with zero human touches — is the number every ops leader quotes and almost nobody achieves. Benchmarks have moved from 10–15% to 70–90% at the teams that cracked it.
If yours is stuck in the teens, there's a piece of arithmetic that explains why, and it's the reason incremental effort keeps disappointing.
The arithmetic
Say your process has ten decision points, and you've automated each one to 90%.
End-to-end straight-through isn't 90%. It's:
0.9 ^ 10 = 0.348 -> ~35%
A chain of nine automated steps and one manual check isn't 90% automated. It's 0% — one human touch and the whole thing is a manual process with extra steps.
This explains the pattern everyone experiences: a team celebrates improving one step from 80% to 95%, and the end-to-end number barely moves, because the weakest link still routes everything to a human.
STP is a chain, and chains are governed by their worst point. So the strategy isn't "improve automation broadly." It's find the single point dumping the most volume into the manual queue and fix that.
The three reasons things fall out
Instrument your fallout and the reasons cluster into three buckets. All three are data problems, not workflow problems.
1. Missing data
The field a rule needs is blank, so the rule can't fire, so it routes to a human — who looks it up manually from a source you could have integrated. Every blank field is a manual queue.
2. Untrusted data
The field exists, but nobody believes it, so a human "verifies" it. This is the most insidious: you've automated a decision and then added a person to check the automation, which is worse than not automating. Trust should be a data-quality score, not a vibe.
3. Late data
The signal exists and is trustworthy but arrives tomorrow. Your check runs on an overnight batch, so the transaction waits. Latency turns a good decision into a manual queue.
How to actually move the number
Instrument fallout at field level first. Before changing anything, log why each case went manual — field-level, not category-level. "routed to review" is useless. "roof_age missing" is a work order.
Most teams can't do this today, which is exactly why their automation programmes are guesswork. This step alone usually reveals that three or four fields cause most of the fallout — a much shorter roadmap than anyone expected.
Then, in order:
- Rank fallout reasons by volume. Fix top-down. Not the easiest — the biggest.
- Close data gaps with enrichment, not people. If a field is missing, integrate a data provider. The feed costs trivially less than the human hours it eliminates.
- Fix latency only where the decision needs it. Move the decay-sensitive signals to a real-time path; leave the rest on batch. Streaming everything is expensive theatre.
- Score your data and let rules trust the score. Auto-proceed above a confidence threshold, escalate below it. "Untrusted data" becomes a tunable dial instead of blanket human review.
- Accept that some cases should be manual. The goal isn't 100%. Complex, high-value, genuinely ambiguous cases should reach an expert. STP is about making sure the simple 80% never does.
The reframe
Nobody gets to 90% by buying a better workflow engine. They get there by making the data at every decision point present, trusted, and timely — and by being ruthless about identifying which single point is dumping the most work on humans.
The workflow was never the bottleneck. It's just where the bottleneck becomes visible.
We build the real-time, quality-scored data foundations that make straight-through processing possible. More at IntelliBooks.
Top comments (0)