Why Your Automation Pipeline Is Dry (It Isn't the Ideas)

The dashboard was beautiful.

That is the part I remember best. It went up on the big screen in a steering meeting: every process variant in its own colour, handoffs drawn as arcs between teams, and a heatmap of where the hours went, glowing orange over accounts receivable. Somebody photographed it on their phone. Somebody else said, and meant it, that this was the most the company had ever known about how it actually worked.

A few months later the company announced it would stop doing new automations.

I didn't run that programme. A colleague did, at a US healthcare company large enough to have a proper automation Centre of Excellence, a steering committee, and a budget line for something called discovery. I watched it from close enough to see the meetings and far enough away to have nothing to defend. I have thought about that dashboard more than I have thought about most of the bots I built myself.

The pipeline had gone dry

Every CoE I have worked with in twelve years runs the same ritual. An idea comes in on a form. Somebody scores it on volume, complexity and savings. A lead approves or parks it. A handful get built each quarter.

It works well for a while. The obvious candidates get built in year one, the big invoice flows and the reports everyone hated. Then what's left on the sheet is smaller and messier, and it stops clearing the ROI column. The ideas sheet thins out. Leadership starts asking where the pipeline went.

That's where the head of automation was. And the bet they made was a reasonable one. Bring in a process mining platform, put its recorder on desktops, let real work data find the candidates instead of whoever complained loudest. A data-driven pipeline. The kickoff deck had a funnel on it. I'm fairly sure every kickoff deck of that era had a funnel on it.

What the recording saw

The agents went onto desktops and recorded. Clicks, application switches, copy and paste, the time between one system state and the next, screenshots with patient data masked out.

This part tends to get skipped when people tell the story: the output was good. The maps were real. The variants were real. Nobody faked anything, and the vendor delivered what the contract said.

The vendors' own guidance for this kind of capture is a handful of users over a week or two. UiPath's guidance for its unassisted task mining, for example, recommended two to seven users and somewhere between twenty and seventy thousand recorded actions. That is enough to see a pattern in daily work. Hold on to that number, because the interesting part is what a sample that size cannot see.

What it couldn't see

Month end, for a start. If the recording window doesn't cross it, the most painful week of the finance calendar simply isn't in the data.

The Excel tracker in accounts receivable, with a rule buried in it that says if the payer is this one, hold the claim till the fifth. The email thread that decides whether an adjustment gets booked this month or next. The analyst who stopped trusting one particular report two years ago and opens a different one first, every time, without thinking about it.

On the dashboard, all of that looked identical. User edited cell D14. User switched to Outlook. User edited cell D14. Forty thousand times.

What did that heatmap know that the AR team lead couldn't have told you over chai in ten minutes?

The philosopher Michael Polanyi had a line for this in 1966: we can know more than we can tell. He was talking about tacit knowledge, the stuff you do by feel. Task mining has the opposite problem. It can record more than it can know.

The same narrow pipe

So the mining produced a list of candidates, ranked and colour coded. Then each one went into the queue that existed before any of this started.

Somebody still had to sit next to the user and ask what happens when the payer is that one. Somebody still had to write the process document, get it signed off, build the bot, test it, fix it. Same team. Same capacity. Same five or so a quarter.

The easy version of this story blames the tool, and it's wrong. The mining didn't kill the programme. It just didn't save it. The map shortened the part of the job that was already short, finding the work, and left the long part exactly as long as it was.

Every idea still had to squeeze through the same narrow pipe, and the pipe was the build.

A few months after that meeting, the announcement came. No new automations.

It wasn't one company

Look at the industry numbers from those years and the story stops being unusual. Deloitte's surveys found that only 8% of organisations were running more than fifty automations in 2019. By 2020 it was 13%, and more than a third were still stuck piloting between one and ten. In their 2022 survey, the average payback for organisations still piloting had stretched from 16 months to 22.

What programmes were short of was build capacity. Discovery tools got sold into that gap because discovery was the part that could be sold.

The vendors seem to have reached the same conclusion. UiPath has spent the last three years retiring its own task mining products, one deployment option at a time. In September 2026 it launched Cartographer, an AI agent that builds the process map from conversations, documents and recordings, and asks about the exceptions.

Why does a company that sold passive capture for years now sell an agent that asks people questions?

Rationing made mining necessary

Nobody in that steering meeting saw this, me included. None of us could have, back then.

Task mining exists because automation had to be rationed. When every bot costs weeks of a developer's time, you need machinery to pick the few that are worth it: recorders, scoring sheets, committees, funnels on slides. The whole apparatus is a response to the build being expensive.

AI is changing the cost of the build. It's still work, and some tasks will always be hard. But it's cheap enough now that if most of the tasks on the ideas sheet can be automated, a committee picking five a quarter starts to look like it's guarding the wrong door.

And once the question stops being which task, it becomes a much harder one. How, exactly, is this task done? What's the rule in D14? Why that payer? Why that report first?

The dashboard can't answer that. Only the person clicking can.

What we're building instead

This is the bet behind Guerrilla Bots, and I'll keep it short because this isn't a product page.

Start from the task the person already knows is painful. They don't need a heatmap to find it. Let them record themselves doing it, once. Capture the steps, and capture the logic too: the rules in the workbook, the reasons behind the judgement calls, asked about while they work instead of reconstructed later in a workshop. Then build from that.

By the time the recording ends, most of the bot is built. The process document comes out of the same session, written from what was actually captured rather than from a workshop three weeks later.

IT still approves the environment. The CoE still sees every automation. What changes is who does the specifying.

If you want the full breakdown of where task mining falls short, and where it still earns its place, it's in task mining limitations.

I still think about that photo of the dashboard somebody took on their phone. It's probably still in a camera roll somewhere, between a birthday cake and a parking spot.

Mining finds the work. Nobody was short of work.