Intelligent Process Automation at Scale

An automated process that only handles the straightforward case is not really solving the problem. The difficult part of automation at scale is not the normal path but what happens when that path is unavailable, and whether the failure stops the process or gets routed around it.

Patient referrals are a useful example. A clinical record moving from a rural health post to a hospital has to arrive every time, whatever happens to be available at that particular moment. Building that around a single channel, ordinary internet, means the process breaks as soon as the channel is missing, and in many of the places we work it often is. The system runs as a cascade instead, attempting standard internet first and then falling back through long-range radio, structured SMS, USSD, Bluetooth and finally a printable QR code if nothing else gets through. It works through each option automatically until the record arrives, so the receiving facility ends up with a complete record rather than a partial one or nothing at all.

That is what automation at scale actually demands, not one efficient path that works most of the time but a system that keeps trying until the job is done. At scale, working most of the time translates into a real number of cases falling through every day, and each of those cases is a patient whose record did not reach the facility treating them.

The same principle applies well beyond healthcare. Wherever a process runs continuously and at volume, it meets its edge cases constantly rather than occasionally, which means a system designed only for the clean path is quietly failing a measurable number of people every day it operates. Designing for that means spending less effort polishing the common case and more on making sure nothing disappears when a step does not go as planned, including surfacing the failure to someone who can act on it rather than letting it sit silently in a queue.