The test before anything else
Four questions. A task needs a yes to all four.
Is it high volume? The same thing, many times. Daily or weekly, not twice a month.
Is it rule-based? Clear steps, no judgement.
Is the input structured? Consistent format, same place each time.
Is the source stable? The site or system does not change constantly.
One “no” usually means do not automate it — or automate part of it and leave the rest.
1. Fetching published data
What it is. A dataset, price list or report published somewhere, needed in your system on a regular basis.
Why it fits. Repetitive, entirely mechanical, and skipped on busy days — which means working from stale data without realising.
How to build it well: if there is a direct URL, request it rather than navigating a browser. That one choice removes most of the fragility.
What it delivers: the file, validated, handed to something that processes it. Not the whole pipeline.
2. Extracting from a portal with no export
What it is. Logging into a supplier, bank or government portal, navigating to a report, downloading it.
Why it fits. Genuinely no alternative — you use the portal, you do not own it.
Why it pays. Often daily or weekly, and it takes real time.
Watch for: portals redesign without notice. Budget for maintenance, keep the automation’s job to retrieval only, and make failure visible.
3. Moving data between disconnected systems
What it is. Records from one system entered into another.
Why it fits. High volume and mechanical.
Check first: does either system have an API or an import function? If yes, use that instead. This is the most common case where RPA gets built unnecessarily, because it does not require anybody’s permission.
FIGURE 1: THE THREE THAT PAY MOST OFTEN
Fetching published data
- Repetitive and often skipped. Use a direct URL where one exists.
Portal extraction
- No alternative when you do not own the system.
Moving data between systems
- But check for an API first — this is where RPA gets overused.
4. Repetitive form filling
What it is. Entering the same kind of information into the same form, many times.
Why it pays. Time saved, and the error rate drops — a robot does not mistype on the four hundredth entry.
Where it breaks: the form changes. Keep the interaction minimal and the selectors stable.
5. Reconciling two lists
What it is. Compare a list from one system against another and flag differences.
Why it fits. Rule-based comparison, structured data.
Why it pays. Tedious, error-prone by hand, and often skipped entirely — which means problems go unnoticed until they are expensive.
The robot flags. A person investigates. Do not automate the investigation.
6. Regular report assembly
What it is. Pull figures from several places, put them into a template, distribute.
Why it pays. Somebody currently loses a morning to it.
Agree the definitions first. What counts as revenue, what period, what is excluded. If those are unclear, automating produces a report people argue about faster.
7. Preparing work for a person
The underrated one.
What it is. The automation gathers everything, assembles it, and stops. A person reviews and decides.
Why it fits. The gathering is mechanical; the decision is not.
Why it pays. Most of the time in these tasks is collecting, not deciding. Automating the collection captures most of the saving with none of the risk.
This is often the right answer when full automation seems to need judgement. Split the task rather than abandoning it.
FIGURE 2: PARTIAL AUTOMATION IS OFTEN BETTER
The robot gathers
- Opens the systems, collects, assembles.
The robot checks the obvious
- Flags what does not match a rule.
A person decides
- Judgement stays where it belongs.
Faster to build, more reliable
- And nothing irreversible happens unreviewed.
What does not pay
Low-volume tasks. Twice a month is not worth building and maintaining.
Anything needing judgement. Encoding it as rules works until reality produces a case the rules do not cover.
Documents in varying layouts. That is a document AI problem, not screen automation.
Frequently changing interfaces. You will spend more repairing than you save.
Processes nobody has documented. Automate the confusion and it gets faster, not better.
The one that catches everyone
Automating a bad process.
If the process itself is wrong — unnecessary steps, duplicated work, a report nobody reads — automating it means doing the wrong thing faster.
Ask before building: should this task exist at all?
Sometimes three of the eight steps are pointless, and removing them saves more than automating all eight would have.
FIGURE 3: BEFORE YOU AUTOMATE
Ask first
- Should this task exist at all?
- Does an API or export already do it?
- Which steps genuinely need judgement?
- Who will maintain it?
Common mistakes
- Automating a process nobody questioned
- Building RPA where an API existed
- Encoding judgement as rules
- Nobody owns it after go-live
Calculating whether it is worth it
The saving: minutes per run × runs per month × the cost of that time.
The cost: build time, plus licence, plus maintenance for as long as it runs.
That last part gets left out, and it is not small.
A rough guide: if the annual saving is not several times the annual cost, it is marginal. Marginal automations get abandoned when their author leaves.
A sensible first project
Pick the most repetitive task, not the most complicated one.
The temptation is to automate the biggest headache. Start with the simplest high-volume task — you learn the tooling, prove the value, and build credibility for the harder ones.
Then:
- Check for an API, an export, or a direct URL
- Time the manual version
- Document it including exceptions
- Build attended
- Run alongside manual for two weeks
- Measure against the baseline
- Assign an owner
The short version
RPA pays on high-volume, rule-based tasks with structured input.
Check for an API or a direct URL first. Both beat screen automation, and both are frequently available when nobody looked.
Consider partial automation — the robot gathers, a person decides. Faster to build and more reliable than encoding judgement.
And ask whether the task should exist before making it faster.
Somebody repeating the same task every week?
Get in touch. We will check whether an API or an export already solves it — and if not, scope it with maintenance included in the number.
