It’s 4:39 pm. An MS Teams notification captures your attention from the top-right corner of your screen. It’s your MD—she sent you a 20-second voice note. And you have no idea what it’s about.

Instantly, anxiety invades your body. So with a quivering hand, you reach for the Rescue Remedy on your desk, screw off the cap, tilt your head back, swiftly release a few drops of the herbal scented liquid onto your tongue—actually, double the recommended amount—and bravely click the circular play button to start the voice note.

“Hey, this is just a quick one. I need you to do some research on robotic process automation (R-P-A). I’m chatting with an outsourcing company that does RPA because I want to see how they can improve our finance department’s processes. But I’m not sure if there’s anything specific I need to keep in mind from a commercial or legal perspective. So let me know what you think.”

That’s where you come in: your job is to advise your MD on the commercial and legal aspects she needs to look out for when dealing with an RPA vendor. And you don’t want just to scratch the surface; you want to understand the topic deeply (eager-beaver complex) so that you can explain it well and protect the business’s interests. But you don’t yet know much about it. So, you start your research by Googling “RPA”, “commercial”, and “legal” and find yourself here.

Dear gentle reader, in this post, I’ll guide you through the commercial and legal considerations you need to think about before, during, and after RPA projects. By the time you’ve read it, you’ll feel comfortable enough to have conversations about RPA and protect your interests. Hopefully, your anxiety will subdue too. And yes, the guidance will also help RPA vendors who design, develop, and deploy the technology.

What is RPA?

Simple automation

At its essence, RPA is the simplest form of automation software. It performs human tasks that are manual, repetitive, or rule-based. Nothing more; nothing less.

Examples of these tasks include:

  • opening emails,
  • logging into apps,
  • reading databases,
  • accessing files,
  • performing calculations, &
  • accessing forms.

So, based on these examples, you can deduce that RPA works best with high-volume and clearly defined tasks.

Not brains, brawn, or beauty

  • Not AI (brains). RPA is not trained on data sets like AI. RPA also doesn’t learn from data using machine learning or deep learning techniques. Instead, developers programme it to perform specific tasks. Tasks that are manual, repetitive, or rule-based.
  • Not a physical robot (brawn). The word ‘robotic’ in RPA misleads you to think that RPA is about physical robots. But it isn’t a physical robot that can pick up objects like the ones in the picture at the beginning of this post. Instead, it performs the virtual tasks of a specific business process like emailing invoices or capturing data from a spreadsheet.
  • Not a humanoid (beauty). RPA technology doesn’t have a physical or virtual humanoid appearance (looking like a human). It’s not like Sophia, the world’s first humanoid robot or like the virtual influencers of the metaverse.

RPA < intelligent automation < hyperautomation

By now you should realise that RPA is the simplest form of automation.

But, did you know RPA can integrate with other technologies to make automation intelligent? In fact, organisations can combine RPA, AI, machine learning, and other business process automation software to produce what the software industry calls “intelligent automation” or “intelligent process automation”.

Taken a step further, organisations can even scale intelligent automation to automate every possible business process. The industry calls this automation type “hyperautomation”.

Why is RPA so popular?

  • Cost savings. Businesses immediately save 25-80% on operational and human capital costs.
  • 24/7 continuous performance. The virtual RPA workers deliver 24/7 without a general need for breaks (except for scheduled maintenance).
  • Faster processing. Virtual RPA workers execute processes up to 70% faster than human workers.
  • Improved accuracy. RPA eliminates the risk of human error thus promoting predictability and a markedly improved customer experience.
  • Reduced operational risk. RPA reduces errors by 99%. It also promotes compliance by keeping log files of its actions that compliance teams can review at any time.
  • Accountable, scalable, & flexible technology. RPA empowers businesses to predict outputs better, scale automation, and apply it to different processes.
  • Increased personnel productivity. With RPA focused on rote tasks, personnel shift their attention from those tasks to creative and critical thinking, thus, increasing productivity.

In sum, because of these measurable benefits, many businesses have successfully deployed RPA across several different functions such as accounting, customer service, finance, human resources, procurement, and supply chain management.

The lifecycle of an RPA project

The lifecycle captures the phases of when and how a vendor delivers and executes RPA automation to you. Here’s a pretty diagram capturing the lifecycle.

The lifecycle of an RPA project

Gratitude break

You’ve been doing excellently. You’ve just learnt what RPA is, why it’s popular, and the phases of the RPA lifecycle.

Now, stand up, stretch a bit, release your tension, take a deep breath, and get ready to tackle the commercial and legal considerations.

Three contracting models for implementing RPA technology

  1. Managed service model. You (customer) would enter into a services contract with an RPA vendor. Under the contract, the vendor would use RPA technology in delivering the services to you. In essence, you’d be buying services or outcomes from the vendor.
  2. In-house or DIY model. You’d enter into a software licence contract with the vendor. Under the contract, you’d acquire software licences from the RPA vendor to use internally for your business processes. Usually, you’d first pilot the technology as a proof of concept. Then, you’d adapt your approach based on the proof of concept phase results.
  3. Blended model. The vendor would initially use RPA technology in delivering services to you. But the end goal would be to move the RPA in-house. So, you’d start with a services contract and then acquire software licences.

Before procuring RPA technology: knowing what you want

  1. Create a high-level business case. The business case summarises why you want to use RPA and what processes you want to automate. It’ll also include how much you’re willing to spend on the RPA project.
  2. Decide what contracting model would suit your business case best. But be flexible enough to hear reasons from a vendor why you should adopt a different model from what you want.
  3. Draft a brief transformation plan. Automating your business processes will probably disrupt how you currently do business. So, have a rough idea of how you’ll deal with disruptions, e.g. phasing in automation over some time.
  4. Identify the data RPA will process. Think about the data that forms part of the RPA processes, e.g. personal data or confidential data.
  5. Draft a business continuity plan. Have a backup plan for the event where RPA fails. For example, have a list of people who could step up and perform the manual tasks.
  6. Consider the impact of RPA on your human capital. The bots carrying out RPA tasks are virtual, not human. But their deployment impacts humans like you and me. So, suppose you’re considering using RPA in your business. In that case, I urge you to engage with human resources and labour law counsel early. And, if needed, with trade unions and employee representatives. Plus, ask yourself whether some personnel become redundant or you need to reprofile their job descriptions.
  7. Check applicable sector regulations. Are you using RPA in a regulated sector? If so, get an opinion on how that sector’s regulations impact your ability to roll out RPA technology.

Your procurement strategy: let’s date

You should consider the following points in procuring an RPA vendor:

  1. Check if your vendor complies with applicable sector regulations. This step is crucial, and you should probably disqualify a vendor if they don’t comply with applicable regulations. Otherwise, you assume the risk of their non-compliance.
  2. Conduct a compatibility assessment. The assessment would compare your business case to the vendor’s offerings to see if you’re a match. If you’re a match, swipe right; if not, swipe left.
  3. Determine if the RPA vendor’s stable. Secure enough information to assess the financial and operational stability of the vendor.
  4. Check if the vendor’s solution interfaces with legacy systems. This step is vital where the business processes you want to automate link to your other software systems.
  5. Review your other software licence agreements. Suppose the RPA solution would interface with other software you use (but don’t own). In that event, I recommend you review your licence agreements with your ordinary software vendors. Your review would check if you can use RPA with their software, need more user licenses, and how using RPA would affect your pricing model with those vendors.
  6. Ownership of the intellectual property in the software. In the case of the managed services model, you’d want to know that the vendor has the rights to offer the services to you. In the in-house or DIY model, you’d either want to know that the vendor owns the RPA licences or has authority from a third party to sell it to you.

RPA contracts: the marriage of true minds

So, you’ve found a vendor you like and want to engage them. But, RPA is exciting, so it can often lead to rushed deals that expose you to unnecessary commercial, data, security and contractual risks.

In my experience, the best approach to this problem is to strike a balance between minimising risk and maximising productivity. The more you know about RPA contracts, the closer you’ll be to striking that balance effectively and understanding the underlying trade-offs between risk and productivity.

The main question: Know what you’re buying

Are you buying a service (managed service model) or software (in-house or DIY model)? Once you answer this question, it will be easier to understand how you should approach RPA contracts.

9 themes in RPA contracts: exploring the kinks

I’ve divided the key contractual clauses into 9 easy-to-understand themes. They’ll give you a solid foundation for understanding the kinks in RPA contracts.

Data

What data will the virtual bots have access to?

Confidential data? Personal data? Other proprietary data?

The type of data the bots process will influence whether you need to take additional legal or commercial steps in the RPA contract. For example, if the bots process personal data, you’ll need to sign a separate data processing agreement with the vendor. You’ll also need to evaluate whether the bots are making automated decisions about data subjects (persons to whom personal data relates) and the consequences if this is the case.

Mapping processes

Who’s responsible for mapping the processes the bots will automate?

You need to clarify if it’s you, the vendor, or a third party. You also need to clarify if it’s included in the costs for the services or software.

Performance

Service Level Agreement (SLA)

An SLA is a document that defines the level of service you expect from a vendor, lays out the metrics by which you measure the service, and states the remedies or penalties if the vendor doesn’t meet the SLA. In RPA contracts,  the SLA for virtual bots must describe:

  • expected uptime,
  • speed of processing,
  • accuracy of processing, and
  • time taken to fix broken bots.

It also needs to set out what happens if the bots can’t meet the SLA, e.g. service credits.

Rollout schedule, success criteria, & acceptance testing

I recommend you have a rollout schedule to know the timelines you’re working with for your RPA project. It would also be best to have robust success criteria to know exactly what outcomes you expect the vendor to deliver. Plus, the clause dealing with acceptance testing should give you testing rights such as the right to review the configuration or programming of the bots.

Implementation, training, support & maintenance

Implementation & training

Usually, the vendor’s responsible for implementation and training. But the RPA contract needs to set the parameters for these services clearly. For example, how many hours do you get? How do the parties decide when implementation and training are complete?

Support & maintenance

You and the vendor need to set out support & maintenance terms clearly, too. However, if there are many bots and they’re complex, I recommend you execute a separate statement of work (SOW) with the vendor. An SOW is a binding document within the contract that describes the work requirements for the RPA project with its performance and design expectations.

Plus, remember that the amount of support and maintenance you require will impact the pricing.

Intellectual property

IP in data and process

In the in-house or DIY model, you’ll work with the vendor to create custom virtual bots using the vendor’s software. And the RPA lifecycle involves both you and the vendor providing valuable business know-how, processes, and other proprietary information to each other. Let’s call this information “data inputs”.

Issues might arise between you and the vendor regarding the IP rights associated with those data inputs and the data the bots produce. For example, will the vendor be able to exploit that data or the learnings from the bots for its other customers (including your competitors)? Further, can the vendor otherwise capitalise on the RPA, e.g., creating a new product or becoming your competitor?

IP restrictions in existing licences & data

Before implementing RPA that interfaces with your existing software, you should understand the rights and restrictions (both contractual and legal) that apply to you regarding your current software licences and the data with which the RPA interacts. For example, you may only be able to use the licence or data for a specific purpose. Or the scope of your licence may not contemplate RPA. So, I recommend you review your software agreements with your other vendors.

Payment models

I’ve come across many different payment models in RPA contracts.

I’ve grouped them into two models. The two main models are paying per outcome or per unit (virtual bot).

  • Paying for an outcome is common when you’re buying a service.
  • Paying per unit is usual when you’re buying software.

Another consideration is with whom the costs lie for implementation, training, support, and maintenance. It’s not uncommon for the vendor to absorb the implementation and training costs when you buy a service, but you often need to pay for them when you buy the software. In the case of software, these costs will probably be higher as the vendor would need to train your team and initially offer their personnel to perform some of the functions until training is complete.

Change management

Change in process

The RPA contract needs to indicate what happens if you decide to change processes. That is, if you had a process, mapped that process, and the bot performs that process. But later, you learn something new and want to update the process. If you want to change the process the bot performs, it would help if you clarify how the vendor will charge you for the change.

Risk management

Size matters

Risk management usually depends on the size of the vendor. Smaller vendors are less likely to assume contractual risk when compared with larger vendors. A workaround is to request a performance or bank guarantee from smaller vendors. Or to ask them to have insurance in place. Another option is to hold the source code in escrow.

Exit management

RPA disrupts traditional outsourcing deals

Outsourcing deals are no longer long-term (over 10 or 5 years). Instead, they’re usually shorter periods to consider technological advances that may require a new solution.

Naturally, customers usually prefer easy in / easy out arrangements. At the same time, vendors want to lock in customers. So, you’ll probably haggle over termination for convenience clauses and cancellation penalties.

Transition arrangements

If you’re worried about vendor lock-in, you should consider robust transition clauses that contemplate either moving in-house or getting another vendor.

How we can support you along your RPA journey

You’ve reached the finish line! At this point, I’ve empowered you with the knowledge to have conversations about RPA and protect your interests.

Yet, there’s so much more to discover about RPA and its nuances in commercial and legal transactions. That’s where we come in: we offer the following specialised services to support you along your RPA journey.

RPA handbook

Navigate your RPA projects confidently

Ask us to provide you with our exclusive RPA handbook.

RPA contracts

Manage your RPA relationships

Ask us to draft, review, negotiate or interpret your RPA contracts.

RPA workshop

Get practical training on RPA transactions

Ask us to present an intensive RPA training workshop to your team.

Get in touch

Get in touch with your personal RPA lawyers by filling in our enquiry form:

  • This field is for validation purposes and should be left unchanged.