Map Before You Automate
Why strategy first automation lasts, and where not to automate at all.
The instinct, once a team finally has the appetite to automate something, is to ask what can we automate first. It is an understandable question, and it is the wrong place to start. The right first question is quieter and considerably more useful: do we actually understand this process well enough, exceptions and all, to automate any part of it safely.
This guide is not a generic planning exercise dressed up for healthcare. It sets out a specific risk this sector carries that most automation advice never mentions, the workaround that is quietly catching a safety problem nobody has written down, and a practical way to map a process properly before deciding what, if anything, is ready to hand to automation.
Why the instinct to automate first is understandable, and risky
Teams who reach for automation quickly are usually doing so for a good reason. They are stretched, the paperwork is genuinely overwhelming, and relief that arrives sooner feels like relief that matters more. That instinct deserves respect, not correction.
What it needs alongside it is a moment’s pause, because automating a process nobody has properly mapped tends to produce something fragile. It works cleanly in the scenario someone happened to picture, and behaves unpredictably the moment it meets the exception that scenario never accounted for, which in a clinical setting is rarely a minor inconvenience.
What a proper map actually reveals
A genuine map is not a tidy flowchart drawn from memory in a meeting room. It is a real pathway, walked through end to end with the people who actually do the work, including every handoff between teams and systems, and every point where something unusual gets handled differently to how the policy document describes it.
Done properly, this exercise nearly always surfaces two things a team did not fully realise before starting: how many quiet workarounds have accumulated around the official process, and how much disagreement exists, even among experienced staff, about what the process actually is once you look closely.
The hidden safety net problem
This is the risk most guidance on this subject never names directly. A workaround that has grown up around a formal process is not always inefficiency waiting to be tidied away. Sometimes it is the thing quietly catching a risk the official process itself was never actually built to handle.
Before you automate around a workaround, ask what it is actually protecting against. Removing it without knowing may not simplify the process. It may remove the only thing currently catching a problem nobody documented.
A member of staff who always double checks a particular field, or always calls a colleague before proceeding in a specific situation, is often acting on exactly this kind of unwritten institutional knowledge. Mapping the process properly is what surfaces this before automation quietly builds around it, or worse, removes it.
Two different reasons something isn’t ready to automate
A proper map tends to reveal that not everything currently unsuited to automation belongs in the same category. Some of it never should be automated. Some of it simply is not ready yet, and could become so with the right groundwork.
| Reason | What it actually means |
|---|---|
| Not ever | The step genuinely requires clinical judgement, a sensitive human conversation, or an assessment of a specific individual’s circumstances that cannot be reduced to a rule |
| Not yet | The process itself is inconsistent or contested among the people running it, and needs proper agreement and standardisation before anything is automated around it |
Treating a not yet as a not ever wastes an opportunity. Treating a not ever as a not yet is how automation quietly ends up somewhere it was never safe to be.
Where automation should never go, whatever the map shows
None of this is a limitation on what automation can eventually achieve elsewhere. It is simply an honest acknowledgement that some parts of care were never meant to be reduced to a repeatable process in the first place, and respecting that is part of what makes everything else in this guide trustworthy.
- Any assessment of clinical risk specific to an individual patient’s circumstances
- Conversations about consent, difficult diagnoses, or safeguarding concerns
- Situations with genuinely little precedent, where a rule built from past cases has nothing reliable to draw on
- Any moment where a patient needs to feel they are speaking to a person who understands them, not a process
What skipping the map actually costs
The cost of skipping this step rarely shows up immediately. It shows up months later, when the automated process meets an exception it was never told about, and either fails visibly or, worse, proceeds confidently down the wrong path. At that point, the fix is no longer a conversation. It is an incident, a piece of rework, and a team’s trust in automation set back considerably further than a proper map would ever have cost in the first place.
Every one of these late discoveries was, in principle, knowable in advance. The map is simply the moment a team chooses to find them deliberately, rather than waiting for a patient, a colleague, or a regulator to find them instead.
Your map is what your Clinical Safety Officer will actually need
Any automation likely to touch a live patient record or clinical workflow needs proper clinical risk management, involving a Clinical Safety Officer and the documentation this sector rightly requires. A genuine process map is not a separate piece of work sitting alongside that requirement. It is very often the single most useful input to it.
A clinical risk assessment produced without a proper map tends to describe the process as it was supposed to work. One built from a genuine map describes it as it actually does, workarounds and disagreements included, which is precisely the version a Clinical Safety Officer needs to assess the risk honestly.
Signs you are not ready to automate yet
Worth an honest check before any build begins:
- Two experienced members of staff would describe the same process noticeably differently if asked separately
- Nobody could name, with confidence, every workaround currently propping the process up
- The policy document describing the process has not been checked against how it actually runs recently
- Nobody has asked why a particular workaround exists, only whether it could be removed
- The people who do this work every day have not been properly involved in describing it
None of these signs mean automation is off the table. They mean the map needs finishing before the build begins, which is a considerably cheaper problem to solve now than later.
Why strategy first automation actually lasts
Automation built around a properly mapped process holds up in exactly the moments that matter, because the exceptions, the workarounds, and the genuine points of disagreement were dealt with before anything was built, not discovered afterwards when something goes visibly wrong.
This is the quiet difference between a system that needs patching every few months and one that simply keeps working. The map is not a delay before the real work begins. It is the reason the real work does not need redoing.
A practical approach to mapping before you automate
- Walk the real pathway with the people who actually run it. Observe or discuss the process as it genuinely happens, not as the policy document describes it.
- Document every workaround, and ask why it exists. Treat each one as a question before a target, understanding what it protects against before deciding its fate.
- Get genuine agreement on how the process should work. Where staff describe it differently, resolve the disagreement before building anything around either version.
- Classify every step honestly. Sort each part of the pathway into genuinely routine, not yet standardised, or never appropriate to automate.
- Start with the clearest case the map actually supports. Choose the step with the least ambiguity and the strongest agreement, and prove the approach there first.
What this looks like when it is done well
Teams who map before they automate describe a calmer process on both sides of the decision. What gets automated tends to work quietly and reliably, because it was built around the process as it actually happens. What stays with a person stays there deliberately, not by default, and everyone involved can explain exactly why.
None of this asks a team to move more slowly out of caution alone. It asks them to spend a little time understanding the work properly, so the automation that follows actually earns the trust it needs to last.
