Robotic process automation is having its best year, and for the least strategic reasons in its history. The purchases being signed this autumn are not the output of transformation roadmaps. They are replacements: for a clerk who cannot get to the office to key a batch, for a volume spike nobody planned, or for a headcount that was removed in the second quarter while the work kept arriving. That distinction matters more than the adoption numbers. Automation bought as a substitution behaves differently from automation bought as a strategy. It targets different processes, it skips the analysis, it is funded from a continuity budget, and it leaves behind an estate of software robots that nobody has agreed to maintain.
Three triggers, three different things
It is worth separating what actually caused each bot, because the right treatment differs. Physically anchored work. Somebody had to be in the building: to key from paper, to collect a stamped document, to operate a terminal that only exists on a desk. The automation here is genuinely valuable and often permanent, because the physical dependency was never a good idea. Volume shocks. Refunds, cancellations, credit notes, payment deferral requests, relief claims. Enormous, unfamiliar queues arriving in weeks. The automation is a surge response and, in most cases, the volume will normalise. Headcount that left. The work did not leave with it. This is the most common trigger this autumn and the least discussed, because it is awkward. It also produces the worst automation, since nobody redesigned the process before encoding it — they simply mechanised what the departed person used to do, including the parts that were already wrong.
The question nobody is asking: how long is this bot for?
Every robot built this year should carry a label, and almost none do. Some automate processes that will exist in 2025. Some automate processes invented in April that will be irrelevant by next summer — the furlough claim, the deferral workflow, the workaround for a closed counter. Both are being built with the same tooling, into the same environment, with no marker distinguishing them. The consequence arrives in about eighteen months, when the estate is large, half of it is dead weight, and no one can tell which half. Deleting a bot requires knowing what it was for and who depended on it, and that knowledge lives with people who are already leaving. So put an expiry date on every automation built for a temporary process, record it, and review the list quarterly. Permanent automations get a process owner, documented inputs and outputs, and a maintenance budget. Temporary ones get a date and a plan to remove them. This costs an hour per bot and it is the single most valuable governance step available right now.
| Automation type | Record and review |
|---|---|
| Temporary surge or workaround | Expiry condition, dependencies and removal plan |
| Permanent process | Named owner, inputs, outputs and maintenance budget |
| Either type | Identifiable service account, scoped access and protected credentials |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Why the 2020 estates break more than usual
UI-driven automation is brittle by nature. It is far more brittle when the underlying environment is being rebuilt at the same time. This year's bots were built against systems that were themselves moving: applications relocated behind new remote access, portals redesigned, sign-in journeys changed, multi-factor prompts introduced. A robot that navigates screens has no tolerance for any of it. Teams that automated in April have spent the autumn repairing rather than expanding. There is also an access problem that is peculiar to substitution automation. When a bot replaces a person, the fastest path is to run it under that person's login, with the password in the script or the orchestrator. This year that has produced an uncomfortable number of robots operating under the credentials of employees who have left the company, in systems where the audit trail attributes every transaction to a human being who was made redundant in June. Unattended automation also breaks awkwardly against multi-factor authentication, which is why the standard workaround is to exempt the bot account from it, which is how automation quietly becomes the weakest identity in the estate. Fix the pattern before the estate grows: named service accounts, credentials in a vault rather than in a script, least privilege rather than inherited human access, and the bot identifiable in the log as a bot.
Automate last, not first
The ranking that holds up is uncomfortable for anyone holding a licence. Eliminate. A surprising share of automated work should not happen at all. The report nobody reads. The second approval that duplicates the first. The reconciliation that exists because of a policy you could change this week. Simplify. Reduce variants and exceptions. Automating six variants of the same process is the most expensive possible way to avoid a decision about which one is correct. Integrate. If two systems both have interfaces, a supported integration is cheaper to own than a robot typing between them, and it does not break when a screen layout changes. Then automate. Software robots are the right answer when the system has no interface, the vendor will not build one, the process is stable and the volume justifies the maintenance. The emergency licences and free trials that vendors offered in the spring distorted this ordering badly, because the bot appeared to cost nothing at the moment of the decision. The licence was never the cost. The maintenance is the cost, and it arrives in year two.
Practical Guidance for RPA Implementation Strategy
- Label every bot permanent or temporary, with an expiry date on the temporary ones. Do this retrospectively for everything built since March.
- Move bots to named service accounts with vaulted credentials. No robot should be operating as a departed employee, and no password belongs in a script.
- Apply the elimination test before the automation test. If a step can be removed or a policy changed, that beats any robot on total cost.
- Never encode rates, thresholds or account codes in automation logic. They change, usually with three weeks' notice and no warning to the automation team.
- Assign a named process owner to every permanent automation. A bot without an owner is an outage with a delay fuse.
- Build the bot inventory before the auditors ask for it. What it does, which system, which account, who approved it, what evidence it leaves behind.
- Check the regulatory roadmap before automating a compliance process. Automating data entry into a process that is about to be replaced by a mandated interface is money spent twice.
- Be straight with the team about what the automation is for. They already know; pretending otherwise costs you the cooperation you need to document the process.
The Regional Angle
Four points matter particularly here. First, resist automating government portals with screen robots, however tempting it looks. A large proportion of back office work in this region is interaction with public platforms: immigration and labour portals, customs systems, tax filing, municipality and chamber services. These are precisely the queues that hurt, and precisely the worst automation targets. They use image challenges, hardware tokens and one-time codes sent to a registered mobile; they change layout without notice or notification; and their terms of use generally do not contemplate automated access at all, which raises a question nobody wants to answer during an inspection. The durable answers are batching, proper delegation to your public relations officer, and waiting for the official interfaces that several authorities are now publishing. Screen automation against a government portal is a maintenance subscription, not a solution. Second, this year has already supplied a regional stress test for automation discipline, and the results were poor. When the Saudi value added tax rate tripled on 1 July, organisations discovered how many of their scripts, macros and bots had the rate written into them. Some of those failures were visible immediately; others produced quietly wrong output for weeks. The rule is absolute: rates, thresholds, account codes and entity identifiers belong in maintained configuration, never in automation logic, and any bot that touches tax should be tested against a rate change as a matter of routine. Third, time your automation against the regulatory calendar rather than the licence renewal. Saudi Arabia is consulting on electronic invoicing now, with rules expected shortly and implementation to follow within roughly a year, and other regional authorities are moving in the same direction. Automating the keying and issuing of invoices with screen robots in this window means building an asset with a known short life. Where a mandated interface is coming, wait for it and spend the money on the data quality that the interface will expose. Fourth, do the business case with local arithmetic. Vendor return-on-investment models are built on the salary of a European or American processing clerk, and clerical labour in this market costs considerably less, which makes a per-bot licence priced in dollars look very different here. The offsetting factor runs the other way: headcount in the Gulf carries visa fees, accommodation, annual tickets, end-of-service gratuity and notice periods, and it cannot be flexed in a fortnight. Build the comparison on fully loaded cost and on flexibility, not on the case study in the deck, and expect a smaller but more honest number.
The objection worth taking seriously
The strongest criticism of this entire category is that it is a tax on bad architecture. A robot typing between two systems exists because those systems cannot talk to each other, which means the organisation is paying twice: once for software that will not integrate, and again for a fragile mechanical typist to compensate. Worse, the robot removes the pain that would otherwise have forced the real decision, so the underlying defect becomes permanent. Automate a broken process and you have industrialised it. That argument is correct and it is not always actionable. Replacing the system requires capital and a year; building the integration requires a vendor who will cooperate and often a licence tier nobody budgeted for. In a year when capital projects were suspended in March and have not all restarted, a bot that buys three years of relief on a genuinely painful process is a defensible tactical purchase. The condition is honesty about what it is. Tactical, dated, owned, documented, and recorded on the list of things to remove when the underlying problem is fixed. The organisations that will regret this year are not the ones that automated quickly. They are the ones that automated quickly and then described it, in the following year's board pack, as a digital transformation.
Common Questions
Is now a bad time to start with automation?
No, but it is a bad time to start without labelling. Volumes and processes are unusually unstable, so build for a short life and say so explicitly.
How many bots is too many?
The limit is maintenance capacity, not licences. If you cannot name the owner of every automation and fix a breakage within a day, the estate is already larger than the organisation can carry.
Should we use the automation in our existing software suite or buy a specialist platform?
For a modest estate of simple tasks, the bundled tooling is usually sufficient and considerably cheaper to own. Specialist platforms earn their cost at scale, with complex orchestration and real governance requirements.
What should we expect over the next twelve months?
Expect the large software suites to keep absorbing desktop automation into products customers already pay for, which will compress specialist pricing through 2021. Expect vendors to bundle process mining and document understanding to escape the commodity trap. Expect the bills for this year's hurried estates to arrive as maintenance and breakage in the second half of next year. And expect external auditors to start asking pointed questions this coming season about who authorised the postings that a robot made under a former employee's login.
RPA Implementation Strategy — we label the estate you already built, fix the identity and credential pattern underneath it, and decide what should be eliminated rather than automated.