What it means for a program to be closed
A program is called closed when it leaves you no way in for data. No API, no file import, no access to the database. Sometimes there is an export to Excel, but it goes one way only, and whatever comes in still has to come in by hand.
It happens often with niche business software, with old programs still around because they work, and with supplier or public administration portals, where the only route on offer is a person logging in and filling things out.
Careful though, "closed" doesn't mean "manual by necessity". It only means the easy road isn't there, and you take the one that's left.
The road that's left, using the screens
If the only way to get a piece of data in is the program's window, then you automate the program's window. The system does what a person would do, it opens the software, goes to the right screen, looks up the code, types into the field, presses the button, waits for the confirmation message and moves on to the next line.
The difference is that it doesn't invent the data. It takes it from where the data already is, a PDF, an Excel file, an attachment in the inbox, and before writing it down it checks it against the rules you give it.
Hooking onto the controls or onto the picture
The first way is to read the window's real controls. The field has a name inside the program, and the system finds it by name, not by position. This is the solid way. Move the window or change the resolution and it carries on working. It can be used when the software is built with technologies that expose their controls, which is fairly common on Windows business software.
The second way is to look at the pixels. The system recognizes what a button looks like, or reads the text on screen, and clicks there. It's needed when the program draws everything itself and exposes nothing, certain terminals or certain remote sessions for instance. It works, but it's more fragile. A different theme or a resize is enough to send it back for a fix.
When we can, we use the first. The second is the reserve. The two can be mixed on the same process, real controls where they exist and on-screen recognition for the points that won't be caught otherwise.
Where this stuff breaks
Better said before we start than after. The weak point is that the system depends on how the screen is built. If an update to your software moves a field or changes the text on a button, the process has to be corrected. It isn't a fault, it's the nature of the thing.
Then there are the cases where it isn't worth it at all. A program that changes constantly, or a process where every case is different from the last and the decision sits entirely in the operator's head.
There is the rules side too. Some portals forbid automated access in their terms of use, others put anti-robot checks in the way, and certain software licenses have something to say about it. That's a check to run first, case by case, not a detail to sort out along the way.
One last practical thing, these systems work on a real session, so they want a machine that stays on and a set of credentials. Better a dedicated user with the fewest permissions possible, so what the system is allowed to do is written down and bounded.
How to tell whether your case holds up
The most honest test you can run on your own, in ten minutes, with no technician. Sit next to whoever does the job and write down every step, opens this, clicks here, copies this field, pastes it over there. If you can write the list and the person follows it without ever saying "it depends", the process is stable enough.
If halfway down the list you get a "then I check whether this is one of the awkward customers", you've found the human decision. It doesn't need removing, it needs isolating. Nearly always the part that can be automated is the part before and the part after, and the person stays in the middle.
Then count the volume, not by eye, with the real numbers, how many cases a month and how many minutes each. Here's an example made up only to show the reasoning, say two people spending two hours a day, twenty days a month, that's eighty hours, and eighty hours are worth thinking about. If instead the sum gives you three hours a month, the right answer is "let it go", and that's fine.
Why it's usually a service and not a delivery
An automation that leans on the screens isn't a finished object handed over to sit there. It's something that lives on top of programs that get updated, and every so often it has to be put back in line.
That's why the sensible way to buy it is a fee that includes the person keeping it standing, and not a one-off job that becomes your problem the day of the update. If somebody sells it to you as a delivery and nothing more, ask who fixes it at the first update of your software. The answer tells you a great deal.
The next step
If you want to know whether a process of yours is one of the suitable ones, what's needed is that list you wrote, the name of the program involved and the count of how many times a month. With those you can reason. Without them it's just talk.