Most manual work is not one big job. It is dozens of small ones: pulling a report out of one system, checking it against another, rekeying the result, chasing the exception. RPA does that shuttling, following rules you define.
Which makes it quick to put in place and narrow in what it can handle. It 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 and what each is worth in hours a month. Some of what we find turns out to be fixable by removing a step rather than automating it.
A first automation is a small piece of work, priced before it starts. The scope that works is one task, one team, in production quickly, narrow enough that you can judge it on whether the hours actually came back rather than on a projection. A defined set of automations runs fixed-price as an Amplify project; where you expect a steady stream of processes to work through, it runs as an Apex partnership.
The cost people miss is maintenance. Automation that drives an interface breaks when a vendor changes it, so it needs an owner and a small budget to keep running. An automation nobody maintains fails silently, and the work quietly goes back to a person who now also does not trust it.
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.
We map how your business really runs — systems, costs, friction — and return a prioritised roadmap with a business case. $9,000 + GST, fixed.
RPA software does the clicking, copying and re-keying your team does by hand. CodeFish builds it in Adelaide for Australian operators where a person spends hours a day moving data between screens — and says plainly when a real integration or an AI agent is the better answer.
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.