On legacy systems with no API, we build software robots that take over the repetitive steps a person performs on screen. The robot runs under its own user account and on a schedule; when something unexpected happens it does not guess, it stops and hands the job over to a person along with a screenshot.
Every office has a job nobody has given a name to: opening one program in the morning and typing the list on screen into another program one item at a time. Downloading the bank statement and posting it into accounting, copying the order list from a marketplace panel and pasting it into a dispatch file, transferring the Excel file in an incoming email into the system row by row. This work usually sits with one person, and when that person goes on leave the work stops. Nobody sees it as a process, because it is written in no procedure and appears in no report. Yet it takes hours during the day, produces errors in the tiredness at the end of a shift, and where the error was made is often only noticed weeks later, when a reconciliation fails to match.
The right answer to this work is usually integration: the two systems are connected and the data is not carried by hand. In the field, though, that is not always possible. The program in use was written years ago and has no external interface (API); the firm that wrote it cannot be reached, or does not want to do the development. Sometimes the development quote that comes back is higher than the cost of doing the job by hand for a year. Sometimes the licence agreement forbids writing directly to the database, and sometimes writing to it reduces the support cover. Sometimes the system is going to be replaced soon anyway and investing in integration with it today makes no sense. In short, the right door is closed, but the work carries on being done the same way every morning.
Robotic process automation (RPA) comes in at exactly this point. RPA is a software robot that takes the steps a person performs on screen — opening the window, clicking the field, typing the data, pressing save, downloading the list — binds them to rules and runs them repeatably. The robot uses the target system's interface just as a user would; that is why no change has to be made in that program and no update has to be requested. The robot has its own user account and its own permission boundary, when it will run is tied to a schedule, and every step it takes is recorded. When it meets a screen it was not expecting, it does not carry on; it stops and hands the job over to a person. The robot is thereby set up not as one employee's shortcut but as an auditable component of the system.
The condition for setting this work up honestly is to say up front what RPA is not. If the target system has an interface (API), the right solution is integration, not RPA; integration runs faster, costs less to build and is far more robust. RPA, by contrast, depends on the screen: when the system changes its screen layout in an update, the robot stops and needs maintenance. That maintenance burden is a fact of the work and is written into the project from the start. Moreover, robotising a badly designed process does not fix it, it only speeds up the error; that is why we strip the unnecessary steps out of the process before moving to a robot. We recommend RPA not as a permanent architecture but as a bridge that works where integration is not possible.
Programs that have been in use for years, still do their job, but offer no external data interface. The firm that wrote it cannot be reached, the source code is not to hand, or writing directly to the database is not possible under the contract. In these companies the robot works through the screen without changing the system at all and takes over the manual transfer.
Accounting and finance teams where jobs such as downloading bank statements, matching payment advices, account reconciliation and invoice posting are repeated every day. The steps are clear, the judgement involved is small, the volume is high. The robot runs those steps overnight; in the morning the team only looks at the exception queue. The gain is not just in time but in the reduction of attention errors.
Teams that gather order, stock and price information by hand from several marketplace or supplier panels. Some of those panels offer an API, some do not. For the ones that do we build an integration, for the ones that do not we write a robot, and we combine the two in the same flow. If a usage would breach a panel's terms of use, we say so from the outset.
A new ERP or industry system has been chosen and the migration will take months. During that period the old and new systems run side by side, the same data is held in two places, and keeping them in step falls on the team. The robot builds this temporary bridge and is removed once the migration is complete. This is one of the most honest uses of RPA.
Not every repetitive job is a job for a robot. We look for steps that can be written as rules, structured input, meaningful volume and countable exceptions. The result this screening frequently produces is this: part of the job can already be solved with an interface, part of it is unnecessary and can be removed, and the real remaining part is given to the robot. RPA projects that skip the screening are usually abandoned quietly under the maintenance burden.
The robot can work in Windows desktop applications, in web panels in the browser and on legacy terminal screens. Fields are selected by identity rather than by position wherever possible, so the robot does not break when the window size or the screen resolution changes. Position-based clicking is used only when no other route is left, and with a written note that it is fragile.
Robots run overnight, at the end of a shift or when an event triggers them. Jobs are queued; each record is processed individually and its status held separately. So when a thousand-row transfer is cut off midway, there is no need to start over — it carries on from where it stopped. How many robots run at the same time and how much load they put on the target system are also limited.
When the robot meets a screen it was not expecting, it does not guess, it stops. The transaction drops into the exception queue; the screenshot and the steps taken up to that moment are recorded and a notification goes to the person responsible. Where necessary, the half-finished transaction is rolled back. A robot that quietly writes wrong data is far more expensive than a robot that never runs at all, and we design to that principle.
The robot does not borrow an employee's account; it works under its own user account and with only the permissions its job requires. Passwords are not hard-coded, they are held in an encrypted vault, fetched at run time and never written to the logs. Every transaction the robot performs is recorded under its own identity, so in an audit the answer to who entered this record does not stay unclear.
Which robot runs which process, who owns it, which systems it touches, when it was last updated and who to call when it breaks: all of it is held in a single inventory. As the number of robots grows, robots nobody knows the purpose of pile up; inventory and ownership prevent that from the start. Changes are versioned and an earlier version can be reverted to when needed.
If the input is a PDF or a scanned document, the robot alone is not enough. Field extraction from documents is designed together with the robot: the document is read, the fields are extracted, the ones with a low confidence score are put to a person, and the robot posts the verified data into the system. Reading and entry then run in a single flow, with no intermediate file retyped by hand in between.
We map out the steps screen by screen together with the person who actually does the work on the ground. The first question we ask is whether the target system has an interface (API). If it does, we do not propose RPA, we propose integration. If it does not, we decide together which steps go to the robot and which stay with people. This stage usually takes a few days for a single process, and at the end we share the scope in writing.
Unnecessary steps are stripped out of the process before moving to a robot, because a broken process robotised as it stands merely breaks faster. The remaining steps are written out one by one together with their exceptions. This written flow becomes the basis both for development and for later maintenance. In the same exercise we also record how often and at what volume the work is repeated.
The robot is developed in short cycles: the main flow first, then the exceptions. What happens if the system does not respond, if the record already exists or if a field is different from what was expected is designed case by case. The typical duration for a first robot is 3-6 weeks; the number of screens to connect to and the variety of exceptions determine that duration. Every version is first run in your own test environment.
The robot runs alongside a person for a while: the robot does the work, a person verifies the result. The differences caught during this period are written back into the robot. When parallel running is skipped, the robot's silent errors are only noticed months later; that is why we do not recommend shortening this step. We decide together when parallel running ends, once the rate of differences caught has fallen.
The robot is tied to the schedule, monitoring and alerts are switched on, and it is registered in the robot inventory. What to do in which situation is handed over to the team in writing. We plan from the outset for the robot possibly needing maintenance when the target system is updated, and we carry out that maintenance under the SLA. If the robot becomes unnecessary one day, its removal is done within the same discipline and it is struck off the inventory.
If the target system has an interface (API), the answer is clear: integration. Integration runs faster, needs less maintenance and is not affected by screen changes. We recommend RPA only when that door is closed; that is, when there is no interface, when the vendor will not do the development, or when writing to the database is not possible because of the contract or the support cover. That is the first thing we check in discovery. We will not sell you RPA when there is an interface, because two years later you are the one paying the maintenance bill.
If the screen layout changes it can break, and we are not hiding that. To reduce the risk we select fields by identity rather than by position; when the robot cannot find the screen it expects, it stops instead of performing the wrong transaction. When it breaks it does not stay silent — an alert goes out and the job waits in the exception queue. Fixes arising from screen changes are handled under maintenance. That is why we position RPA not as a permanent architecture but as a bridge that works until integration becomes possible.
No. Work whose rules cannot be written down and that requires human judgement every time is not suitable for a robot; nor are cases where the input is free text and the exceptions cannot be tied to a rule. We also do not build automations that get around bot protection, disable two-factor authentication, or breach the target system's terms of use. When such a request comes in, we explain why and propose the technically and contractually compliant alternative if there is one. We also report in writing the steps we have left out of scope.
The robot takes the repetitive step that contains no judgement, not the whole job. What remains is usually the reviewing of exceptions, the checking and the deciding; that part stays with people and the workload often shifts there. Having someone to look at the exceptions the robot hands over is a condition of the work. A robot nobody owns quickly becomes a robot nobody trusts, and in the end it is switched off. That is why we determine the responsible person together at handover.
The robot sees only as much as the permissions defined for it. It works under its own user account rather than an employee's, and that account is given only the permissions needed to do its job. Passwords are not written into code or files; they are held in an encrypted vault, fetched at run time and never written to the logs. Every transaction the robot performs is recorded under its own identity, so the audit trail is not broken in an audit. The server the robot runs on and the records it keeps stay within your own infrastructure.
Written process flows and exception scenarios; working robots and their run schedules; a queue and exception screen; the password vault connection together with permission definitions; the robot inventory, version history and monitoring alerts. We also leave behind, in writing, why each step was not given to a robot. The robots' source code, documentation and the records they produce belong to you; you are not locked in to a particular RPA tool or to us.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We build an inventory of your processes, map them as they really are using BPMN 2.0, and define an owner and a measure for each one. We then run them on a process engine (BPMS) and measure cycle time, waiting points and bottlenecks. If a single flow is all you need, we will say that plainly too.
Details →We build the layer beneath the report: data is pulled from source systems by ETL or ELT, modelled across raw, processed and presentation layers, and stored together with its history. Metric definitions are fixed in a single data dictionary, and quality checks catch silent corruption while the data is still being loaded.
Details →We repair the record-keeping in which the same customer has been created three times and the same material sits under two codes. With matching rules, a similarity score and a review queue, duplicate records are deduplicated, a golden record is produced and distributed back to the source systems, and a similar-record warning steps in whenever a new record is created.
Details →We do not build diagnostic imaging software; your existing PACS stays where it is. What we build is the layer that closes the gap between the device worklist, the patient record, the order, the report and sharing: the image is linked to the right patient, pending orders become visible, and the retention and backup status of the archive becomes auditable.
Details →We build student information systems that bring admissions, enrolment, class placement, timetabling, attendance registers, marks, report cards, parent communication and instalment tracking together on a single record. It is designed around your institution's own calendar and your own fee policy; you do not have to fit into the mould of an off-the-shelf package. The source code and the data belong to the institution.
Details →We build laboratory information management systems that run every step on a single record, from the moment a sample is received through to the certificate of analysis: barcoded sample tracking, a method library, instrument connections, specification checks, staged approval and an audit-ready record structure.
Details →
