Making Sense of Nonsensical RPA Software Pricing

Confusion around RPA deployments is rife, with growing questions surrounding whether RPA can deliver on promised ROI and outcomes. Most RPA initiatives continue to be small and piecemeal; scaled RPA deployments are rare because the industry is still relatively nascent, and the ultimate desired outcomes still being crafted.

When we interviewed 359 power users of RPA for our recent RPA Top 10 study, one of the critical issues for RPA scalability was software pricing or RPA licensing costs (see Exhibit 1). What are the challenges with RPA pricing? Is there a better and more practical pricing model? And what can the industry stakeholders do to help?

Exhibit 1. RPA customer experience on scalability and flexibility

Sample: 359 power users of RPA

Source: HFS Research, 2018

The mystical world of RPA software pricing

There are four significant challenges with RPA software pricing:

1. A bot is not a standard unit of measure. Most leading RPA products are priced as a function of “number of bots.” However, a “bot” as a unit of measure is an abstract concept and hard to understand. It does not easily equate to common units of input-pricing measures (such as FTEs, lines of code, or T&E) or output-pricing measures (volume of transactions processed). The meaning of “bot” across RPA products is also not standard; a UiPath bot is not the same as a Blue Prism bot, which is different from an Automation Anywhere bot!
2. It’s difficult to compare across vendors. Most RPA product licensing is some form of input-based pricing (some function of “number of bots”), but different products have vastly different pricing configurations (see Exhibit 2), making it difficult for clients to do any form of apple-to-apple comparison. Some products like Redwood and Thoughtonomy are experimenting with output-pricing models, but standards are yet to emerge.

Exhibit 2. RPA pricing models of leading RPA products

Source: HFS Research, 2018

2. Pricing models are inflexible. RPA products make it harder for clients by taking a “my way or highway” approach. There is little to no flexibility in pricing models (note that pricing flexibility does not equate to discounts). Pricing details are also behind firewalls, making the information relatively inaccessible. We’ve heard about clients having to deal with third-party implementors in some instances to get details when they wanted to deal with a product company directly.

3. Software cost is only part of the total cost of ownership. In our view, RPA licensing costs represent just 25% to 30% of total costs for implementing RPA (see Exhibit 3). There are significant implementation, training, governance, and management costs that vary dramatically by the current maturity and nature of the targeted process being automated. And we’ve not even talked about the intangible internal client costs such as change management. Without a total cost of ownership (TCO) model, ROI calculations just based on licensing costs are misleading.

Exhibit 3. Worldwide enterprise robotic software and services (RPA and RDA), 2016-2021

Source: HFS Research, 2018

There is no RPA pricing “nirvana”

RPA software pricing is a complex topic and, unfortunately, there are no easy answers here. There are three types of pricing mechanics (input, output, and outcome) for any service-oriented product but none of them represents the “nirvana” state for RPA pricing.

• Pricing based on process inputs such as FTEs, lines of code, and time and material. The entire business process management (BPM) market uses this FTE model, where clients can easily compare the cost of a payables clerk in the US versus one in India and make a relatively simple and accurate business case. However as described above, a “bot” as a unit of measure of input pricing is an abstract concept.
• Pricing based on process outputs such as the volume of transactions processed. Often used in mature and commoditized services such as a price-per-employee pay-slip in payroll processing. But, given the generalized and broad scope of RPA implementation, defining and measuring business transactions is difficult.
• Pricing based on business outcome or impact. The most common example is gain-sharing in some form based on a mutually agreed upon desired result from the services. For instance, third-party sourcing and procurement providers are often paid based on the degree of spending deflation that they have achieved for the procurement categories that they manage. This is pretty much a bad idea for RPA product pricing as it is difficult to isolate the RPA product’s contribution in creating the impact. It is also hard to quantify the impact of every outcome of RPA from every implementation. Moreover, a client’s lack of readiness and maturity may restrict an RPA’s ability to achieve results.

How about pricing RPA by bot time?

The answer to this RPA pricing puzzle potentially lies in more granularity and flexibility. Ultimately, RPA is a piece of software that processes logic-driven tasks (such as logging in into an application, entering some data, copying and pasting data, or clicking some buttons). It does it much faster and accurately than a human being can (or wants to!). So, the most fundamental and granular unit for RPA is bot time (execution time taken by software) and a potential solution the current RPA pricing mess could be to price RPA regarding the full-time-equivalents (FTEs) of machine time.

Basing pricing on bot time will be akin to the time and motion (T&M) studies that helped understand how long it takes to complete a process, but you might be observing a software product, not a human, click some buttons. For more mature use cases where RPA has been deployed thousands of times, a pricing mechanism more tightly linked to the volume of transactions could be used, but FTE equivalents of machine time could become the generic measuring unit.

Bottom line: RPA software pricing is not a zero-sum game. The industry needs to collaborate.

RPA clients need to realize the pricing challenges and make their investment decisions accordingly. Remember if it seems too good to be true, you need to look under the covers. The RPA software providers also must realize that for RPA to get through to mass adoption; pricing is one of the facets that need to be resolved. Leading RPA providers, early adopters, and implementation partners need to come together to discuss this issue as an industry versus letting the competitive animosity and one-upmanship get the better of them—the RPA software pricing issue is not a zero-sum game.