Processes and SOPs That Are Ready to Be Automated

Atamyrat Hangeldiyev

Systems Architect

March 25, 2026

The returns process at a B2B distributor could not be automated, and the reason had nothing to do with software: the entire thing lived in the fulfilment lead's head and a spreadsheet whose column logic only she could read. The owner wanted it automated because returns were eating two days a week. A capable assistant could have run it. The project stalled in the first week, not on the tooling and not on the budget, but on a single question nobody could answer: what is the returns process, exactly. Not what it usually is. What it is, every time, including the part where she decides a damaged-on-arrival claim is genuine, the part where she emails a specific account manager and not the generic inbox, and the part where she holds a refund until a photo arrives unless the customer is one of four she trusts on sight. None of that was written anywhere. It was her, doing it, knowing it. The day automating it became the goal was the day everyone discovered the process did not exist outside one person, and you cannot automate something you cannot state.

Process readiness is the practice of making a tacit business process explicit enough that a person or a machine can run it without the original person present, so it becomes the precondition any automation is built on, in the context of small and mid-sized businesses whose processes mostly live in a few people's heads. It is its own discipline with a hard end state, and that end state is "documented and automatable": the trigger, the real inputs, the steps as performed, the exceptions, and the definition of done all written down clearly enough that someone, or something, who has never done the work can run it correctly. This guide gets a process to that line and stops. It does not build the automation and does not run it.

What "ready to be automated" actually means for a process

"Ready to be automated" means a specific, checkable state of a process, not a feeling that it is well understood. A process is ready when its trigger is explicit, every input it needs is named and reachable, every step is written as it is actually performed, every exception is written as a rule rather than left to judgment, and "finished" can be confirmed without asking the person who used to do it. Miss any one of those and the process is not ready, no matter how routine it feels to the people who run it today.

Documented and automatable is an end state, not a step inside building an automation

The most expensive misconception here is treating documentation as the first task of an automation project, something the implementer will sort out as they go. It is not a phase of building the automation. It is the precondition that has to be true before building starts, and it is a different kind of work: discovery and writing, done by people who understand the business, not configuration done by people who understand a tool. Treating "documented and automatable" as a distinct, completed end state, signed off before anyone touches automation software, is the single decision that separates projects that ship from projects that stall. Reach that line first. Hand off second.

An example: a process that looked simple and stalled the automation on discovery, not on tooling

On a slide, the distributor's returns process from the opening was four clean boxes: receive request, validate, authorize refund or replacement, close. Anyone would call that automatable, and the tooling to move data between those boxes is trivial and cheap. It stalled anyway, for the reason the opening already showed: the boxes named steps whose real content lived in one person's head, so every hour the implementer spent trying to start the build was an hour spent getting "it depends" out of one busy person. The lesson is blunt: a process can look ready from the outside and be entirely unwritten on the inside, and you only find out which when someone tries to run it without the person.

A process that lives in one head cannot be automated, no matter how cheap the tool is

A machine, and a model, can only run a process that is stated. This is not a limitation of any particular vendor. Claude, the Claude API, and an agentic client like Claude Code can execute genuinely sophisticated work once the work is explicit: the trigger, the inputs, the decision rules, the done-state. None of them can read what is in someone's head. Cheap tooling does not change this. The constraint was never the price of the software. It was always whether the process had been written down well enough to be run by something that cannot ask the original person "what do you usually do here".

The work that is real but unstated: the exception nobody wrote, the input nobody can reach

The part that blocks automation is almost never the happy path. The happy path is easy to state and everyone can describe it. What blocks automation is the work that is real but unstated. There is the exception nobody wrote: the foreman at a 30-person manufacturer who reorders the production schedule when a particular customer's job comes in, because that customer once walked over a late delivery and now gets quiet priority. There is the input nobody can reach: a step that needs last month's actual shipped quantities, which live in a report only one person can pull because only she has the login. There is the "you just know" still sitting inside a step: "then you check whether the order looks normal", where "looks normal" is twenty years of pattern-matching that has never been turned into a rule. Each of these is invisible until you try to run the process without the person who carries it. Then it is the whole problem.

Why the project stalls on discovery and the cost of finding that out after you have bought the tool

These projects stall in the discovery, not the implementation. The implementer asks "what is the process" and gets a description of what it usually is, with the exceptions, the unreachable input, and the judgment quietly omitted because to the person doing it they are not separate steps, they are just the work. Discovery drags because it is reverse-engineering a process out of one person's habits while that person is busy. The cost of finding this out late is the worst version: the tool is already chosen and partly paid for, the implementer is on the clock, and the actual blocker is documentation that should have been done before anyone signed anything. Doing the documentation first is not slower. It moves the slow part to before the spend, where it is cheap, instead of after it, where it is not.

How to make one tacit process explicit

This is the procedure. It takes one process from "lives in someone's head" to "documented and automatable". Do it for one process at a time. Resist the urge to document the whole business at once; that produces a binder nobody opens and no process that is actually ready.

1. →
   Step one: pick one process with a clear trigger and a clear output

   Pick the process that has an obvious starting event and an obvious finished state, and that runs often enough to be worth the effort. Not the messiest, most political process. A returns workflow, an order-to-fulfilment handoff, a new-customer onboarding, a weekly reconciliation: something with a clear "this is what kicks it off" and a clear "this is what done looks like". A clean trigger and a clean output give you two fixed posts to stretch the documentation between. The messiest process is the worst place to learn this skill and the one most likely to produce a document you abandon.

2. →
   Step two: capture the trigger and the real inputs

   Write what actually starts the process, in the real world, not the official version. "An email lands in this inbox with this subject pattern." "The Friday close completes." Then list every input the process consumes, and for each one write where it really comes from and who can actually get it. This is where the unreachable input surfaces: the report only one person can pull, the figure that lives in a spreadsheet on one laptop, the approval that exists only as a verbal "yeah, go ahead". An input you cannot name a reachable source for is a blocker, and you have just found it on purpose instead of three weeks into a build.

3. →
   Step three: write the steps as performed, not as imagined

   Sit with the person while they do the work, on real cases, and write what they actually do, in order. Do not interview them about the ideal process away from the work; you will get the tidy version they think you want, and the tidy version is not the one that runs. Shadowing surfaces the steps that never make it into descriptions: the double-check they do without mentioning it, the system they open and close in four seconds, the message they send that they would never list if asked to describe the process from memory. Write it as it is, including the ugly parts. The ugly parts are the process.

4. →
   Step four: surface every exception and decision the person makes without thinking

   This is the step that decides whether the process is automatable. After every step, ask: is there ever a case where you do something different here, and how do you decide. Keep asking until the answers stop. Each "well, if it's this kind of customer I..." is an exception that has to become an explicit rule: the condition, and what happens when it is true. The four trusted accounts the fulfilment lead refunded on sight are not a quirk; they are a rule that was never written: "if account is in this list, release refund without waiting for the photo." If a decision genuinely cannot be reduced to a rule, write that down too and mark it as the point a human still has to make the call. An unstated exception left in the steps is exactly what stalls the build later.

5. →
   Step five: write the definition of done so finished is checkable without the original person

   Write what "finished and correct" means in terms anyone can check without asking the person who used to do it. Not "the return is handled" but "a credit note exists, the customer has the confirmation, the stock figure is adjusted, and the case is closed in the system." The test of this step is concrete: could a colleague who has never done this work look at a completed case and tell, on the document alone, whether it was done right. If they cannot, the definition of done is still in someone's head and the process is not ready.

When all five are written for one process, you have a documented, automatable process. That is the deliverable. What gets built on it is the next section's problem and a different team's job.

How to tell a genuinely automatable process from one that only looks documented

Having a written document is not the same as being ready. Plenty of SOPs read cleanly and still cannot be automated, because the hard parts were smoothed over in the writing. Run this test on the document before you hand it to anyone. It is three questions and they are pass or fail.

One: can someone who has never done it run it from the document alone

Hand the document to a competent person who has never run this process and is not allowed to ask the original person anything. Have them run a real case from it. Where they stop, get stuck, or guess is precisely where the document is still incomplete. This is the single most honest test there is, because it removes the one variable that hides every gap: the original person quietly filling holes in real time. If they cannot complete it cleanly from the page, the page is not done, no matter how good it reads.

Two: is every input actually reachable, or does one still live in a person's access or memory

Walk every input from step two and confirm a named, accessible source that does not route through one specific person's login or recall. An input that is only reachable because "she pulls that report" is not a documented input; it is a dependency on a person wearing the disguise of a step. Fix it by making the source reachable, or the process is automatable only as long as that person is available, which is the opposite of the point.

Three: is every exception written as a rule, or is "use judgment" still in the steps

Read every step looking for soft language: "use judgment", "as appropriate", "if it looks off", "handle accordingly". Each one is an exception that was felt but not written. Either turn it into an explicit rule with a condition and an action, or mark it deliberately as a decision a human still owns, with the criteria written down. What you cannot do is leave the soft phrase in and call the process ready. A machine reads "use judgment" as a hole, and so should you.

Process readiness versus the things it gets confused with

Process readiness gets conflated with several adjacent things, and the conflations are what cause owners to think a job is done when it is not.

Documenting it versus running and maintaining the automation

These are different jobs owned by different work. Process readiness is documenting the process so it can be automated, and it stops at the documented, automatable process. Running and maintaining the automation is building the live system on top of that document and operating it: the tooling, the monitoring, the on-call, the off-switch. That is the AI and Automation pillar's territory, and this is the one place in the Business pillar that hands across to it. When a process is documented and passes the readiness test, the next work lives in the AI and Automation pillar. This guide is the precondition. That work is downstream of it, and it is a real handoff, not a blurred line.

An SOP for people versus a process explicit enough for a machine

A human-readable SOP and an automatable process are not automatically the same artifact. A people-facing SOP can lean on shared context: the reader knows what "the usual carrier" means, infers the obvious, fills small gaps with experience. A process explicit enough for a machine cannot lean on any of that. Every condition is stated, every input has a reachable source, every exception is a rule, nothing is left to "they will know". A good SOP can be the starting draft for an automatable process, but it is ready only once every place a human would have inferred has been made explicit.

Process readiness versus org structure

Documenting the work and deciding the shape of the roles that do it are separate decisions. You can have a clean org chart and an undocumented process, and the clean chart will not save you: a well-shaped role still fails when the work inside it lives in one person's head and was never written down. How to shape those roles is its own subject, covered in how to structure a small team when AI does part of the work. The boundary here is simple: this guide makes the work legible; that guide decides who is shaped to own it. A documented process is what makes the second decision survivable.

Where this work hands off

Process readiness ends at the documented, automatable process, and naming where the next work goes is part of doing this one honestly.

How the documented process feeds the build

The documented process is the input the build consumes. Building and running the automation on top of it is the AI and Automation pillar's job and, when it is delivered as a service, the operations service that builds and runs the automation is where that work lives. This is stated as fact about the sequence, not as a pitch: get the process to documented and automatable, then the build is real work that someone does next, and it is not this work. The cleaner the document, the cheaper and faster that next stage is, which is the whole reason this stage exists.

How a documented process makes a role absorbable and a hire teachable

Two effects fall out of this work without being its subject. A documented process makes a role absorbable, because work that is written down can be reshaped or combined into a role instead of being trapped in one person; that seam is argued in how to structure a small team when AI does part of the work. It also makes a new hire teachable from the document instead of from the person who happens to know it, which touches the talent question argued in hiring and skills for a business in transition. Both are consequences, not this guide's scope; the documentation is what makes them possible.

How writing it down removes the owner as the single point of failure

When a core process lives only in the owner's head, the owner is the single point of failure for it, and every instance of that process is a claim on the owner's attention. Writing it down removes that dependency, which is why this work connects directly to protecting the owner's scarcest resource, argued in why an owner's decisions matter more than their hours. Naming the effect is enough here; the cadence question belongs to that guide.

The process to write down first

Process readiness is one move in the larger discipline of steering a small business through the AI transition, covered across the Business guides: it is the part where you make the business legible to the people and the machines that will run it, so the work no longer depends on who happens to remember it. The point of this skill is not a binder. It is a small number of core processes that can be run, taught, reshaped, and eventually built on, without the original person in the room. This work ends at documented and automatable; the build belongs to the AI and Automation pillar. Pick the one process that costs you the most when its one person is out, and run the five steps on it this week. When it passes the readiness test, that is the moment to take it to the people who build and run automations and not before.