How to change RPA pricing for good

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.

You need a license for:

• Every runtime environment (this is the bot license)
• Unattended bot users
• The orchestrator
• Developer tools for everyone building RPA bots
• Add-ons like intelligent document processing or process discovery

In addition, you'll need to think about:

• Infrastructure for bot runners
• The orchestrator database
• 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.

Starting from a blank canvas

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.

Implementing consumption pricing

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.”

Benefits of consumption pricing

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.

Common consumption based RPA myths

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.

Conclusion

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.