Robotic Process Automation

RPA is software that operates your existing systems the way a person does — opening the application, reading a screen, entering data, clicking through a process. It is used where two systems need to exchange information but have no way to connect directly, so a member of staff has become the connection. The robot does that same work on a schedule, without the transposition errors and without the wait.

An integration connects two systems through a proper interface, so data moves directly and reliably. RPA drives the user interface instead, which is slower and more fragile — but it works when there is no interface available, which is the situation with most legacy and vendor-locked systems. Where a real integration is possible, we will tell you, because it is almost always the better answer and usually the cheaper one to maintain.

A macro repeats keystrokes and fails silently the moment a screen changes. What we build runs on a server on a schedule, validates that each screen is what it expected, retries transient failures, keeps a record of every action it took, and escalates to a named person when something is genuinely wrong rather than continuing against a changed system.

It breaks. That is honest and it is true of RPA from any vendor, because the robot depends on screens it does not control. What matters is that it fails safely and stops, rather than continuing against a changed layout and doing the wrong thing at volume. We monitor the robots we build and treat keeping them running as part of the arrangement rather than a separate surprise.

High-volume, rule-based work with a stable process and a clear right answer — reconciliation between systems, data entry into a system with no API, scheduled downloads from a portal, routine compliance checks. Work that requires judgment, negotiation, or frequent exceptions is a poor fit and we will say so rather than take it on.

No — not having to is the reason RPA exists. It sits on top of what you already run, which is why it suits organisations with a core system that cannot be changed, a vendor platform with no integration options, or a regulator's portal that will never expose an interface.

It depends on how many systems are involved and how stable they are, so we quote after discovery rather than from a price list. As a rough guide, a single well-defined process automation is the smallest engagement we take on — smaller than a custom software build — and the sensible first step is one process rather than a programme. Our guide to what drives software cost in Kenya explains what moves the number.

With a discovery call to understand the process you want changed and the constraints around it. From there we scope the work in writing — deliverables, timeline, and cost — before any build begins, so you are approving a defined piece of work rather than an open-ended retainer.

McDorcis Solutions is headquartered in Nairobi, Kenya, and delivers to clients globally. Work is done by our own team rather than subcontracted, and we operate across overlapping hours with clients in Africa, Europe, and the Middle East.