Most Australian teams did not choose screen-scraping. They inherited it. A vendor portal had no API, a legacy finance system only spoke through its own screen, and someone built a bot that clicked through the interface pixel by pixel. It worked on the demo. Then the vendor moved a button, renamed a field, or added a cookie banner, and the whole chain fell over at 6am with no one watching.
If you run traditional robotic process automation (RPA), you already know this pattern. The bots are fast when they run and silent when they break. Claude computer use offers a different way to retire that fragility without ripping out every workflow at once. This is a practical plan for doing exactly that.
Why screen-scraping bots keep breaking
Classic RPA records a fixed path through a user interface. It remembers that the Submit button lives at a specific coordinate or under a specific element ID, and it repeats that path forever. The trouble is that the path is a promise the software vendor never made to you. When the promise breaks, so does the bot.
The common failure modes are boringly predictable:
Layout drift. A vendor ships a redesign and every hard-coded selector points at the wrong place.
Timing races. A page loads half a second slower than usual and the bot clicks into empty space.
Pop-ups and consent banners. An unexpected modal blocks the flow the script assumed would be clear.
Login and session changes, such as a new multi-factor step, that the recorded path never anticipated.
Silent data errors. The bot keeps running but reads the wrong column, so bad data flows downstream until a human notices weeks later.
None of these are edge cases. For a mid-sized firm running twenty or thirty bots, something in the fleet breaks most weeks. The maintenance tax is the real cost of RPA, and it rarely appears in the original business case.
What Claude computer use does differently
Claude computer use lets Claude look at a screen the way a person does, then decide what to click and type based on what it actually sees. Instead of following a brittle recorded path, it reads the current state of the interface and reasons about it. If the Submit button moved, Claude finds it in its new spot. If a consent banner appears, Claude can dismiss it and carry on.
The practical difference is tolerance for change. A recorded RPA script has zero tolerance: any deviation from the captured path is a failure. Claude has a wide margin, because it is interpreting the goal rather than replaying keystrokes. That single shift is what turns a fragile bot into something closer to a reliable digital assistant that does not page you at dawn.
It is not magic, and it is not free of oversight. Claude works best on tasks where the goal is clear and the consequences of a mistake are recoverable. The retirement plan below is built around that reality.
A staged retirement plan
You do not need to switch off every bot on day one. The safest path is to retire screen-scraping gradually, starting with the flows that break most often and matter least when they hiccup.
1. Inventory the fleet. List every RPA bot, what it touches, how often it breaks, and how much manual rework each failure causes. This alone usually surprises people.
2. Rank by fragility, not importance. The best first candidates are the bots that break weekly on interfaces you do not control. Those are where interpretation beats replay by the widest margin.
3. Rebuild one flow with Claude. Describe the goal in plain language, give Claude access to the screen in a controlled environment, and run it beside the old bot for a fortnight.
4. Add a human checkpoint. For anything that writes to a system of record or moves money, keep a person approving the final step until you trust the flow.
5. Retire the old bot. Once the Claude version has run clean through a real vendor change, switch the RPA script off and move to the next candidate.
Running old and new side by side is the part teams are tempted to skip. Do not skip it. The overlap fortnight is where you catch the difference between a task that looks automatable and one that genuinely is.
The AUD maths
The case for retiring brittle RPA is usually about maintenance, not licence fees. Consider a Sydney operations team running twenty five bots. If three break in a typical week and each failure costs four hours of engineer time to diagnose and patch, at $110 an hour that is roughly $68,000 a year spent keeping the fleet upright, before you count the downstream cost of bad data slipping through.
Rebuilding the ten most fragile flows with Claude computer use might take a focused engagement of around $45,000, plus running costs. If it removes even two thirds of that recurring break-fix work, the payback lands inside the first year and keeps compounding, because the interpreted flows do not accumulate the same maintenance debt. The number that matters is not the build cost. It is the maintenance line that quietly grows every quarter you keep the old bots alive.
Where to draw the line
Retiring RPA is a governance question as much as a technical one. Before you point Claude at any system, confirm you have permission to automate against it. Some vendor terms of service restrict automated access, and scraping a third-party portal you do not own can breach those terms regardless of the tool. Where the workflow touches personal information, the Privacy Act obligations do not change just because an AI is doing the clicking rather than a script.
Keep sensitive credentials in a proper secrets store, log what Claude does so you have an audit trail, and keep a human in the loop for any step that is hard to reverse. Done this way, retiring screen-scraping reduces risk rather than adding it, because you replace an opaque bot that fails silently with an assistant that reasons out loud and can be watched.
If you are carrying a fleet of fragile bots and want a clear-eyed view of which ones to retire first, we help Australian teams plan and stage exactly this kind of migration. Book a brainstorm and we will map your fleet against a staged plan you can actually run.
