The automation the business asks for first is almost never the one with the highest return. We've run discovery on enough automation programmes to say this with confidence: requested automations reflect annoyance, not cost. The process people complain about in workshops is the one that interrupts their afternoon — not the one that quietly burns 4,000 hours a year across three departments without anyone owning the total. Annoyance is visible. Cost hides in the event logs.
That's why we don't start automation engagements with a wish-list workshop. We start with process mining: reconstructing how work actually flows through your systems, from the timestamps those systems already record. The gap between the process people describe and the process the logs reveal is, reliably, where the money is.
Your systems already recorded the truth
Every ERP transaction, CRM stage change and ticketing update leaves a timestamped event: case ID, activity, timestamp, user. String those events together per case and you get the real process map — not the four-box diagram on the wiki, but the forty-variant reality. When we mine a process for the first time, three findings show up almost every time:
- Hidden rework loops — cases that bounce back to an earlier step. A "five-step" order process where 30% of orders visit step two twice is really a seven-step process for a third of your volume.
- Approval ping-pong — documents ricocheting between two approvers, each round-trip adding a day of idle time while touch time stays at minutes.
- Long-tail variants — the "standard" path covers maybe 60% of cases; the other 40% spreads across dozens of variants, each one an exception someone is handling by hand.
None of this appears in interviews, because nobody sees the whole flow. The order clerk sees their screen. The approver sees their inbox. The event log sees everything.
The method: discover, quantify, rank, then build
Our pipeline is deliberately boring. First, extract the event logs from the source systems — usually two to three weeks of data engineering, and the hardest part of the whole exercise. Second, discover the real process map, including every variant and its frequency. Third, quantify what each variant costs: cycle time, touch time, error and rework rates, fully loaded labour cost. Fourth, rank candidates by a simple product: volume × time per case × error rate × automatability. That last factor is the engineering judgment — how rule-based the work is, how stable the systems are, how clean the inputs arrive. Only then does anything get built.
Don't automate the process people complain about. Automate the one the logs complain about.
The boring three-step reconciliation wins again
Here's the typical shape of what the ranking reveals. The flashy request — say, an AI-driven customer-onboarding workflow the leadership team has been pitched at a conference — scores poorly: moderate volume, high variability, low automatability. Meanwhile, a three-step reconciliation that nobody mentioned in a single workshop sits at the top of the table: thousands of cases a month, fifteen minutes of pure copy-compare-paste per case, a measurable error rate that triggers downstream rework. On a recent supply chain engagement, that unmentioned reconciliation beat the requested automation roughly 5:1 on projected ROI. It wasn't close. It's never close. The boring candidate wins because volume and repetition are exactly what deterministic automation is built for — and boring work is what people stop noticing they do.
From mining output to build pipeline
The ranked candidate list isn't a slide — it's the intake for the build pipeline. Each top candidate leaves the mining phase with its variant map (the bot's spec, essentially: happy path plus the exceptions worth handling), its baseline metrics (so post-deployment savings are measured against reality, not estimates), and its exception profile (which tells us whether this is a job for a deterministic UiPath bot, a bot with AI decision nodes, or an agent). The mining model stays live after go-live, so every quarter we re-rank: processes drift, volumes shift, and last year's seventh-ranked candidate becomes this year's first. That cadence — mine, rank, build, measure, repeat — is how our automation practice keeps a programme honest for years instead of quarters.
Key takeaways
- Requested automations reflect annoyance, not cost — the expensive processes hide in event logs, unowned and unnoticed.
- ERP, CRM and ticketing timestamps already contain the real process map: rework loops, approval ping-pong, long-tail variants.
- Rank candidates by volume × time × error rate × automatability — then build, in that order.
- Expect the "boring" reconciliation nobody mentioned to beat the flashy request — 5:1 on ROI is typical, not exceptional.
- Keep the mining model live after go-live and re-rank quarterly; it doubles as the bot's spec and the savings baseline.
Start with the logs, not the wish list
If you're sizing an automation programme, the first deliverable shouldn't be a bot — it should be a ranked, costed list of candidates derived from your own event data. It takes four to six weeks, and it routinely redirects the first year of build budget toward work that pays back several times faster. If you want to see what your event logs are hiding, talk to us — bring read access to one ERP or ticketing system and we'll show you the first process map within a fortnight.