For businesses under a few hundred staff who keep being sold enterprise automation

RPA for Australian SMEs, Without the Enterprise Vocabulary

Robotic process automation means software that operates other software the way a person does. It logs in, clicks through the screens, reads what is there and types what needs typing. There is no intelligence in it and no robot in the physical sense. It is a very patient temp who never gets bored, never gets sick, and never notices when something has changed.

That last part is the whole story. RPA works brilliantly on high volume, boring, rule bound work in systems that will not change, and it fails expensively everywhere else. Most of the material written about it is aimed at organisations with thousands of staff and a centre of excellence. This page is about whether it makes sense for a business with twenty or eighty people, and it says no more often than yes.

Book an RPA Reality Check (03) 9003 0111

Realistic ROI

5 hours a week

Is the rough floor we use for a single process

That is our own working rule rather than an industry standard. Below it, the build and the permanent upkeep usually cost more than the task

One process

Is the right size for a first project

High volume, stable, rule based and boring. Programmes that start with five processes at once tend to finish none of them

Exceptions

Are where the build effort actually goes

The standard path is quick to build. The awkward cases your staff handle without even noticing are what consume the time and the budget, which is why we scope them first

Every year

Upkeep is a recurring cost, like a licence

Screen driven automation is coupled to interfaces you do not control, so budget for maintenance permanently rather than as a one off

Four Things Nobody Selling You RPA Will Lead With

We build this work and we still think it is oversold to smaller businesses. Here is the honest version.

It is a very patient temp, not an intelligent one

A robot follows the exact steps it was given, in order, forever. It does not understand what it is doing, it cannot tell that an invoice looks wrong, and it will not pause to ask anyone. Everything people describe as intelligence in these projects comes from either the rules somebody wrote down or a separate document reading capability bolted alongside. Keeping that distinction clear in your own head is the fastest way to spot a proposal that is promising more than the technology does.

The economics are less flattering than the brochures

The saving is real hours multiplied by a real hourly cost, and for most SME processes that is a smaller number than people expect once they actually time the task rather than estimate it. Against that sits the build, the exceptions work that always turns out to be bigger than scoped, any licence cost, and permanent maintenance. A process that takes forty minutes a day is genuinely worth automating. A process that takes forty minutes a fortnight is not, no matter how irritating it is, and irritation is what usually drives the request.

The projects that fail tend to fail for the same four reasons

They pick the process that annoys the loudest person rather than the process with the most volume. They scope from a description of the work instead of watching it being done, so half the exceptions never make it into the build. They stop at a pilot that works on a laptop and never gets promoted to something monitored and owned. And they finish without a named owner or a maintenance budget, so the first vendor interface change kills it and nobody notices for a fortnight. None of those are technology problems. You will also see failure rates of thirty to fifty percent quoted for this technology: that figure comes from a consulting firm describing what it saw across its own engagements, not from a published study, so treat it as a caution rather than a measurement.

Half the time the right answer is not a robot at all

Before automating the keystrokes, it is worth asking whether the data needs to be in both systems, whether the vendor has an import route, whether a scheduled export would do, and whether the report anybody is producing is still read. Plenty of processes that look like automation candidates are actually candidates for deletion or for a supported integration that costs less and lasts longer. We would rather lose the build and keep the relationship than sell a robot that will be a liability in eighteen months.

The Six Questions That Decide Whether a Process Is Worth Automating

Answer these honestly before anybody writes a proposal. Four good answers is worth a conversation. Two is not.

Volume

Question 1

How many times does this actually run, and how long does it genuinely take? Not the estimate somebody gives in a meeting, but a stopwatch over a normal week, including the interruptions and the bits people forget to mention. Volume is the single strongest predictor of whether a robot pays for itself, and it is the number most often guessed rather than measured. If nobody is willing to measure it for a week, that in itself tells you how much the process really matters.

Rules, not judgement

Question 2

Can the whole process be written down as rules that a new starter could follow without asking anyone? If any step relies on knowing that this customer is always late, or that this supplier codes things oddly, or that anything over a certain amount needs a quiet word, that judgement has to become an explicit rule or an exception that stops for a human. Processes full of unwritten judgement are not unautomatable, but they are much more expensive than they look, because the automation project becomes a documentation project first.

Structured input

Question 3

Does the work start from something consistent, like a report, a form or a file, or does it start from an email that could say anything? Structured input is what makes a robot reliable. Where the input is unstructured, you are really looking at a document understanding problem with an automation problem behind it, which is two projects rather than one and should be priced and staged as such. Be suspicious of any proposal that treats messy inbound email as a solved starting point.

Stability

Question 4

How often does this process change, and how often does the software it runs on get updated? A process that is redesigned every quarter will spend its life in rework, and every change to the underlying screens is a maintenance event. This is why finance and administration back office work automates well and anything attached to marketing or a growing product line usually does not. Ask when the vendor last changed the interface and whether they warn customers beforehand.

Is there a better route?

Question 5

Before accepting screen level automation, check whether the system has a supported interface, a scheduled export, a documented import format, a database connection the vendor permits for reporting, or a report it can already email. Every one of those is cheaper to build and far cheaper to keep alive than a robot. A robot is the last resort in a list of options, not the first idea, and any honest assessment starts by trying to make itself unnecessary.

Ownership

Question 6

Who inside the business owns this after go live, who receives the alert when it fails, and who signs off the budget for the fix? If the answers are nobody, an unmonitored inbox and nobody, the project will fail regardless of how well it is built. This is the question that most reliably separates the automations still running in three years from the ones quietly switched off. It costs nothing to answer and it is the one most often skipped.

Where a Robot Earns Its Keep in a Smaller Business, and Where It Does Not

Task	Traditional	With a robot	Notes
Keying supplier invoices into the ledger	Someone types every line	Good candidate at real volume	Works when invoice formats are consistent and there is a human approval step before posting. Volume decides it.
Copying orders between two systems	Retyped once or twice a day	Check for an import file first	Frequently solvable with a scheduled export, which is cheaper to build and much cheaper to keep alive.
Pulling a daily report out of an old system	Someone logs in and exports it	Almost never needs a robot	Reading is a data problem. A scheduled report to a monitored mailbox usually does the whole job.
Reconciling two sets of records	Two screens and a spreadsheet	Automate the comparison, not the screens	Get both sides out as files and compare them. The fragile screen driving part is avoidable entirely.
Onboarding a new employee across five systems	A checklist and a slow afternoon	Reasonable if hiring volume is high	Low volume in most SMEs. A good checklist and a template often beats an automation you have to maintain.
Chasing overdue accounts	Manual list, manual emails	Automate the chase, not the lookup	Extract the debtor list from the system, then run the follow up outside it where nothing is fragile.
Monthly compliance or statutory lodgement	One long painful day each month	Usually not worth a robot	Twelve runs a year rarely justifies the build plus upkeep, and the rules change often enough to force rework.
Anything that needs a judgement call	An experienced person decides	Automate the preparation only	Let the robot assemble everything the decision needs and stop. Handing judgement to a rule engine is how bad outcomes get faster.

Where These Projects Come Unstuck in a Smaller Business

Scoped from a wish list rather than a stopwatch

The processes that get nominated are the ones that irritate people, which is not the same as the ones that consume hours. Irritation correlates with fiddliness, and fiddliness is exactly what makes automation expensive. Before scoping anything, have someone record for a fortnight how many times each candidate process runs and how long it genuinely takes including the interruptions. The list almost always reorders itself, and occasionally the whole business case evaporates, which is a cheap thing to discover early.

The exceptions arrive after the build

Staff handle exceptions so instinctively they do not mention them: the customer whose name is spelled two ways, the supplier who sends two invoices in one PDF, the order that has to wait for a manager. A build scoped from a written description will hit these in week one of production and either stop constantly or, worse, process them wrongly. The fix is to watch the work being done rather than have it described, and to sample a few hundred real historical records looking for the shapes nobody mentioned.

A pilot that never becomes production

A great many SME automations live permanently on somebody’s desktop machine, running when that machine is on, logged in as that person, with no monitoring and no documentation. It works, so nobody promotes it, and then the laptop gets replaced or the person leaves. Decide up front where it will run, under which account, who gets the alerts and where the documentation lives, and treat the pilot as a test of the design rather than as the delivery.

Licence and platform costs sized for someone else

Unattended automation is generally licensed per robot, and the published prices assume an organisation running a lot of them. As at August 2026 Microsoft’s Australian list price for Power Automate Process, its unattended bot licence, is AU$224.50 per bot per month billed yearly, or AU$321.80 for the hosted version, both excluding GST. That is roughly AU$2,700 a year per bot before anybody has built anything. UiPath publishes only a small entry tier and quotes everything above it, so you cannot compare without a sales conversation. Whatever is proposed, put the annual platform cost, the build cost and the maintenance cost in one place next to the measured hours saved. If the platform fee alone is a meaningful share of the saving, the answer is a simpler approach or no approach, not a longer payback period.

No named owner and no maintenance budget

Screen driven automation is coupled to software you do not control, so something will change and it will break. Without a named internal owner, a monitored alert destination and an agreed arrangement for fixes, the failure is discovered by accident, usually by a customer. This is the single most common reason an automation that worked fine at go live is switched off within a year, and it is entirely a management decision rather than a technical one.

Automating a process that should have been redesigned

A robot makes a process faster without making it better, and it locks in the current design because changing the process now means changing the automation too. If the reason two systems both need the data is historical, if the report exists because a manager who left used to want it, or if a step exists to work around something already fixed, remove the step instead. Automation applied to an unexamined process is the most expensive way to preserve a bad habit.

How Yes AI Approaches RPA for Smaller Australian Businesses

We measure before we scope

A short observation exercise across the candidate processes, with actual run counts and actual durations, before anybody writes a proposal. It costs a little time and it regularly changes which process gets automated, or whether any of them should be.

We look for a route that is not a robot

Supported interfaces, scheduled exports, documented import formats, permitted database connections and vendor reports all get checked first. If one of them does the job, we will tell you, even though it is a smaller piece of work for us than a robot would be.

We will tell you when the numbers do not work

If the measured saving is a few hours a month, or the process changes every quarter, or you are already planning to replace the system, the honest recommendation is not to build. You get that recommendation with the reasoning, not a proposal with an optimistic payback period.

Maintenance is part of the deal, not an afterthought

Anything screen driven is quoted with an ongoing support arrangement covering monitoring, response times and vendor interface changes. If that arrangement is not agreed we do not build it, because an unwatched robot fails quietly and leaves you with bad records rather than an obvious outage.

How an SME Automation Project Should Actually Run

Five steps, one process at a time. The first two exist to stop you spending money you do not need to spend.

Measure the candidates

A fortnight of real run counts and durations across the processes people have nominated, plus a note of every exception that comes up. The business case is built from that, not from estimates given in a meeting.

Try to avoid the robot

Written questions to the software vendors, a search of export, import, reporting and scheduling options, and a check for third party connectors. Anything supported beats screen automation on cost and lifespan, so it gets ruled out first.

Build one process, exceptions first

A single process, with the awkward cases designed in from the start rather than discovered later. Its own named login, validation before every write, verification after, a hard stop on anything unexpected, and full action logging.

Run it in shadow, then cut over

The automation runs alongside the manual process for an agreed period, its output compared rather than acted on, so discrepancies surface before anyone depends on it. Only then does the manual process stop, and the manual method stays documented.

Hand over with an owner and a support arrangement

A named internal owner, alerts to a monitored address, written documentation, a tested manual fallback, and an agreed maintenance arrangement with response times. Then, and only then, consider the second process.

FAQ

What is RPA in plain English?

It is software that uses other software the way a person does. It opens the application, logs in, clicks through the menus, reads what is on the screen and types into the fields, following a sequence somebody defined in advance. It does not understand the work and it makes no decisions beyond the rules it was given. The reason it exists is that a great deal of business software has no way for other systems to talk to it, so driving the screen is the only route left. That also explains its main weakness, which is that it depends entirely on the screen looking the way it looked yesterday.

How much manual work justifies a robot?

As a working rule of ours rather than an industry standard, a single process needs to consume at least several hours a week, measured rather than estimated, before the build plus permanent maintenance is worth it. That threshold moves down if the work is error prone and the errors are expensive, and it moves up if the underlying software changes often or if the process itself is redesigned regularly. The most useful thing you can do before asking for a quote is to have somebody time the task honestly for a fortnight, because measured numbers are usually lower than remembered ones and the business case has to survive the real figure.

Is RPA the same thing as AI?

No, and conflating them is where a lot of money gets wasted. RPA follows fixed rules and does not interpret anything. Language models and document understanding tools can read unstructured material and make judgements of a sort, which is a genuinely different capability with genuinely different risks. The two are often used together, for example a document reader extracting fields from an invoice and a robot entering them, but they should be scoped, priced and tested separately. Any proposal that blurs the line is worth reading twice, because the blurred part is usually where the optimism lives.

What actually goes wrong with these projects?

Four things, and none of them are technical. The wrong process is chosen, usually the annoying one rather than the high volume one. The exceptions are not discovered until production, because the build was scoped from a description rather than from watching the work. The pilot never becomes a properly hosted, monitored, documented production system and instead lives on somebody’s desktop. And no one is named as owner with a budget for upkeep, so the first change to the underlying software kills it quietly. Fix those four and the technology part is comparatively easy.

Can we do it ourselves with a low code tool?

Sometimes, and for simple, low risk, read only tasks it is a reasonable thing to try. The trap is that these tools make the easy part very easy, which encourages people to build something that touches real records without any of the defensive design that keeps it safe. If your homemade automation writes into a financial system, at minimum give it its own named login rather than a staff member’s, log every action it takes with a timestamp and the values involved, read the record back after saving to check it matches what was intended, and have it stop the whole run rather than continue when anything looks wrong. If you cannot do those four things, keep it to reading and reporting.

What does it cost to keep running?

More than people budget for, and it never goes to zero. Screen driven automation is coupled to an interface controlled by somebody else, so vendor updates, browser updates, new security prompts and process changes all generate work. UiPath, the largest vendor in the category, says in its own material that interface changes are the primary cause of robot failures and that a repair can take from a few hours to weeks (checked August 2026). Treat maintenance as a recurring annual cost in the same mental category as a software licence, agree who monitors it and what the response time is, and price the whole thing over three years rather than against the build cost alone. If the three year picture does not work, the one year picture was never real.

When should a smaller business simply not do this?

When the measured saving is under a few hours a week. When the process changes every quarter. When you are already planning to replace the underlying software within a year or two, because you will pay for the automation twice. When the software licence forbids automated access, which some do. And when nobody in the business is willing to own it after go live. In any of those situations the better spend is on simplifying the process, negotiating a proper interface with the vendor, or accepting that some manual work is cheaper than the machinery required to remove it.

Find Out Whether You Actually Need a Robot

Book a call. We will look at the processes you have in mind, ask what the volume really is, check whether a supported route exists, and give you a straight answer. Quite often that answer is that you do not need us to build anything.