The Long Tail of Workflows RPA Was Never Going to Reach
Most organisations that invested in robotic process automation automated the work that was worth automating under the rules of the time. What remains is a large, scattered body of manual work that was never a candidate, and it is worth looking at again.
Ask any operations leader how much of their organisation’s routine digital work has been automated, and the honest answer is usually “less than we expected”. Many programmes delivered what they promised on the processes they targeted. The shortfall is in the work that never made it onto the backlog.
That work is the long tail. It is made up of hundreds or thousands of small, varied, low volume tasks spread across teams, systems and geographies. Individually none of them justified a project. Collectively they account for a meaningful share of how people spend their working week.
Why RPA concentrated on the head of the distribution
RPA programmes were shaped by a simple piece of arithmetic: the cost to build and maintain a bot had to be recovered by the volume of work it removed. That arithmetic pushed every serious programme towards the same kind of process.
The ideal RPA candidate was high volume, stable, rules based and structured. Invoice matching, claims intake, account reconciliation and data migration all fitted that profile. A bot built once could run thousands of times a month, and the business case wrote itself.
The constraints that made those processes attractive also defined what was left out:
Build effort. Each automation needed process discovery, design, development and testing, usually by a specialist team or a partner. That fixed cost ruled out anything that only ran a few times a week.
Brittleness. Bots that rely on screen coordinates, selectors or fixed field positions break when an interface changes. Maintenance became a significant share of the total cost, so programmes avoided processes on systems that changed often.
Rigid logic. RPA follows rules. It struggles when a task requires reading context, handling an exception or making a judgement call that a person would make without thinking.
Centralised ownership. Automation was typically run through a Centre of Excellence with a prioritised pipeline. Small requests from individual teams rarely competed with large, quantifiable cases.
Most programmes were right to prioritise this way. The consequence is that the automation estate in most organisations is concentrated in a relatively small number of high volume processes, while the majority of distinct workflows remain manual.
What the long tail looks like inside an organisation
The long tail is rarely visible in one place, because it does not belong to one team. It shows up as the steady background effort that keeps operations moving.
Some recognisable examples:
A Finance analyst who logs into a supplier portal every week, downloads a statement, rekeys selected figures into a spreadsheet and then into the ERP.
An HR coordinator who copies details from an onboarding form into four separate systems, each with its own screens and quirks.
A service desk agent who checks a legacy application, a ticketing tool and an email thread before deciding what to do next.
An engineering team that extracts data from an older desktop application with no API so it can be used in a modern reporting tool.
A regional team running a monthly process that differs slightly from the same process in another country.
These tasks share a set of characteristics. They are low to moderate in volume. They cross several applications, often including older desktop or virtualised software with no integration layer. They involve small amounts of judgement or variation. And they are owned by the people who do them, not by IT.
The people closest to the work know where the time goes, but until recently they had no practical way to automate it themselves. The tasks were too small to justify a project, and too varied to be solved by a single platform rollout.
The hidden cost of leaving it unaddressed
Because no single long tail task looks expensive, the cost is easy to underestimate. It only becomes clear when the work is added up across a team or a function.
The most obvious cost is time. Skilled people spend part of every week on repetitive navigation, copying and checking. Ten minutes here and half an hour there does not appear in any budget line, but across hundreds of staff it amounts to a substantial amount of capacity.
There are less obvious costs too:
Error and rework. Manual rekeying introduces mistakes, and those mistakes tend to surface later in the process, where they are more expensive to correct.
Inconsistency. When the same task is done slightly differently by different people, the output varies and auditability suffers.
Dependence on individuals. Knowledge of how a task is done often lives with one or two people. When they are absent or leave, the work slows or stops.
Shadow tooling. Teams build their own macros, scripts and spreadsheets to cope. These are rarely documented, governed or secured.
Engagement. Experienced staff notice when a large part of their role is mechanical. It affects how they feel about the job and how long they stay.
Organisations that consider their automation programme mature may also stop looking for further opportunity, even though most of their manual work has not yet been touched.
What has changed: why the tail is worth revisiting now
The long tail was left alone because the economics did not work. Several of the assumptions behind those economics no longer hold in the same way.
AI can now interpret what is on the screen. Modern models can read an interface the way a person does, recognising fields, buttons and context rather than relying on fixed coordinates or selectors. This reduces the brittleness that made RPA maintenance so costly, and it opens up applications that were previously impractical to automate, including legacy and virtualised desktop software.
Workflows can be described rather than coded. Where a task once had to be mapped step by step by a developer, it can increasingly be captured by demonstrating it or describing it in plain language. That moves the build cost from weeks towards hours, which changes which tasks are worth automating at all.
Variation and judgement are less of a barrier. Tasks that involve reading a document, handling a minor exception or choosing between two paths no longer automatically disqualify a process. They still need care and oversight, but they are no longer out of scope by definition.
The people who own the work can take part. When building an automation no longer requires specialist development skills, the people closest to the task can contribute directly. That is the only practical way to reach work that is spread across hundreds of small teams.
Together, these shifts lower the threshold for what is worth automating. A task that runs twenty times a month may now justify the effort, where previously it needed to run thousands of times.
How organisations can revisit the tail
Addressing it does not require a new large scale programme. Approaching the long tail the same way as the head of the distribution would recreate the same constraints. A few practical questions help frame a better approach.
Where does manual digital work actually sit? Start with the people doing it. Ask teams which recurring tasks take time, cross several systems and feel mechanical. The answers are usually specific and immediate.
Which tasks were rejected or never submitted? Most automation teams hold a backlog of ideas that failed the original business case. That list is a ready made starting point.
Which applications have been treated as off limits? Legacy desktop software, virtualised applications and systems without APIs often explain why a process was excluded. It is worth checking whether that is still true.
What is the right governance model? Wider participation needs guardrails. Security, access control, audit trails and clear ownership should be designed in from the start, not added after shadow automation appears
How will success be measured? Long tail value is cumulative. Measure hours returned and errors avoided across many small workflows, rather than looking for a single large return from one process.
Some tasks are better solved by fixing the underlying process or integrating systems properly. Some involve judgement that should remain with a person. The goal is to stop excluding work simply because it was too small or awkward for earlier tools.
Closing thought
The first wave of automation proved that software could take on repetitive digital work. It also set a threshold for which work was worth the effort, and that threshold left most workflows untouched.
That threshold is now much lower, and organisations that revisit the long tail with fresh assumptions are likely to find more opportunity in the work they previously set aside than in the processes they have already automated. Much of that work can now be addressed, provided someone goes looking for it, and it’s a safe assumption that they won’t have to look very far.
