RPA has been going through a huge boom in the last six years and now we are about to see a shift in how enterprises adopt RPA. Now I’ve been following the RPA space since 2016 and this is what I’ve seen.

2016-2018: 1st gen winners appear to the big audience... There are talks about “a bot for every employee” and RPA is framed as a magical AI driven tech that simply watches what you do and automates that. A ton of focus was placed on attended and desktop bot use-cases.

2019-2020: I counted at least 100 RPA tech vendors on the market. It seemed that there was a new tool coming out every week. A lot of consolidation started happening as well when big platforms started to acquire RPA capabilities.

There was little to no differentiation between the upstarts. Many vendors were touting intelligent automation, hyperautomation, cognitive automation and really saying just about anything they could come up with to differentiate their brand in the crowd. Industry pundits were big on fantasies about autonomous intelligent bots but the reality in the IT trenches couldn’t be further from that.

At the same time there were a lot of skeptics asking if RPA is a band-aid technology and questioning if it would ever become a real market category.

Citizen developers were still the focus of the analyst industry but customers began seeing more value from headless to unattended automation - an example of this was bots that crunch big back office workloads. It’s clear that RPA isn’t a tech where citizen developers create magical assistants on their desktop and instead every company is standing up teams to operate RPA internally.

2021-2022: RPA has been validated as a “must have” for every enterprise. We’ve seen teams running hundreds of bots and felt the pain of scaling. 1st gen winners start expanding TAM by adding features in areas like document processing, process discovery, API connectivity.

Today I’m seeing a lot of software vendors looking to add RPA capabilities into their products. My bet is that every single integration platform will have RPA-like capabilities within two years. There’s also a push by RPA service providers into the mid-market – more on that some other time.

I think we are at a point in the RPA hype cycle that we are coming out from a slump in expectations.

So where does the enterprise go with RPA from here? We know what’s working, how it's working, what’s real and what’s fantasy. 1st gen platforms have gotten so big and complex, not to mention expensive and heavy to operate. They might be good at the basic RPA tasks but mediocre at best in everything around that.

I know it’s just one stock but UiPath hasn’t performed well against the S&P tech index for a variety of reasons. Looking back on UiPath’s move to becoming a publicly traded company, it is clear it was built with a significant amount of hype revolving around the promise of a one-stop “fully automated enterprise” and being the next SAP. Sure the market is pulling the rug under many other tech stocks as well but $PATH is right up there with Peloton and Zoom. Another 1st gen leader, Blue Prism, was just purchased by a private equity firm.

According to Gartner, by 2024, 40% of RPA buyers will utilize a multi-vendor strategy. This points to a different future than the vision of single enterprise wide automation platforms taking over. We have dedicated technologies, such as Instabase for dealing with unstructured documents, and Celonis for understanding processes.

We started working on Robocorp in 2018 and incorporated in 2019 with a vision to build an open-source technology stack and community for RPA developers. It was a counter move to the early hype about magic and AI in business process automation. We knew that citizen developers cannot ship big and powerful headless automations and that’s where a lot of the value is going to be generated.

We also missed some things with our initial idea. The shift to cloud has been slower than expected, although enterprise loves our cloud-native pricing that’s based on consumption. We also underestimated the power of low-code when done right and that’s why we’ve course corrected and built Automation Studio.

An important side note, low-code in RPA isn’t about enabling everyone to build bots. Just look at low-code game development platform Unity that started with a vision to enable everyone to make games, but it’s still a complex professional tool. This is how we see low-code and RPA, and we’ve created a tool that’s easy to pick up and powerful to use for the long term.

Now, observing the shift in RPA narratives, I think we are at a point where a dual aka multi vendor strategy will be key for success in enterprise RPA. Looking at Wikipedia definitions of the hype cycle phases, it’s safe to say that we’re entering phase 4.

The future of RPA is bright in the sense that it’s getting used by more and more companies every day, and those companies are seeing real value. Some of our enterprise customers have seen massive improvements in TCO by replacing their old bots with Robocorp. Many others are looking to add a second RPA vendor because they don’t want to be locked in and get stuffed with more features they don’t use.

There is not going to be a single platform that powers hyper-automation for the enterprise. Instead we are going to see that in 2022-2023 more enterprise RPA users will add complementary technologies into their operations and by doing that, they will have access to the best of each category.

Multi Vendor Strategy is the New RPA Normal

We all know that Gen1 RPA licensing is complicated and messed up. They all use the same licensing model because they were built before the cloud was invented and are fundamentally based on an on-prem world.

What’s broken in RPA licensing and pricing?

To highlight the key challenge with RPA licenses, here's how Gen1 works.

Every runtime environment (this is the bot license)

Developer tools for everyone building RPA bots

Add-ons like intelligent document processing or process discovery

Software licenses for business applications used by bots


Ok, so it has many components but what's really the problem? It's very rigid.

People are measuring the utilization rate of bots, and the industry average hovers around 30% or less. The bot license is treated like an industrial asset with fixed capex and you'll want to squeeze as much value out of that asset as possible.

Large RPA operations struggle with balancing license utilization while trying to meet the business user’s service level expectation. If you stack up too many bot licenses, then you'll have excess capacity and wasted resources. If you have too little capacity, you might have a good utilization rate on paper but you'll need to turn down use-cases that don't fit with your available resources. 

I talked with one large company that had a 90% utilization rate but they ended up hiring a ton of people to fill gaps in some end-of-the month use-cases that would have demanded a few thousand bot hours of capacity. Talk about wasted opportunity, and it's all due to licensing.

I've also seen that many times Gen1 RPA would start with attended use-cases first because those licenses are much cheaper and easier to deploy than a full-blown orchestrator with unattended bot environments. But that’s really missing many of the larger benefits of RPA.

And remember, it’s just software at the end of the day. These are made up of constraints.

When we started Robocorp, we thought about licensing a lot. My intuition was that there needs to be a better way so we started from first principles and thought about the fundamental unit of value that RPA provides. 

An idle bot doesn’t really do anything for you, so we can’t use that as the basis. It’s just an option to run automation but that’s a step removed from the actual automation. 

A process is the actual automation that the bot will execute, but processes can be so wildly different that it’s really difficult to say that each of them are equally valuable.

A digital worker’s output is the work that they perform so we concluded that the working time of the bot is the best proxy for value generated by RPA. When you start thinking from this perspective a lot of things change. This requires a shift in thinking to consumption-based RPA. We are the first in the industry to build an RPA company, from the ground up, based on consumption rather than expensive and complicated licensing.

Robocorp’s platform consists of an open-source automation stack, developer tools, and a cloud-based Control Room. We wanted to give anyone the ability to build bots with open-source tools that are simple to use and universally available. It was a natural choice to adapt a model where Control Room is a paid offering where we can focus on solving the organization’s needs while RPA developers can freely operate without having to talk to sales or think about licenses.

Control Room is the most powerful and capable orchestration platform in the RPA industry, and it’s delivered as a highly secure and available hosted SaaS environment. It measures the runtime on a process level per minute and pricing from self-service to enterprise is built around that concept.

A process can have multiple steps and they can run on as many environments as you want, and even run concurrently. The only thing that matters is the execution time across all environments. Since there’s no limitation on runtime environments, we can easily do things like provision dynamic containers and VMs to run bots without having to think about running out of bot licenses.

Hosting and maintaining such a platform requires a dedicated team and having Control Room as a self-managed platform offers zero benefits for the user. More importantly, this decision also enabled us to fully embrace consumption pricing from the beginning and design it to be an integral part of the Robocorp product.

It’s important to realize that we have built everything around this model from the ground up. It’s nearly impossible to replicate a pure consumption based model when you’re starting from a legacy background and try to bolt it on. This is a classic example of an innovation stack, described in this great book; 

“[The] innovation stack … comprises a series of value-based decisions that level the playing field and disrupt markets. … A competitor could not copy just one part of the innovation stack and hope to win.”

Unlike traditional RPA licensing that’s rigid, consumption pricing is flexible. It allows you to build automations in an optimal way running on as many machines as you want. That’s the nature of cloud elasticity and in general why this paradigm is winning over the market.

Why bother thinking about utilization rates since it’s just compute time? Got a use-case that has unpredictable demand or periodic workloads? No problem. These are the typical arguments for consumption pricing but more importantly, it allows you to ramp consumption over time rather than having to decide on a big up-front commitment. Consumption pricing is derisking RPA projects.

From a vendor perspective, consumption pricing aligns us perfectly with customer interests. We only get paid when the customer is successful. We don’t have the luxury of selling a stack of licenses and waiting for 11 months to check back with the customer to renew.

Myth: 24/7 use-cases are expensive: The biggest misconception we hear is that a consumption model is expensive for 24/7 use-cases. That’s true if you take our self-service list price of a run minute and multiply it by 40,320 minutes. You get a big number, but luckily that’s just the self-service list price. Remember that bot runtime is only a proxy for value. We know that there are legitimate use-cases that require long processing times. One process can actually run much more than 40k minutes per month since we allow concurrent execution. It could easily do 400k minutes!

This is why we’ve introduced billing caps for high volume workloads. You can run the process as much as you want but the billing is capped on certain maximum consumption on a monthly basis. This gives the customer upside protection and predictability.

Another thing to consider is that quite few 24/7 bot use-cases actually come down to the bot working all the time. Often it’s more about checking if it has work to do. In these cases it’s better to use Control Room’s Work Data Management features to push new work to bots rather than using the bot to actually check for queued work.

Myth: Robocorp only runs in the cloud and I can’t do that with my bots: The need to run on-prem is valid for nearly all enterprise use-cases. Bots need to run inside local networks, sometimes even for mid-market users. Control Room is a cloud-native platform but the bot environments can live where ever needed. We can even provide VM provisioners and container clusters locally that can run dynamic workloads. The fact that we provide cloud elasticity in pricing doesn’t limit your use-cases only to the cloud.

Myth: Consumption pricing will have unpredictable billing each month: While departmental usage can start with a credit card purchase and ramp up over time, typically enterprises prefer to have a fixed annual contract in place. We do this by bundling runtime that can be consumed across any number of automations. This gives the flexibility of consumption pricing with the predictability of an annual contract.

When you are ramping up from zero to a new platform, you don’t really know what the consumption pattern is going to be like. So how much runtime are you actually going to need for the first year? Luckily that’s easily fixed by first year contract terms that allows for experimentation. We’ve seen that Robocorp bots typically run 2x - 8x faster than Gen1 so you might be surprised by how much less runtime is actually consumed.

Myth: License costs are the only thing that bring TCO up: License costs are a big consideration, especially in the enterprise. However, we see that infrastructure can cost much more  than the actual licenses. Luckily, that infrastructure is something we can partly eliminate. We have been able to reduce infrastructure costs by 50% in competitive Gen1 installations. This is achieved by not having to host the Control Room locally and being able to leverage container based runtime, plus using VM resources in a more efficient way. Robocorp can run multiple bots on a single Windows Server and shift workloads to containers.

A huge part of the reduced TCO also comes from reducing bot maintenance. This isn’t directly related to licensing but is still part of the total improvement. Architecting and developing RPA with Robocorp allows you to build it in a more robust and sustainable way. Bots don’t have to be fragile and brittle.

By combining these factors around licensing, infrastructure, and maintenance, we’ve recorded TCO reductions of 70% against well established Gen1 vendors.

Myth: Consumption is the best model for all RPA: I think there’s a category of RPA, that’s mostly driven by ISV and OEM use-cases that fall outside of the consumption pattern. In these instances the end user of the solution isn’t the primary customer and thus the cost model needs to be aligned with the pricing model of the ISV / OEM in question. However, this is a whole separate thread and anyone interested in exploring it further is welcome to contact me directly.

Consumption pricing is a fundamental shift in RPA. It unlocks flexibility in a way that has never been possible before, and it will require some getting used to if you’re used to legacy bot licensing schemes. It’s also a model that’s inherently less risky than considering bot licenses the same way as industrial physical assets that you buy in advance and then try to optimize and measure their utilization. If bots are working, they are producing value. And again, it’s just software – we should treat it as such.

There are not many vendors who are doing consumption pricing. I don’t actually know anyone except Robocorp that has properly implemented it. This is because it needs to be built into the product from ground up and cannot be added as an afterthought. It’s not just a business decision but a long string of product and technology decisions.

Over the long term, we will see a trend towards consumption pricing in all software, not just RPA. Companies like Snowflake are trailblazing the model and they are educating the markets on how it works. We chose the consumption model for Robocorp, not because it’s different, but instead because we think it’s the best model for capturing the value that RPA brings to its users.

Blog

Robocorp offers its clients the ability to build, scale, deploy, and maintain their robot workforce.

All posts by Antti Karjalainen

Multi Vendor Strategy is the New RPA Normal

How to change RPA pricing for good

products

solutions

developers

digital workers

resources

company