The weekly task nobody should still be doing.
Process automation is the work of removing the repeated manual steps a business has stopped noticing — the export, the re-key, the chase, the Friday reconciliation. Done properly it starts by simplifying the process rather than encoding it, and it leaves behind a trail somebody can audit rather than a black box.
Personal reply from Andrew within one business day.
What is process automation?
Process automation is the practice of having software carry out the repeated, rule-governed steps of a business process, so that a person is only asked for the part that genuinely needs judgement.
Every business has a small number of tasks that exist for no reason anybody can defend. A file is exported on Friday because a report needs it on Monday. An order is confirmed by copying four fields into an email. Somebody runs a check at the end of every month that has never once found an error and cannot be stopped, because the one time it does find something will be the month it was skipped. None of these were designed. They accumulated around the edges of systems that do not talk to each other, and they are paid for every week in the currency a small business has least of.
The first decision is whether the process should exist at all. The most valuable hour of an automation project is usually the one spent asking why a step is there. Steps outlive their reasons: an approval added after an incident nobody remembers, a duplicate check guarding a data entry screen that was fixed two years ago, a report emailed every week to somebody who has left. Automating those makes them permanent and gives them the authority of software, which is considerably harder to argue with than a habit. Simplify first, then automate whatever survives the conversation.
The second decision is what happens to the case that is not ordinary. Automation is good at the ninety per cent that follows the rule and poor at the rest, and the rest is where the design lives. A process that forces every case down the ordinary path will quietly produce wrong answers for the unusual ones. A process that stops and asks a person whenever it is uncertain will be abandoned inside a fortnight. What works is routing the exception to a named person with the reason attached, handling the ordinary case without asking anybody, and keeping a count of how often it had to ask — because that count is what eventually tells you the rule itself needs changing.
The third decision is the trail. Anything that posts a transaction, sends a message to a customer, or changes a number somebody will later be asked to explain needs to record what it did, when, and on what basis. That is not a compliance nicety. It is the difference between a fault that takes an hour to find and one that takes a week, and it is why it just works is such an unsatisfying answer on the day it stops.
Where the repeated work exists because two systems hold the same fact and neither will tell the other, the honest answer is usually an integration rather than an automation — that is covered on systems and API integration. Where the task is a report being assembled by hand each month, see data and reporting. Inside Accredo Saturn specifically, most of this work is event scripting and scheduled jobs, which is the subject of MaxBasic scripting.
What changes when a process is automated?
The same standing task, before and after. The interesting difference is not the time saved — it is where the record ends up and who finds out when something goes wrong.
The visible win is that nobody spends Monday morning on it. The win that matters is that the process now has a state somebody can inspect. In the before column there is no answer to the question did it work last week other than asking a colleague, and that answer is a memory rather than a record. In the after column the question has a factual answer, which is what makes it possible to trust the process without watching it.
The exception queue gets designed last and should be designed first. Every automation produces cases it cannot handle, and where those go is a business decision rather than a technical one. A queue nobody has agreed to read is the same as a log file, and a log file is the same as nothing at all. The questions worth settling before any code is written are which named person opens it, how often, and what they are actually empowered to do about what they find. If the answer to the last one is email the person who built it, the process has not been automated; it has been made someone else’s problem on a delay.
A run that does not happen must be as loud as a run that fails. The most common way an automation stops helping is not an error at all. It is a scheduled job that quietly stopped being triggered — a credential expired, a server was rebuilt, a licence lapsed — and produced no output and no complaint, because the absence of a file is not something anybody notices for about three weeks. Watching the schedule itself, rather than only the runs it produces, costs very little and catches the failure mode that does the most damage.
How much automation is the right amount?
Four routes, and the second one is the one almost nobody checks. It is already paid for, it is nobody’s project, and it is regularly one filter away from doing the job.
| Leave it manual | Configure what you own | Low-code platform | Purpose-built job | |
|---|---|---|---|---|
| What it is | A person does the steps on a rhythm the business has learned, with a written procedure so it survives them being away. | The rules, alerts, scheduled outputs and approval steps already built into products the business pays for and has never switched on. | A drag-and-drop tool that connects services and runs steps between them. Power Automate, Zapier, Make and their equivalents. | Code written for this process specifically, run on a schedule or triggered by an event, inside the environment you already have. |
| Where it wins | Low volume, high judgement, or a process still being argued about internally. | Almost always worth exhausting first. It is the cheapest automation available and the least often used. | Connecting mainstream cloud services, and where somebody non-technical will genuinely need to change the flow later. | Real volume, awkward rules, on-premise systems, or anything that has to post a transaction correctly every time. |
| What it costs | Nothing to build. A recurring slice of a week, and a single point of failure who takes leave. | Somebody’s time to learn what the product already does. No licence, no build, no new supplier. | A per-user or per-run subscription that grows with volume, plus connectors you do not control. | The largest build cost and the smallest running cost. It needs an owner after handover. |
| How it fails | Predictably. Backlogs, transcription errors, and the week nobody is available to do it. | By being forgotten. A setting changed in a screen with no history is hard to explain a year later. | Quietly, on the vendor’s schedule. A connector changes, a limit is reached, a flow is disabled and nobody is told. | At the edges nobody tested. The advantage is that the failure can be read, reproduced and fixed. |
| What it needs from you | A written procedure and at least one person cross-trained. | Willingness to change how a screen is used, which is a larger ask than it sounds. | A licence, and a decision about who is allowed to change a flow that is running live. | An agreed definition of the process, and a named owner for it afterwards. |
The second column deserves more pressure than it gets. Most businesses are paying for capability they have never enabled: an alert on a threshold, a scheduled output the product already produces, an approval step in the accounting system, a rule in the mail platform. Turning one of those on costs an afternoon and no licence, and it removes the same task a project would have removed for a great deal more money. It stays unused because it is nobody’s project — it produces no invoice, no launch and nothing to point at — which is a poor reason for a business to be paying twice.
The third column is not a trap, but it is oversold. A low-code platform genuinely earns its subscription where supported connectors already exist for every service involved, and where a named non-technical person will need to adjust the flow after handover. It stops earning it when volume grows past the plan, when the logic gets beyond a couple of branches, or when the systems in question are on-premise and reached through interfaces the platform does not speak. The cost that surprises people is not the licence. It is that a flow assembled in a browser has no meaningful history of what changed, so a year later nobody can say why it does what it does.
Wherever a process ends with a business system posting a transaction, the choice narrows quickly, because the hard part is no longer the connection. It is validation, safe retries and reconciliation — the same three concerns set out on systems and API integration, and they apply whichever of the four columns above is chosen.
How does a process actually get automated?
Three phases in a fixed order. The second one regularly removes more work than the third one does, which is not the order most projects are sold in.
Follow the process as it runs
- Every step, including the undocumented ones
- Volume, frequency and who does it
- The exceptions handled by hand
- Which steps exist only from habit
A process described in a meeting and a process observed on a Wednesday afternoon are rarely the same thing, and the gap between them is precisely where the exceptions live. Nothing is built in this phase, and part of the point is that some of what it finds will be deleted rather than automated.
Remove before automating
- Steps whose reason has gone, retired
- Duplicate checks collapsed into one
- Definitions agreed where two exist
- Whatever remains, written down
Automating a step is a decision to keep it indefinitely, so this is the last cheap opportunity to decide a step should not exist. It routinely removes more work than the automation that follows it, and it is the phase most likely to be skipped because it produces nothing visible.
Run it beside the old way
- One process end to end, not five partly
- Exceptions into a queue a person reads
- Parallel running against the manual output
- Handover to a named owner
The parallel run is what gets compressed when a project runs late, and compressing it is how an automation goes live carrying a fault that surfaces at a month-end. Keeping the old process available for a few weeks costs almost nothing next to discovering the fault after it has been dismantled.
- Runs completed on scheduleexpected: all of them
- Exceptions raised and clearedcounted, not hidden
- Time from event to recordmeasured both ways
- Manual steps still remainingnamed individually
The third measure is worth agreeing before anything is built, because it needs a baseline and the baseline stops being available the moment the old process is switched off. The fourth is deliberately awkward: every automation leaves some manual steps behind, and naming them individually is what prevents a project being declared finished while somebody is still opening a spreadsheet on Fridays. No figures appear on this page. The only honest ones are measured in your own business, against its own starting point.
Not sure whether a task is worth automating, or worth deleting? That is exactly what the free audit is for.
Book a free process auditWhen is automating the wrong answer?
Often enough that it is worth checking before anything is scoped. Four situations account for most of them, and all four are recognisable early.
The process is still being argued about. If two people disagree about the right sequence, automating it does not settle the argument. It awards it to whoever happened to be in the room, and then encodes the result in something considerably harder to change than a habit was. Settle the process on paper, run it that way for a month, and automate what survives contact with a real month.
The judgement is the work. Some tasks look repetitive from the outside and are actually a sequence of small decisions: which supplier to chase first, whether a discrepancy is worth a phone call, which customer will take the news badly. Automating that shape produces something that asks a person to approve every case, which is the original task with an extra screen in front of it. The useful version is narrower — automate the gathering, and leave the deciding alone.
The upstream data is wrong. Automation is indifferent to quality. It moves whatever it is given, faster and in greater volume, and it does so without complaint. If the source records are inconsistent, the first honest piece of work is the data rather than the pipeline. This is unglamorous, it is rarely what anybody wants to hear, and it is regularly the difference between an automation that is trusted and one that is quietly worked around.
Nobody will own it. An automation with no owner is a future outage that nobody in the building can debug. If there is no answer to who is told when it fails and who is allowed to change it, that is a real reason to keep the process manual, or to choose a deliberately simpler mechanism on the grounds that a person notices when something stops arriving. Sometimes a small custom app with a visible screen is the more maintainable answer than a background job nobody can see.
Questions about process automation.
What is the difference between process automation and systems integration?
Integration is about two systems agreeing on data; automation is about a sequence of steps happening without a person. They overlap constantly, and the distinction still matters because it decides what the first piece of work is. If the repeated task exists because two systems hold the same fact and neither will tell the other, the answer is an integration, and automating around it only builds a faster version of the problem. If the task is a sequence within one system, or across systems that already agree, it is an automation. Most real projects contain some of each, and the useful discipline is naming which part is which before anybody chooses a tool.
Should we use Power Automate, Zapier or something similar?
Sometimes, and the decision should turn on three questions rather than on the demonstration. Do supported connectors already exist for every service involved, including the on-premise ones? Will somebody without a developer background genuinely need to change the flow after handover, and is that person named? And does the volume fit inside the plan being quoted at next year’s volume rather than this year’s? Where the answers are yes, a platform removes real work and is worth the subscription. Where they are no, it adds a cost, a supplier and a second place your business logic lives, without removing any of the decisions that actually matter.
How do you know the automated version produces the same result as the person did?
By running both and comparing, for long enough to be dull. The manual process stays in place and its output is compared with the automated one every cycle — daily where the process is daily, and across at least one full month-end wherever the numbers reach a ledger, because month-end is when the unusual cases turn up. Differences are investigated rather than explained away; the difference dismissed early is reliably the one that reappears at year-end. The old process is retired when the comparison has been boring for a stretch everyone involved is comfortable with, not on the day the build is finished.
Does automation mean fewer people?
Usually it means the same people doing different work, and it is worth being straight about why rather than simply reassuring. The tasks that automate well are the low-judgement, high-repetition ones, and very few small businesses are fully staffed for the judgement work they already have — so the realistic outcome is a week that gets its afternoons back, spent quoting instead of re-keying, or chasing the exception instead of processing the ordinary. It would be dishonest to promise that no role is ever affected anywhere. What can be said plainly is that the projects which go well are the ones where the people doing the task helped design its replacement, and the ones that go badly are the ones where they first heard about it at go-live.
How long does it take, and what does it cost to keep running?
The build is rarely the long part. Watching the process, agreeing what it actually is, and removing the steps that should not survive usually takes longer than writing the automation, and the parallel run at the end is measured in weeks because it needs a full business cycle to disagree with you. The running cost is the part most often left out of an estimate: an automation needs somewhere to run, credentials that expire and have to be renewed, and a person who is told when it stops. That is small, but it is not zero, and a quote that does not mention it is quoting about two thirds of the job.