For businesses stuck on software the vendor will never open up

Automating Software That Has No API

Plenty of Australian businesses run an ERP, a practice management system or a trade package that was written before anybody expected software to talk to anything else. The vendor has no integration roadmap, the support desk suggests exporting to a spreadsheet, and meanwhile two people spend their mornings retyping the same numbers into a second system. That is a real problem and it has real answers, but the answers are not equally good.

A screen level robot, one that drives the software the way a person does, is the answer most people arrive at first. It should be the answer you arrive at last. This page sets out the ladder from best route to worst, tells you honestly what breaks and how, and explains why we will not build a robot for anyone who is not willing to pay for its upkeep.

Book a Route Assessment Call (03) 9003 0111

Realistic ROI

4 routes

Should be ruled out before a robot is considered

A supported interface, a database level connection, a scheduled file export, and a report the system can already email or write to disk

1 to 3 hours

Is usually enough to rule the cheap routes in or out

In our experience a structured call with the vendor plus a walk through the export, report and scheduling menus answers most of the question

Every release

Is a moment a screen robot can break

A vendor update, a browser update, a new consent banner or a slow morning can all change what the robot sees on screen

Ongoing

Maintenance is mandatory, not a nice to have

We do not build screen automation without an agreed support arrangement, because an unmaintained robot corrupts records quietly rather than stopping

Four Things to Understand Before You Buy a Robot

Screen level automation is a genuine tool and we build it. It is also the most fragile thing in the toolbox, and most of the disappointment around it comes from four misunderstandings.

A robot is the last rung, not the first idea

The instinct when a system has no API is to reach straight for something that clicks the buttons. Skipping the ladder is expensive, because the rungs above it are cheaper to build, far cheaper to keep alive, and usually already sitting in the software waiting to be switched on. We have lost count of the systems described to us as closed that turned out to have a nightly export, an ODBC driver, a documented report writer, or a paid integration module the client had never been told about. Spend the three hours checking before you spend the money building.

Screen automation breaks silently, and that is the real danger

When a supported interface breaks it usually returns an error, and an error can be caught, alerted and retried. When a screen robot breaks it often does not error at all. A field moves two rows down, the robot types the invoice total into the reference box, presses save, and reports success. Ten days later somebody notices the ledger is wrong and nobody can say which of the four hundred records the robot touched are affected. Every design decision in a screen automation project should be aimed at making that scenario impossible or at least immediately visible.

Maintenance is part of the product, not an optional extra

A screen robot is coupled to a user interface that somebody else controls and can change without telling you. That means it needs somebody watching it, a defined response when it fails, and a budget for the fix. Priced honestly, ongoing upkeep is a real line item rather than a rounding error, and a business that cannot carry that line should not buy the robot. We would rather talk a client out of the project at the quoting stage than hand over something that will quietly rot after the first vendor update.

Governance is what separates a tool from a liability

A robot that logs in as Sharon from accounts is indistinguishable from Sharon in every audit trail the system keeps, which is a problem the day something goes wrong or the day Sharon leaves. It needs its own named account with only the permissions the task requires, its own record of every action it took with a timestamp and a before value, and a human sign off on anything that moves money or leaves the building. None of that is expensive to build in at the start. All of it is painful to retrofit after an incident.

The Decision Ladder, Best Route to Worst

Work down this list in order. Stop at the first rung that works, because every rung below it costs more to build and much more to keep running.

A supported interface

Rung 1

Ask the vendor directly, in writing, whether there is an API, a web service, a partner integration programme or an add on module that exposes data. Ask their partner channel too, because resellers often know about interfaces the front line support desk has never mentioned. Even a paid, limited or poorly documented interface beats a robot by a wide margin, because it is a contract the vendor has some obligation to honour. If one exists, the conversation changes from automation engineering to integration work, and the whole project gets cheaper and steadier.

A database level connection

Rung 2

Many older on premise systems sit on a standard database and can be read directly, often through an ODBC or SQL connection the vendor already supports for reporting purposes. Reading is usually safe and enormously useful, because it gets you clean data for dashboards, reconciliations and downstream systems without touching a single screen. Writing directly to a vendor database is a different matter and normally a bad idea, since it bypasses the application logic that keeps records consistent and will void your support agreement. Get permission in writing, treat it as read only unless the vendor says otherwise, and take a copy rather than querying the live server during business hours.

A scheduled file export

Rung 3

Almost every business system can write a file, and a surprising number can do it on a schedule to a folder or a file transfer destination. A nightly CSV of jobs, invoices or patients dropped into a watched folder is unglamorous, boring and remarkably robust, and it will still be running in five years. The same works in reverse for import, where many systems accept a formatted file that the vendor already documents for data migration purposes. If the export exists but the schedule does not, ask whether the vendor can run it from a command line or a scheduled task, which is often a small piece of paid work.

A report the system already sends

Rung 4

If nothing else, most systems can email a report to somebody every morning, and a report arriving as a PDF or spreadsheet attachment in a monitored mailbox is a usable data feed. It is one sided and it is slow, but it is stable and it requires no cooperation from the vendor at all. This route is often enough for the actual business need, which is frequently reporting, reconciliation or an alert rather than genuine two way integration. Be honest about what the job really requires before dismissing it as too crude.

Buy the route

Rung 5

Before building anything fragile, price the alternatives properly: a paid custom export from the vendor, an upgrade to a version that has an interface, an add on module, or a third party connector built specifically for that product. Vendors will sometimes quote a fixed fee for a one off extract or a custom export, and it costs nothing to ask for that quote in writing before assuming a robot is the cheaper path. Weigh whatever comes back against several years of robot maintenance rather than against the build cost alone, and the sums often land somewhere different from where people expect.

A supervised screen robot

Rung 6

Only when every rung above has genuinely been ruled out does a screen level robot make sense. It logs in with its own account, navigates the software the way a trained person would, reads what is on screen and enters what needs entering. Done properly it is checked against expected values at every step, it stops rather than guesses when the screen does not look right, it writes a full record of everything it did, and a person reviews anything financial before it becomes real. Done improperly it is a very fast way to fill a database with wrong data.

Common Jobs and the Route That Usually Wins

Task	Traditional	Route to check first	Notes
Get yesterday’s sales into a dashboard	Robot opens the report screen daily	Scheduled export or read only database query	Reporting is a read problem, and read problems almost never need a robot. This is the single most over engineered request we see.
Push new customers into the accounting system	Robot types into the customer screen	Check for a supported import file first	Most accounting packages, even old ones, document a contact import format because they need it for migrations.
Raise invoices in an old practice system	Robot fills the invoice form	Vendor import route, then a robot only if refused	Anything touching money should carry a human check, whichever route you take. Volume decides whether the effort is justified at all.
Reconcile two systems that disagree	A person compares two screens	Export both sides and compare the files	Comparison is a data job. Getting data out of both systems is far easier than driving either one.
Book jobs from a web form into a trade package	Robot keys the job in	Check the mobile app or partner interface	A vendor with a mobile app usually has an interface behind it, even if it is not publicly documented. Ask the partner channel.
Chase overdue accounts	Robot reads the aged debtors screen	Scheduled aged debtors report to a mailbox	Once you have the list, the chasing happens outside the old system entirely, which removes the fragile part.
Keep stock levels in step across two systems	Robot updates quantities on screen	Whichever system has a real interface becomes the master	Two way syncing through a screen is the highest risk pattern there is. Make one system authoritative and publish one way.
Extract history before a migration	Robot pages through records	Ask the vendor for an extract, in writing	Vendors are usually cooperative about exit data because the alternative is an unhappy customer telling people about it.

What Actually Goes Wrong With Screen Level Automation

Silent failure that corrupts rather than stops

The failure mode people prepare for is the robot crashing, which is the easy one because you notice. The failure mode that hurts is a layout change that shifts a field, so the robot keeps working and keeps writing values into the wrong places. Defend against it by validating what is on screen before every write, reading the record back after saving and comparing it to what was intended, and stopping the whole run the moment anything does not match rather than skipping the record and carrying on. A robot that halts loudly at record twelve is a minor inconvenience. A robot that quietly mangles records twelve through four hundred is a month of reconstruction.

Shared logins and borrowed credentials

The quickest way to get a robot working is to let it use a staff member’s login, and it is the decision you will regret. Every action the robot takes becomes attributable to a real person in the audit log, which undermines any investigation and is unfair to the staff member. It also means the robot dies the day that person changes their password or leaves. Create a named service account with the minimum permissions the task needs, store the password properly rather than in a script, and check that the licence actually permits an additional non human user, because some vendors charge per named user. Borrowing a person’s credentials is frequently a straight breach of the terms in any case. MYOB’s business terms, to take one published Australian example, tell subscribers never to let anyone else access the product using their username and password, whether acting as their agent or not (checked August 2026).

Vendor terms and support agreements

Read what you signed, because this is not a hypothetical risk. Atlassian’s acceptable use policy, to take one published example, prohibits accessing or searching any part of its services by any means other than its publicly supported interfaces, and names scraping specifically (checked August 2026). Other vendors do not forbid automation but will decline support for any environment where it is present, which matters the day you have a genuine unrelated problem. Terms vary enormously between products and get revised without fanfare, so read your own rather than assuming the general case, and put the question to the vendor in writing before you build. The answer is sometimes a shrug and sometimes a paid integration option you did not know existed.

Nobody owning it after go live

Screen automation accumulates undocumented knowledge fast: which screen has the slow load, which popup appears only on Mondays, which field must be tabbed rather than clicked. If that lives in one contractor’s head, the first vendor update after they move on becomes an emergency. Insist that the automation is documented as a written deliverable, that the failure alerts go to a monitored address rather than an individual’s inbox, and that somebody inside the business knows how to turn it off and do the work manually for a week if needed.

Timing, popups and the small print of a user interface

A screen robot is racing an interface that was designed for human patience. Pages that load in one second on a quiet morning take eight during end of month, dialogues about expiring passwords or new terms appear without warning, and a system that logs you out after inactivity will do so mid run. The right response is generous waiting for specific things to appear rather than fixed pauses, explicit handling of the known interruptions, and a run window chosen for when the system is quiet. Most robots that are described as unreliable are actually just impatient.

Automating a process that should have been deleted

The most expensive screen automation is the one that faithfully reproduces a bad process. Before automating the retyping, ask why the data has to be in both systems at all, whether the downstream system is still needed, and whether the report anyone is producing is still read by a human being. We have seen requests to automate a daily transfer that existed only because of a reporting need that ended three years earlier. Delete first, simplify second, automate third.

How Yes AI Approaches Software With No API

We hunt for a real route before we quote a robot

The first piece of work is a structured search for a supported path: a written question to the vendor and their partner channel, a look through the export, report and scheduling menus, and a check for third party connectors built for that product. You get the findings in plain language whether or not we end up building anything.

We will talk you out of it when the numbers do not work

If the task is twenty minutes a week, or the vendor will sell you an extract for a few thousand dollars, or you are already scoping a system replacement for next year, we will say so. A screen robot is only worth building where the volume is genuinely high, the process is stable, and the business can carry the upkeep.

Built to stop rather than guess

Every automation we build validates the screen before writing, reads the record back afterwards, and halts the run on any mismatch instead of continuing. Every action is logged with a timestamp and the values involved, and anything touching money or leaving the business waits for a human to approve it.

Maintenance is quoted with the build, not after it

The proposal includes the ongoing arrangement: who watches the alerts, what the response time is, and what happens when the vendor changes the interface. If that arrangement is not agreed, we do not build the robot, because an unsupervised one becomes a data quality problem rather than a saving.

From Stuck System to Something That Runs

Five steps. Two of them are aimed at avoiding the robot entirely, which is the point.

Map the real job and count the volume

We watch the task being done, record what actually happens including the exceptions people handle without thinking, and count how many times a week it runs. That number decides whether any of this is worth doing and which route can justify its cost.

Hunt for a supported route

A written question to the vendor and their partners, a search of the export, report, scheduling and integration menus, a check for a database connection the vendor permits, and a look at third party connectors. Findings written down, with prices where a paid option exists.

Design for failure if a robot is the answer

Its own named login with minimum permissions, screen validation before every write, read back verification after, a hard stop on any mismatch, complete action logging, and a human approval gate on anything financial. Agreed before a line is built.

Run it in shadow beside the humans

The automation runs alongside the existing manual process for a defined period, producing output nobody acts on, so its results can be compared against what people actually did. Discrepancies are investigated before the manual process is switched off.

Hand over with a maintenance arrangement in place

Written documentation, alerts routed to a monitored address, a named owner inside your business, a tested manual fallback for the week something breaks, and an agreed support arrangement with response times.

FAQ

Our vendor says there is no API. Is that the end of the conversation?

Not usually. What a front line support desk means by no API is often that there is no self service developer portal, which is a different statement. Ask specifically about an integration module, a partner programme, a documented import or export format, a supported database connection for reporting, and whether the product has a mobile app, because an app almost always talks to an interface of some kind behind it, though a private undocumented one is not necessarily something you are permitted to use. Ask their reseller channel as well as their support desk. In our experience a written question to the right person changes the answer more often than not, and even a paid, limited interface is worth far more than the best screen robot.

What exactly is a screen level robot?

It is software that operates another piece of software through its user interface, the same way a person would: opening the application, logging in, clicking through menus, reading what is on screen and typing into fields. It does not need the target system to cooperate, which is its entire appeal, and it is entirely dependent on the target system looking the way it looked yesterday, which is its entire weakness. In practice it is a trained sequence of steps plus a lot of defensive checking, and the defensive checking is where the real work is.

How fragile is it really?

Fragile enough that you should assume it will break, and design for the break rather than hoping to avoid it. Realistic triggers are a vendor software update, a browser update where the system is web based, a new consent or security banner, a change to a form layout, an unusually slow day, a password expiry prompt, and a record that contains something the robot has never seen. None of these are rare events over a year, and you do not have to take our word for it. UiPath, the largest vendor in this category, says in its own material that interface changes are the primary cause of robot failures and that repairs run anywhere from a few hours to weeks depending on the mess (checked August 2026). The question is not whether it breaks but whether it tells you loudly when it does, which is a design choice you make at build time.

When should we absolutely not build one?

When the manual task takes less than about an hour a week, because the maintenance will cost more than the saving. When the process changes often, because you will be rebuilding rather than running. When you are already planning to replace the system inside the next year or two, because you will pay twice. When the software licence forbids automated access, which some do. And when the business is not willing to fund ongoing upkeep, because an unmaintained screen robot is worse than the manual process it replaced, since it fails quietly and someone still has to clean up the records.

Can it write into the system, or only read?

It can do both, but the two carry completely different risk. Reading is comparatively safe: the worst outcome is a bad number in a report, which is annoying and visible. Writing changes real records, and a robot that writes into the wrong field creates damage that can take weeks to unpick. Where writing is genuinely necessary we build in verification that reads the saved record back and compares it against what was intended, a hard stop on any mismatch, and a human approval step for anything that moves money, issues a document or contacts a customer.

What does ongoing maintenance actually involve?

Monitoring so that a failure raises an alert to a monitored address rather than being discovered a fortnight later, a defined response when the vendor changes something, periodic checks that the output is still correct rather than merely present, and updates to the automation when the process itself changes. It also includes keeping the documentation current and testing the manual fallback occasionally, because there will be a week when the robot is down and the work still has to happen. We quote it with the build rather than afterwards, and we do not proceed without it being agreed.

Should we just replace the software instead?

Sometimes, and it is worth asking honestly rather than defensively. If the system is unsupported, if the vendor has stopped releasing, if it only runs on a machine nobody is allowed to update, or if it is blocking several improvements rather than one, replacement is the better use of the money even though it is the harder conversation. If the system genuinely does its core job well and the only complaint is that it will not talk to anything, automating around it is a reasonable decision, and often the right one for another five years. The mistake is spending heavily on automation around a system you have already privately decided to leave.

Find Out Which Rung You Are Actually On

Book a call. We work through the ladder with you, ask the vendor the right questions, and tell you plainly whether a robot is justified or whether there is a cheaper route you have not been shown. If the honest answer is do nothing, you will get that too.