RPA consultation: what it should cover and what you should leave with

The short version

• An RPA consultation should end with a written, ranked list of processes and a running cost, not a tool demo.
• RPA suits stable, rule-based, high-volume work on systems with no usable API.
• Bots copy clicks, so a changed screen can stop one, and maintenance decides whether RPA pays back.
• If a supported API exists, use it. A bot on a screen is a workaround for a missing interface.
• RPA follows fixed steps, while an AI agent chooses its steps and needs evaluation and review.

What happens in an RPA consultation?

A consultant learns how a process really runs, then judges whether software robots should do it. That means sitting with the person who does the work, not only the manager who describes it. The written procedure and the real one rarely match, and a bot has to follow the real one.

Four things get measured or estimated: how often the process runs, how long each run takes a person, how often a case leaves the normal path, and how stable the screens are. With those four you can separate a good candidate from a bad one before buying anything.

Exceptions matter most. Almost every process has a clean path that takes minutes to demonstrate and a long tail of odd cases that people solve from memory. A bot handles the clean path and stops at the rest, so somebody still owns that queue. A consultation that maps only the clean path overstates the saving.

What should you have at the end of an RPA consultation?

You should have a written document that a second supplier could price from. It names the processes worth automating, the ones that are not, and what each would cost to run. If the only output is a tool demo or a proposal for the next phase, you have sat through a sales call.

• •A ranked list of candidate processes, with the reasoning behind each rank.
• •Volumes, handling times and exception rates, each marked as measured or estimated.
• •A running cost estimate covering licences, hosting, monitoring and maintenance, not only the build.
• •A named owner for each bot and for the exceptions it hands back.
• •The processes rejected, and why. This is often the most useful page.
• •A stated view on the alternatives: an API integration, a process change, an AI step, or leaving it alone.

Which processes are good candidates for RPA?

Good RPA candidates are stable, rule-based, high-volume processes with structured input, running on systems that offer no usable API. Typical examples are copying records between two systems that do not connect, keying the same details into several portals, and pulling a routine report out of an old application.

A process should pass all of those tests, not most of them. A bot copies clicks and keystrokes. It does not understand the screen, so a change to the screen or the input changes the outcome. That is why stability comes before time saved.

How do you score a process for RPA?

When is RPA the wrong answer?

RPA is the wrong answer when a supported API exists, when the process is about to change, or when the volume is too low to cover upkeep. A bot on a screen is a workaround for a missing interface. If the interface exists, use it, because an API is a published contract and a screen is not.

It is also wrong when the step should not exist. Automating a task that only happens because two teams keep separate spreadsheets preserves the problem and adds a maintenance bill. Ask what would break if the step stopped. Sometimes the answer is nothing.

Planned system changes catch people out. A bot built on an application that is being replaced this year is a bot you will build twice. A good consultation checks the roadmap before it scores the process.

Low volume is a fine reason to stop. A task done a few times a month rarely repays a bot, however annoying it is.

What does RPA cost to run?

RPA costs licences, hosting, monitoring and the ongoing time of someone who fixes bots when they break. Licences are the visible line. Maintenance is the line that decides the result, because a change to an underlying screen can stop a bot until someone repairs it.

Licence models also differ in ways a headline price hides. Microsoft sells Power Automate unattended capacity per bot, and each bot runs one unattended desktop flow at a time, so concurrent runs need more bots. UiPath's comparison table shows a limit of 2 robots in the Basic column, with hosting in Europe only, and extra users and robots may cost more.

We are not quoting prices here because both pages hedge them. Microsoft warns that its prices are for marketing purposes and are confirmed at checkout. UiPath's page says 'An updated plan offering is coming soon.' Ask for a current quote at the concurrency you need.

How long does RPA take to pay back?

There is no reliable general figure, so work it out from your own volumes. Published payback numbers describe the people surveyed, not your process, and the ones available are weak evidence for a buying decision.

Deloitte's 2021-22 global survey of 479 executives from 35 countries says payback 'is still under 18 months'. Read that with care. The sentence names no group, the page gives another figure it does not reconcile, and company size is not stated, so it is not small-business data.

Adoption surveys do not fill the gap. Eurostat's 2025 enterprise survey leaves out firms with fewer than 10 staff. A US Census Bureau analysis of data from December 2025 to May 2026 reports firms with at least 20 employees as the biggest AI users. Both show who uses AI. Neither shows whether a bot pays back.

The sum is simple. Take the hours saved each month, multiply by what those hours cost you, and subtract the monthly running cost. Divide the build cost by what is left, and that is your payback in months. Count only hours that actually come free. A few minutes saved across a team's day rarely lets anyone drop a task.

How is RPA different from an AI agent?

RPA follows fixed steps and an AI agent chooses its own. RPA is predictable and stops when something changes. An agent copes with variation, but it can be wrong in ways that look right, so it needs evaluation, limits on what it can do and human review.

Many processes need both, in sequence. A model reads the messy email or scanned form, rules check what it extracted, and fixed automation does the keying. Each part does what it is good at, and the checking step sits between them.

Do not use an agent where a fixed rule will do, because you are paying for uncertainty you do not need. Do not use a bot on work that needs reading and judgement, because it will stop at every variation.

Do you need an RPA consultation at all?

Not always. If you have one small task, a tool you already pay for and someone willing to own the result, try it yourself first. A short, cheap experiment will teach you more about your exceptions than a meeting will.

A consultation earns its cost when several processes compete for attention, when the work touches regulated or customer data, or when a failed bot would cause real harm. In those cases the value is a defensible order of work and a clear view of what could go wrong.

How do you choose an RPA consultant?

Choose the one who asks most about your exceptions and is willing to reject a process you were sure about. Product knowledge is easy to find. Honest judgement about your process is harder to buy. These questions separate the two.

• •Which of our processes would you tell us not to automate?
• •Do you earn anything from the licences you recommend?
• •What does this cost to run in the second year?
• •Who fixes the bot when a screen changes overnight?
• •Can we see a sample of the document you deliver?