SOPs in Business: What They Are, What They’re For, and Why Most Go Unused

In the late nineties I ran a shop where a complex changeover took four hours on a good day. On a bad one we’d be setting up for a shift and a half. Same machine, same product, wildly different clock, depending entirely on who happened to be running it that day.

So we built a binder. Step by step narrative instructions for the setup of every custom product we made. We shot video on a camcorder. We stapled in Polaroids of what the tooling was supposed to look like when it was right.

Changeovers came down to two hours or less.

None of that was sophisticated. It was a three ring binder and a VHS tape. What made it work was that the answer finally lived somewhere other than in one person’s head.

That is what a standard operating procedure is for. Everything else on this page is detail.

What Does SOP Stand For in Business?

SOP stands for standard operating procedure. In a business context, it’s a written record of how a specific, repeatable task gets done: the steps, in order, with enough detail that a trained person can execute the task the same way every time without asking anyone.

Three words, and each one is doing work:

– Standard. There’s one agreed way, not four personal ways.
– Operating. It describes what actually happens, not what somebody wishes happened.
– Procedure. It’s a sequence, not a philosophy.

If a document fails any of those three, it’s something else wearing an SOP’s name.

What an SOP Is Actually For

Most companies write their first SOP because a customer audit demanded it, and that origin story poisons the whole exercise. Documentation created to satisfy an auditor gets written for the auditor. It ends up in a binder on a shelf, formally correct and operationally useless.

The real job is smaller and more valuable than compliance.

An SOP takes an answer that currently lives in a person and puts it somewhere the team can reach without that person. That’s the entire mechanism. When your best setup guy is on vacation and the changeover still takes two hours, the SOP worked. When the same question gets asked three times a week and you answer it three times a week, you don’t have a training problem. You have an answer with no home.

Here’s the test I use with clients. Pick any process you consider documented. Now ask: if the person who knows it best were out for two weeks, would the work go on at the same quality and the same speed? If the honest answer is no, that process isn’t documented. It’s described.

The second job an SOP does is give you something to improve. You cannot improve a process that exists in six different heads in six different versions, because there’s nothing to change. Write it down and it becomes an object. Now you can argue about it, test a better version, and measure whether the new way is actually better. This is why I put documentation before improvement in every engagement, and why clarity comes before consistency, and consistency before accountability. You can’t hold anyone accountable to a standard nobody wrote down.

SOP vs. Work Instruction vs. Standard Work vs. Policy

These four terms get used interchangeably and shouldn’t be. The distinction matters because it tells you what to write and how much detail belongs in it.

Policy says what the rule is and why. “All finished goods are inspected before packing.” No steps. A policy sets the boundary.

SOP says how a task gets accomplished from end to end, including who does what and in what order. It can span roles and departments. “Final inspection procedure” covers what the inspector does, what happens when a part fails, who gets notified, and where the record goes.

Work instruction is the narrow, task-level detail inside a step of an SOP. It’s for one person at one station doing one thing. “How to zero the gauge.” Highly specific, often visual, often laminated and hanging at the machine.

Standard work is a lean concept and it’s the one people get wrong most often. Standard work is the current best known method for a task, documented with its timing, its sequence, and its expected work in process. The word “current” is load bearing. Standard work is explicitly a baseline you intend to beat. An SOP describes how the work is done; standard work adds how long it should take and commits you to improving it.

In practice, a small manufacturer does not need all four as separate document types on day one. Start with SOPs for the processes that hurt when they go wrong. Add work instructions where a single step keeps producing errors. Worry about the taxonomy later.

What Actually Goes in One

Every SOP template you’ll find online lists ten or twelve required fields. Most of them are administrative overhead that makes the document heavier without making it more useful. Here’s what earns its place:

– What this covers and where it stops. Scope, in one line. Most confusion about a procedure is really confusion about its boundaries.
– Who does it. By role, not by name. Names change and the document goes stale the day someone quits.
– What you need before you start. Tooling, materials, access, approvals. A procedure that fails at step four because nobody staged the fixture wasn’t a procedure problem.
– The steps, in order, as actions. Start each one with a verb. “Verify the gauge reads zero,” not “gauge verification is required.”
– The failure points. This is the field almost nobody includes and the one experienced operators care about most. Where does this go wrong, how do you know, and what do you do about it. If your veteran knows the machine drifts after the second hour, that belongs in the document.
– Where the record goes. If the task produces a form, a reading, or a signature, say where it lands.
– A revision date and an owner. One line. It’s how you know whether to trust the thing.

Notice what’s missing. There’s no background section, no glossary, no statement of purpose about quality culture. If a step needs explaining, explain it in the step.

Why Most SOPs Go Unused

I’ve walked a lot of floors where the documentation existed and nobody touched it. The reasons are consistent enough that I teach them as a set of four:

Nobody wrote it down. The most common one, and the easiest to spot. The process lives in the operator’s hands and has for eleven years. Everyone knows this is a risk. Nobody has time this week.

It exists but nobody can find it when they need it. This is the quiet killer. The SOP is on a shared drive, three folders deep, in a subfolder named after a project that ended in 2019. Retrieval time exceeds the time it takes to walk over and ask a coworker, so people walk over and ask a coworker. Findability is not a filing problem. It’s the difference between a document that gets used and one that gets audited.

It’s out of date. Someone changed the fixture, improved the sequence, or added a customer requirement, and the document didn’t move. The first time an operator follows a stale procedure and gets burned, they stop trusting all of them. Trust in documentation is a single shared account, and one bad withdrawal drains it.

The team asks you instead. You’re faster than the document, and you’re patient, and you answer every time. Every one of those answers quietly confirms that you are the system. This is the most flattering failure mode and the most expensive.

Three of those four are findability and freshness problems, not writing problems. Which means the effort most companies put into formatting a better template is aimed at the wrong thing.

How to Start Without Stopping Production

The mistake I see most is a company deciding to document everything, building a spreadsheet of 140 processes, and burning out around number nine. Crawl, walk, run applies here as hard as it applies anywhere.

Document what you do today, not what you wish you did. The temptation is to write the improved version. Resist it. If you document the ideal process, you’ve created fiction, and the floor will know within a day. Capture reality first. Reality is the baseline you improve from.

Start with the process that costs you the most when it goes wrong. Not the easiest one, and not the one somebody already half-wrote. Ask which failure has cost you a customer, a shift, or a weekend in the last six months, and start there.

Let the person who does the work write the draft. They know the failure points. You’ll get a rougher document and a dramatically better one, and you’ll get adoption for free because they own it. Your job is to ask “what goes wrong here?” until they run out of answers.

Use whatever format the work deserves. A photo of the correct setup beats three paragraphs describing it. A sixty second phone video beats both. People retain far more from seeing than from reading, and there’s no rule that says a procedure has to be prose. My binder had Polaroids in it for a reason.

Then close the loop. A document nobody trains on and nobody audits is a document that will be wrong in a year. Train on it, then check periodically whether what’s happening on the floor still matches what the paper says. Where they’ve drifted apart, one of the two is wrong, and it isn’t always the floor.

If your problem is less about writing procedures and more about the knowledge never getting out of people’s heads in the first place, I wrote a full piece on how to capture tribal knowledge without writing SOPs nobody uses. And if your team currently does the same job four different ways, start with how to build a process when everyone does it differently before you try to write anything down.

Make Them Prompts, Not Manuals

One more shift, and it’s the one that changes adoption more than any formatting decision.

People forget most of what they learn within a week. That’s not a knock on your team, it’s how memory works. A twelve page procedure fights that reality; a short prompt works with it. The experienced operator doesn’t need to be taught the job again, they need a reminder of the four steps that get skipped when things get busy and the two places this particular job goes sideways.

So write the full procedure once, for training and for the person who’s never done it. Then pull a one page prompt out of it for the person who does it every day. The prompt is what hangs at the machine. I broke down exactly how to build those in process prompts and SOPs.

Final Thoughts

An SOP is not a compliance artifact and it is not a monument to how organized you are. It’s the mechanism that moves an answer out of a person and into the operation, so the work holds together when that person is on vacation, out sick, or gone.

Judge yours by one question. Not whether it’s thorough, not whether it would pass an audit. Whether somebody used it this week without asking you first.

That’s it for today.

See you all again next week!

Dave