RPA Software

Automating a bad process makes the bad outcome arrive faster. If a workflow exists because two systems were never joined up properly, or because nobody trusts the data, the fix is the integration or the data — not a robot clicking through the mess at speed. Fix the process first, automate second.

RPA is brittle by design: it depends on the screen, the field and the sequence staying where they are. If the underlying system, supplier format or rule set changes often, maintenance costs more than the manual work it replaced. A proper API integration or a model-based approach survives change; a screen-scraping robot does not. When a process does change, the automation has to change with it — which is why every one needs a named owner. An automation that keeps running after the process moved on, quietly producing wrong work, is worse than one that stops.

A task done twice a month for ten minutes is not worth automating, however annoying it is. The rough threshold: an hour a day of a person's time, or a task where an error has real cost. Below that, the build and maintenance outrun the saving.

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 small repetitive tasks because each one feels trivial. The errors are the harder number and usually the larger one.

The robot stops at the step that no longer matches and raises an exception, rather than guessing and entering bad data. Every automation we build checks that each screen, field and file looks the way it expects before it acts, so a vendor update to your ERP or a new portal login page halts the run and tells a named person why. The work goes back to the manual process for that day. A small change, like a moved field, is usually fixed in hours. A rebuilt screen takes longer, which is why the support budget is agreed before go-live, not after the first break.

Nobody needs to sit and watch it, because it reports on itself. Each run writes a log of what it processed, what it skipped and why, and anything it could not finish lands in an exceptions queue with the reason attached. Your team sees that queue first thing in the morning, the same way they would check an inbox. If a run fails outright, an alert goes to the owner you named at the start, by email or Teams. You decide who that owner is: usually the person who did the task by hand, because they know what correct looks like.

Something high volume, well understood and low consequence if it stops. The first automation exists to prove the approach and build confidence, not to take on the hardest process you have.

If both systems have an API, connect them properly instead of putting a robot in front of the screens. An API integration is faster, more reliable and cheaper to keep running. RPA earns its place where there is no API — legacy systems, locked-down vendor tools, government portals.

Workflow automation moves a job through steps and people — approvals, handoffs, status. RPA does the individual computer task inside those steps. A purchase approval flow is workflow automation; the robot that then enters the approved order into the ERP is RPA. Most operations problems need a bit of both, and they are usually built together.

Licensed platforms make sense for large enterprises running hundreds of robots with a dedicated automation team. For a $10–50M business running a handful of automations, a purpose-built solution is usually easier to change and carries no per-robot licence. We build the second kind, and we will say so when a platform is genuinely the better fit.

Two to six weeks for a single well-scoped automation once the target is agreed. The variable is rarely the build — it is access to the systems and clarity on what the correct behaviour is when the data is wrong. Both of those get settled in the workshop before development starts.

In practice it removes the parts of a role nobody wanted: the re-keying, the checking, the chasing. The teams we build for are usually behind, not overstaffed — the automation absorbs growth instead of hiring for data entry. If a business is buying automation specifically to cut headcount, the honest advice is that the savings are smaller and slower than the pitch suggests.

Four things: they put hours and dollars against each candidate before quoting; they tell you which tasks are not worth automating; you own the code and the IP at the end; and exceptions are designed for, not ignored. If a partner cannot show you the maintenance story for year two, the build is not finished.

Yes, for the same reason spreadsheets are still relevant. Rules-based automation is cheaper, faster and more predictable than a model on tasks that have one correct answer. What has changed is the ceiling: work that was previously impossible to automate because it needed reading and judgement is now in scope. The right build uses rules for the routine and a model for the exceptions.