Automate the repeat work, and only that work

RPA earns its place when a task is repetitive, follows clear rules, runs at steady volume, and sits in a system you cannot change. Typical examples are downloading statements from a bank portal, entering approved invoices into a supplier site, moving data between an old desktop application and a newer one, and filing returns that must be submitted through a web form. Tasks tied to ZATCA, bank or government portals are good examples of this kind of repeat work, though each portal has its own terms of use that we check first.

A bot that clicks through a screen is also the most fragile way to connect two systems. A changed button, a new login step or a slow page can stop it. When the other system offers an API, a file exchange or a database view, we recommend using that instead, and we say so even though it means less bot work. Our rule of thumb: use an API for anything that will live for years and carries money, and use a bot as a bridge when no better door exists or until a proper integration is funded.

The test we apply to each candidate is simple. How often does the screen change, how many exceptions does the process produce, and what does a wrong entry cost? Tasks with unstable screens, heavy judgment or high-value consequences usually need a different answer, such as a workflow system or an integration.

A bot is a user in your systems, so we treat it like one. Each bot gets its own account with only the access its task needs, secrets are held in a credential vault rather than in the script, and access is reviewed on a schedule. Where a system supports it, we use approved service accounts and single sign-on rather than a shared staff password. For application security we follow the principles in the OWASP Application Security Verification Standard.

Every bot we build assumes it will meet something unexpected. A document is missing a field, a portal times out, a figure falls outside a rule. Instead of guessing, the bot stops that item, writes the reason, and places it in an exception queue for a person to resolve. Clearing the queue is a daily job with an owner, and the volume of exceptions tells you whether the process, the bot or the input data needs attention.

We log each run and each item: what the bot read, what it entered, and the outcome. That record supports your internal audit and helps with segregation of duties, since the person who approves a payment should not be the same identity that a bot used to enter it. Maintenance is planned from the start. Screens change, so each bot has an owner, a test that runs after every release of the target system, and a short list of what to check when it fails.

Much repeat work in the Kingdom starts with an Arabic or mixed-language document: a supplier invoice, a bank statement, a customs form, a contract schedule. We combine optical character recognition with validation rules so bad reads are caught, such as a total that does not equal its lines or a date in the wrong calendar. Items with low confidence go to a person rather than into your ledger. For harder documents we can pair the bot with document intelligence, covered in our Arabic document AI work.

Bots often touch personal data, such as employee records or customer identifiers. We apply the Personal Data Protection Law: bots see only the fields they need, logs avoid copying sensitive values, and retention periods are set. If your policy requires in-Kingdom hosting, the bot runtime and its logs run in a local region, with controls aligned to the NCA Essential Cybersecurity Controls where your sector requires them.

A first process usually goes live in three to eight weeks, depending on how clean the process is and how many systems the bot must reach. We also agree an exit plan. If an API or a new system later replaces the screen work, the bot is retired cleanly and the logic moves with it.