Your process takes four days. Six hours of it is work.
The rest is waiting — for a handoff, an approval, someone to come back from lunch, a queue to clear. Speeding up the steps barely helps. Removing the gaps between them changes everything. That's what I build.
Same process, before and after. Watch where the time actually goes.
Three common processes, mapped as they usually run. Pick one, then flip between today and after.
—
You can't hire your way out of a process problem
Adding people to a process with six handoffs gives you a process with six handoffs and a bigger payroll. The queues stay exactly where they were.
Waiting is usually 70–90% of elapsed time
In most operational processes, the actual work is a small fraction of how long the thing takes. Everyone measures the work because it's the part you can see on a timesheet.
Every handoff is a queue in disguise
Passing work to another person doesn't cost a minute, it costs however long until that person next looks. Removing a handoff removes a queue, which is worth far more than making a step faster.
Most steps are gathering, not deciding
Look closely and half the steps are someone finding, copying, checking or formatting information. That's the part a machine does well — and it's the part that creates the handoffs.
Compression compounds
A process that takes four days can only run so many times. Get it to four hours and capacity, cash cycle and customer experience all move at once — from one change.
Five moves that account for most of the compression
None of them are exotic. The reason they haven't been done already is that each needs an engineer who understands both the process and the model.
Merge gathering steps into one
Where three people each fetch something from a different system, one retrieval layer fetches all three at once. Three steps and two handoffs become one step and none.
Example: an onboarding check where credit, identity and prior-account history each sat with a different team becomes a single assembled file, ready for one reviewer.
Decide the easy cases before a human sees them
Most queues are 70% routine and 30% interesting, but everything gets read at the same depth because you can't tell which is which without looking. Classification separates them on arrival.
Example: the routine 70% arrive pre-filled with a recommendation for a two-second confirmation. The reviewer's day becomes the 30% that needs them.
Catch the missing thing at the start, not the end
The most expensive waiting is the loop: work goes forward three steps, someone spots an absent document, it goes back to the beginning. Validating completeness at intake removes the whole round trip.
Example: a submission is checked against requirements on arrival, so the request for the missing item goes out on day one rather than day four.
Turn writing into reviewing
Producing a document from scratch is slow and gets scheduled for later. Checking one is fast and gets done now — which removes the queue as much as it removes the minutes.
Example: a case summary, response letter or report assembled from the underlying records, with sources cited, for someone to correct rather than compose.
Route by confidence, not by role
Traditional routing sends everything to whoever owns that step. Confidence-based routing sends only the uncertain cases to the expensive person, and the clear ones straight through.
Example: anything the system is sure about proceeds; anything it isn't goes to a senior reviewer with the reasoning attached, so they start from a position rather than a blank page.
What I won't compress
Compression has a floor, and pretending otherwise is how these projects end badly.
- Decisions that carry real consequence. The system assembles, recommends and explains. A person decides. That boundary is set with you in week one and written down.
- Steps that exist because a regulator says so. If a rule requires a named human to review something, the review stays. I can make it take four minutes instead of forty.
- Waiting that's actually somebody else's. If your process waits on a customer, a bank or a supplier, that's their queue. I'll show it on the map so it's visible, but I can't remove it.
- Processes nobody has written down. If the process only exists in three people's heads and they each describe it differently, mapping it is the first job — and sometimes the only one you need.
- Anything where the volume is too low to matter. Something that runs twice a month isn't worth automating, however annoying it is. I'll tell you that for free.
Map first. Build only what the map justifies.
The mapping week frequently finds a change worth making that needs no AI at all. I'll tell you when that's the case.
Map and time it
I sit with the people running the process and time it properly — including the waiting. You get the map whatever happens next, and it's usually the first time anyone has seen the whole thing.
Agree the target
Which steps collapse, which stay, where the human decision boundary sits, and what "correct" means for each automated step. Signed off before anything is built.
Build and run in parallel
The new path runs alongside the old one on real work, so you can compare outputs without risking anything. Differences get investigated, not overridden.
Switch over and hand off
Cut across once the parallel run is boring. Runbook, monitoring and the re-timed map, so you can prove the change to whoever approved it.
Published, so you can budget before we talk
Start with the map. It's cheap, it's useful on its own, and it's the only honest way to price the rest.
One process, timed properly, with the compression opportunities ranked.
$4,500One week · credited against a build
- Every step timed, including the waiting
- Cost per run at your real loaded rates
- Opportunities ranked by value and difficulty
- Including the fixes that need no AI
- Yours to keep and act on without me
One process rebuilt, run in parallel, then switched over.
$18k – $40k6–8 weeks · map credited
- Target elapsed time agreed up front
- Parallel run against the existing process
- Accuracy measured per automated step
- Integrates with the systems you already run
- Runbook, monitoring and handover
The next process, and the one after that, on a monthly rhythm.
from $6,500/moCancel any month · 30 days notice
- A new compression each month
- Everything already shipped kept running
- Monthly re-timing so drift is visible
- Your engineers can pair at no extra cost
- Designed so you stop needing me
The target is agreed, and it's binding
Before a build starts, we write down the target elapsed time and the accuracy bar for each automated step — using the numbers from your own mapping week, not mine. If the finished system misses them, I keep working at my cost until it doesn't.
I can offer that because the mapping week means I'm not guessing. Anyone who quotes you a compression target without measuring the process first is selling optimism.
Model and infrastructure costs sit in your own accounts, typically $80–$400 a month. Not marked up.
What operations leads ask first
How is this different from n8n, Zapier or an RPA tool?
Those move structured data between systems on rules you define in advance, and they're excellent at it. If your process is genuinely deterministic — this field goes to that system when this happens — use them. They're cheaper than me and faster to set up.
Where they stop is judgement. When a step requires reading an unstructured document, deciding which category something falls into, or assembling an answer from several sources, a rules engine needs a human to bridge the gap — and that human is where the handoff and the queue come from. I build the bridge so the rule engine can carry the whole path. Often the right answer is both: automation tooling for the plumbing, a model for the judgement.
Won't this just move the bottleneck somewhere else?
Frequently, yes — and that's why the map matters. Compressing a step that isn't the constraint produces no improvement at all, just a bigger queue in front of the real bottleneck.
The mapping week identifies the actual constraint before anything is built. Sometimes the honest finding is that the constraint is a person's availability or an upstream team, and no amount of AI in your process will help.
Are we going to make people redundant?
That's your decision, not a side effect. In most compressions the headcount stays and throughput rises — the same team handles more, with the tedious gathering removed and the judgement work left.
If reducing headcount is the goal, say so at the start. It changes what gets built and how success is measured, and I'd rather design for the real objective than discover it in month three.
Our process changes constantly. Won't this break?
It will drift, which is why monitoring is part of every build and why the ongoing option exists. What I try to avoid is hard-coding the process shape into the system — the steps are configuration, so a changed rule is an edit rather than a rebuild.
The bigger risk is silent drift: quality degrading while everyone assumes it's fine. That's what the monthly re-timing catches.
What if the map says we shouldn't do this?
Then that's what it says, and you've spent a week's fee to avoid spending a build's fee. It happens often enough that I plan for it — usually because the real constraint is elsewhere, the volume is too low, or the process needs writing down before anything else.
You keep the map either way. Several clients have acted on it themselves without hiring me for the build, which is a completely fine outcome.
How much of our team's time does this take?
The mapping week needs a few hours from whoever actually runs the process — not their manager's description of it, which is reliably different. After that, roughly two hours a week from one person, mostly answering "is this output right?"
The parallel run is the light part: your team keeps working normally and the new path runs alongside.
I've spent eight years building pipelines that run without anyone watching
I'm Bahman Shadmehr. Automated trading platforms placing orders on the Texas wholesale power market, a US equities trading system, a national payment gateway I helped decompose while it was live, and the Kubernetes and data infrastructure underneath all of it.
Trading pipelines are process compression taken to its extreme: every handoff removed, every step timed, and instrumentation on all of it because there's nobody there to notice a problem. The same instincts apply to a four-day onboarding process — measure first, remove the queues, and know immediately when something drifts.
You deal with me from the first call to handover. No account manager, no team you never meet.
Python, Go, Kubernetes, Docker, AWS, GCP, Postgres, Redis, RabbitMQ, Celery, Prometheus. Remote, UTC+3. 76 technical posts · LinkedIn
Name the process everyone complains about
Tell me roughly how long it takes end to end and how many people touch it. I'll tell you within a day whether the time is likely in the work or in the waiting — and those need completely different fixes.
info@bshadmehr.meUseful in a first message
- The process, and what triggers it.
- How long it takes end to end, roughly.
- How many people or teams touch it.
- How many times it runs a week.
- Where it most often gets stuck.