Operations
How to Standardize a Process Before You Automate It
You have finally decided to automate something. Good. Then you sit down to map the steps and discover that you do the task one way, your office manager does it a different way, and the part-timer who covers Fridays does a third way nobody taught her. Whichever version you hand to the automation, the other two people will keep hitting cases it was never built for.
That is the part almost nobody mentions before you start: you have to standardize a process before you automate it, meaning get everyone doing the task the same way, in the same order, before you build anything on top of it. Skip that step and you are not automating a process. You are automating one person's guess at what the process is.
What does it mean to standardize a process?
A standardized process is one where everyone who does the task follows the same steps, in the same order, and gets the same result, regardless of who is doing it that day. It is not about writing the steps down, that is documentation. Standardizing is agreeing on which steps are correct in the first place.
You can have a beautifully written procedure for a process nobody actually follows. That is documentation without standardization, and it is more common than most owners think.
Why you can't automate before you standardize the process
Automation does exactly what you tell it to, every single time. That is the whole appeal, and it is also the problem, because it cannot do "it depends."
If three people run a task three different ways, you have to pick one to automate. The automation then handles that one version well and breaks, silently or loudly, on the other two. The people running those other versions notice quickly. Most of them route around the automation rather than report it, because reporting it feels like more work than just doing the task by hand again. Six months later you have an automation running in the background that half the team has quietly stopped trusting.
An automation cannot absorb a process that was never agreed on. It can only calcify whichever version got fed into it.
This is the same idea behind Question 2 in how we decide what to automate: do you do it the same way every time. That post tells you how to check whether you are stable enough. This one is about what to actually do when the answer is no.
Step 1: Find every way the task is currently being done
Before you can pick a standard, you need to see the variation, and you will not see it by asking "does everyone do this the same way?" People answer that question yes almost every time, because they are not comparing their version to anyone else's. They are comparing it to their memory of the instructions, which is not the same thing.
Instead, watch. Ask each person who touches the task to walk you through it while they actually do it, not describe it from memory. Write down where the steps diverge: different order, an extra check one person adds and another skips, a shortcut someone figured out two years ago that never got shared.
For a task done by one person, the comparison is across time instead of across people. Pull the last five times you did it and check whether they matched. Solo business owners drift too, usually without noticing.
Step 2: Pick one version, and be able to say why
Once you can see the variations, choose one as the standard. Resist the urge to pick whoever has seniority or whoever is loudest about their method. Pick based on outcomes: which version produces fewer errors, handles the known exceptions, and takes a reasonable amount of time.
Write the reason down next to the decision. "We standardized on Maria's version because it catches duplicate orders before they ship, and the other version does not" is a sentence you can defend. "This is how we're doing it now" is not, and it is the version that gets quietly ignored.
If two versions are genuinely close, run both for two weeks with a simple count of errors or complaints, then decide with the numbers instead of the argument.
Step 3: Write the standard down where everyone can see it
This is the documentation step, and it is where a lot of standardization efforts stall, because writing it down feels like the finish line when it is closer to the midpoint.
If you are using AI to turn your notes into a clean written procedure, the same cautions apply here as anywhere else. We covered the specific failure points in our post on AI-generated SOP mistakes: the model will confidently fill gaps you did not describe, and it will flatten the exceptions you just spent two steps identifying. Feed it your standardized version, not a vague description, and check it against the real process before anyone follows it.
Put the finished version somewhere people will actually open it. A folder nobody remembers exists is functionally the same as no documentation at all.
Step 4: Prove it is stable before you build anything on top of it
A standard only counts once people are actually following it, not once it is written down. Run the standardized version for a real stretch of time and count deviations.
The rule we use with clients: track every run of the task for two to four weeks, or the next ten to fifteen times it happens, whichever comes first. If people are still going off-script more than once in ten runs, it is not stable yet, keep coaching to the standard rather than moving to automation.
Once deviations mostly disappear, you have something worth automating, because now there really is one version of the task, not three versions wearing the same name.
A worked example
Here is how this looks in practice. The business below is a composite example built to show the arithmetic, not a real Enovadi client.
A five-person service company wants to automate its client intake. Before touching any software, the owner watches all three people who take intake calls. She finds three different versions: one person asks for a deposit up front, one asks for it after the first site visit, and one forgets to ask until billing catches it, usually two weeks late.
Step 1 surfaces this in about ninety minutes of observation across three calls. Step 2: the owner picks "deposit up front," because it is the only version that has never resulted in a chase-down call, and writes that reason into the standard. Step 3: she documents the four-step intake call, deposit request included, and puts it in the shared drive everyone already uses. Step 4: she tracks the next twelve intake calls. Two go off-script in the first week. By week three, all twelve follow the standard. That is the point she brings in automation, to send the deposit request automatically the moment a call ends, because now every call actually needs that same request.
Skipping to automation in week one would have built a deposit reminder for the version of the process two of her three staff were not yet using.
What to do when your team disagrees about the right way
Disagreement here is normal and usually means two people are both partly right. The fastest way through it is not a meeting, it is a two-week trial. Run each version with the same amount of volume, count outcomes that matter, errors, complaints, and time, then let the numbers pick.
The exception is anything involving safety or compliance. There, the standard is not up for a vote. It comes from whatever regulation or manufacturer instruction applies, and the team's job is learning it, not improving on it.
Standardizing, documenting, and automating are three different jobs
These three get talked about as one thing, and treating them that way is most of the problem.
Standardizing decides what the correct way is. Documenting writes that decision down so it survives someone being on vacation. Automating removes the human from steps that no longer need judgment. Each one depends on the one before it. A beautifully written SOP for an unstandardized process just documents the confusion more clearly. An automation built before either step just runs that confusion faster.
The American Society for Quality describes standard work as something that "helps ensure that each step in the process is clearly defined so that work can be performed repeatedly in the same manner", and notes that variation in how a process runs is what produces the mistakes and rework in the first place. That is standardizing. Writing it down and wiring up software are the two steps after it, not substitutes for it.
Questions we get asked
Is standardizing a process the same as writing an SOP?
No. Writing the SOP documents whatever version you decide is standard. If your team has not actually agreed on one version yet, the SOP just documents one person's opinion, and the other versions keep running underneath it.
How long does it take to standardize a process?
For a task that happens daily, plan on two to four weeks: a few days to observe the current variations, then two to three weeks running the chosen version while you track deviations. Tasks that only happen monthly or quarterly take longer to gather enough repetitions to call stable.
Can I automate a process that still changes often?
Only the parts of it that have stopped changing. If half the task is settled and half is still evolving, automate the settled half and leave the rest manual for now. Automating a moving target usually means rebuilding the automation every time the process shifts, which costs more than doing that part by hand.
Do solo business owners need to standardize, or is that just for teams?
Yes, even solo. The variation shows up across time instead of across people: you do the task differently on a rushed Tuesday than on a calm Thursday. Standardizing solo work also matters the moment you plan to hire, because you are about to hand someone your process, and it needs to be one process, not whichever version you happened to be running that week.
The short version
- Find the variation first. Watch people do the task, do not ask them to describe it.
- Pick one version and write down why. A defensible reason beats seniority or volume.
- Document the chosen version, not a vague summary of the task.
- Track it for two to four weeks before automating. Once deviations mostly disappear, it is ready.
Automation rewards a process that is already settled. It punishes one that is not, just more efficiently than a human would have.
If you want a hand with this
Working out which version of a process to keep, and proving it is stable enough to build on, is most of what our process organization and systemization work covers. It usually comes before any automation conversation, not after.
If you have a task that three people on your team all do differently, send us a message. Happy to help you sort out which version is worth keeping.