IE 11 Not Supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

The Hidden Costs of Robotic Process Automation in Government

Robotic process automation is increasingly popular as a way to speed up government work. But this isn't always the answer — and at times, it may cause an agency unforeseen headaches down the road.

It’s hard to overstate the role technology plays in the way governments operate. To appreciate this, we can simply look at recent examples where local governments — hit with ransomware and other types of cyber attacks — have taken the drastic step of turning off their digital systems. What these governments have learned the hard way is that it is next to impossible to operate in the 21st century without technology.

Because it is essential to the work of government, it’s more important than ever that agencies make sound technology choices. Some choices made in the short term have long-term costs that are not always obvious up front. This is the case with a choice that governments are increasingly making: robotic process automation (RPA).


A good way to think about the tradeoffs between short-term benefits and long-term costs with technology choices is to think in terms of debt.

If your car unexpectedly breaks down, the first thing you reach for is a credit card to pay the repair bill. Credit cards come with a relatively high interest rate, but in an emergency your other options may be limited. If the repair bill is reasonable and you can pay off the balance quickly, the long-term cost you pay for using the card is low. In contrast, if you were looking to buy a new car, the credit card in your wallet might be the least attractive option. With time to plan your purchase, you’ll opt for other kinds of debt with better terms and a much lower long-term cost.

The kind of debt you use matters. If we pay it down quickly, high-interest debt can be appropriate in the short term, while low-interest debt is far more appropriate for the long term.

It’s the same with technology.


RPA includes any software tool or utility that replaces repetitive, labor-intensive tasks with an automated process. It is an increasingly popular option for government agencies with legacy technology systems, complex workflows and backlogs for approving applications for services.

These agencies are like the unlucky driver who has a breakdown. Faced with an unexpected crisis and pressed for time, options may be limited. It is understandable that some agencies choose RPA tools as a way to resolve pressing issues in the short term. But like a high-interest credit card, the convenience and immediate relief provided by RPA comes with some long-term costs.


Automations built on a specific RPA platform are not always portable to other platforms. RPA tools can tightly couple agencies to a specific vendor. While vendor neutrality is always important in evaluating technology choices, it is particularly important here as the industry is still new and changing rapidly. Vendor consolidation, support for different features and rapid changes in pricing are to be expected.

This situation is not unlike the one agencies face when they evaluate different cloud service providers, which can include a dizzying array of choices. Agencies evaluating different cloud service options should consider how tightly a solution would wed the agency to a specific provider. Will building a cloud service option into an agency solution make it impossible to transition away from the platform down the road? These are the kinds of questions agencies need to ask before they invest in a specific technology platform or tool.


RPA tools by themselves cannot dramatically improve the user experience of government services. Processes that are complex, require multiple steps, with multiple review and approval stages, often place an enormous administrative burden on those that use them. RPA tools don’t enable an agency to re-engineer a broken process, or improve an end user’s experience — they simply try to make an existing broken process go faster. And while this is certainly important, by itself this will not allow agencies to realize other objectives for improving customer experience such as adopting plain language or enhancing accessibility.


Complex government processes typically have multiple stakeholders, span multiple legacy systems and involve different sets of employees. Trying to shoehorn an automated step into one small part of a long, complex process can create new and unforeseen problems.

When I worked for the city of Philadelphia, one focus area for technology teams across the city was property information. This information was scattered across agency websites, and when an agency employee needed information about a property (for example, to issue a building permit), they had to open a web browser and manually search for that address on another agency’s website. This situation was highly inefficient, but was a result of using multiple unintegrated legacy systems to manage property information at separate agencies.

As a remedy, one employee developed an automation that allowed property data from one agency to be “scraped” and exposed to other agencies via an API. This approach dramatically reduced the time and effort required to access important property information, making it easy for anyone to access this data for their own processes. As a result, requests for property data through this automation shot up dramatically. This had the unintended consequence of spiking traffic on the agency website being scraped, causing instability and service interruptions. After the automation was implemented, the process for getting property information was still broken — just in a different way.

This effect of “moving the bottleneck” can happen with RPA. By focusing automation on a narrow part of a much larger process, RPA tools can have unintended consequences for actors farther downstream in the process. Where a manual step might be completed dozens of times a day, an automated version of the same step might be completed thousands of times per day. Unless all steps along the chain in that process are able to accommodate the increased throughput, a new bottleneck will develop. Instead of eliminating a bottleneck, RPA may just move it further along in the process.


Just as using high-interest debt in the short term can be acceptable if it is paid down quickly, using RPA in the short term can make sense as well — but only if there is a plan to pay down this debt within a reasonable time frame. Too often, agencies approach RPA without applying a framework for managing it and (eventually) retiring it.

A useful framework for implementing RPA is to apply a four-step approach:
  • Eliminate: If a process is not clearly required and is eating up lots of staff time, consider eliminating it.
  • Optimize: If a process is required, undertake efforts to optimize it by reducing unnecessary complexity or unneeded steps.
  • Automate: If a required process has been fully optimized and still requires lots of staff time, consider how automation might speed up the process.
  • Modernize: If a process has been automated to accommodate a lack of proper integration between legacy systems, plan to deprecate this automation when the underlying systems are upgraded and modernized.

If agencies don’t make plans for moving away from RPA, it’s akin to making just the minimum payment on a high-interest credit card each month. The underlying debt doesn’t go away, it just grows larger and the problem gets more acute.

While RPA can be a sensible choice in the short term, agencies should take steps to pay down this high-interest debt and move on.

Mark Headd is a government technology SME at Ad Hoc. He is the former chief data officer for the city of Philadelphia, serving as one of the first municipal chief data officers in the U.S.