RPA pays off when a task runs hundreds of times a week, follows rules someone can write down, and moves data between systems that have no API to connect them. Most manual work is dozens of small jobs like that: pulling a report out of one system, checking it against another, rekeying the result.
RPA follows the rules exactly, including the bad ones, so the first question is never how to automate the process. It is whether the process is the one you would design today.
The shape of the work matters more than the industry. These are the traits that make a task worth automating.
The same task hundreds of times a week, done the same way each time. Volume is what turns a small time saving into a real one, and consistency is what makes the rules writable.
If a person can write down exactly what they do and why, it can be automated. If the answer is that they just know, the first job is writing it down, and that often fixes half the problem on its own.
Pulling from one screen and typing into another, because the two do not talk. This is the classic case, and it is worth asking whether an integration would be the more durable fix.
A spreadsheet, a form, a consistent report. Where the input is a photographed docket or a free-text email, you need document processing or judgement in the loop, not rules.
Start where a mistake is annoying rather than expensive. The first automation exists to prove the approach and build confidence, not to take on the highest-stakes process you have.
RPA follows your process exactly, including the parts that grew by accident. Automating a broken process makes it fail faster. The process gets fixed first, or the automation locks it in.
An integration, where one is available. RPA driving software through its interface is working around a missing connection, and it breaks when a screen changes. Where the systems expose an API, connect them properly. It costs more up front and far less over five years. RPA is the right answer when there is no API, when the vendor will not give you one, or when the process spans systems nobody is going to connect for a task this small, and there is nothing second-rate about taking that pragmatic path knowingly.
A person stays in the loop wherever judgement is involved. The pattern that works is rules doing the predictable majority and a queue routing the exceptions to someone who can decide, and that queue is also the best map you will get of where the process actually needs work. Where the input is unstructured, like a scanned docket or an emailed instruction, rules alone will not carry it. That is where document processing and AI handle the reading, and the rules take over once the data is clean.
It starts with a Rapid Insight Workshop at a fixed $9,000 + GST. We watch the work as it is done, count the hours going into the repetitive parts, and come back with the two or three tasks worth automating first. Some of what we find is fixed by removing a step rather than automating it.
The cost people miss is maintenance, because automation that drives an interface breaks when a vendor changes it. How a build is priced and run is on our intelligent automation page.
We sit with the people doing the task and record what they actually do, not what the procedure says. A good share of the steps turn out to exist because of a system limitation nobody has revisited.
Steps get removed, not just sped up. This is the stage that stops you paying to make a bad process faster, and it is the one most vendors skip because it shrinks the build.
One task live, with an exception queue and a record of what it did. The exceptions tell you where the rules are thin, and that is what shapes the second automation.
RPA follows rules you write; it does the same thing every time and cannot handle a case you did not anticipate. AI handles judgement, reading something unstructured, deciding what it means. Plenty of real processes need both, with rules doing the predictable majority and judgement reserved for the exceptions.
It can, and that is the honest weakness of automation that drives software through its interface rather than its data. Where a proper integration is available it is more durable, and worth the extra effort up front. Where it is not, automation is still often the pragmatic answer.
Something high volume, well understood, and low consequence if it stops. The goal of the first automation is to prove the approach and build confidence, not to take on the hardest process you have.
In our experience it moves them. The work RPA takes on is the part nobody wanted (the copying and the chasing), and what is left is the judgement, the exceptions and the customer. If a business case depends entirely on headcount reduction, it is worth stress-testing before you build.
Hours a week times the people doing it, plus the cost of the errors. The hours are easy to count once you watch the work rather than ask about it. People routinely under-report the small repetitive tasks because each one feels trivial. The errors are the harder number and usually the larger one.
The automation has to change with it, which is why it needs a named owner and a small ongoing budget. The failure mode to avoid is an automation that keeps running after the process moved on, quietly producing work that is now wrong, which is worse than one that stops.
The figure is set in a $9,000 + GST Rapid Insight Workshop. Defined work is then quoted fixed price as Ignite or Amplify (typically from $100K), and a steady stream of processes to automate runs as an Apex partnership (from $15K a month).
Typically 2 to 12 months as an Amplify build, with the first process live well before the end. The workshop comes first and delivers a roadmap about three weeks later. Steady, rule-based tasks go fastest; processes nobody has written down take longer.
Buy if the tasks are simple, screen-based and stable, and you have someone to maintain the bots. RPA tools usually charge licence fees every year. Custom automation suits work that crosses systems through APIs or needs judgement, and it breaks less when screens change. A custom build has no per-user licence and you own the code.
A Rapid Insight Workshop is two sessions with your key people that map how work really gets done and where time and money are lost. It costs a fixed $9,000 + GST, and about three weeks later you get a prioritised roadmap, a business case and a product specification you keep either way.
CodeFish builds RPA software in Adelaide that does the clicking, copying and re-keying your staff do between screens. We will also tell you plainly when a proper integration or an AI agent is the better answer.