What is a standard operating procedure?

A standard operating procedure (SOP) is a written, step-by-step instruction describing how to perform a routine task correctly and consistently, no matter who performs it. Good SOPs capture the current best-known method so quality and safety do not depend on individual memory.

How long should an SOP be?

Aim for one page or one screen per task. If a task genuinely needs more, split it into several linked SOPs rather than writing one long document. Long SOPs get signed during training and never opened again.

What is the difference between an SOP and a work instruction?

The terms overlap and many plants use them interchangeably. Where a distinction is made, an SOP describes a whole procedure (who, when, what) while a work instruction details exactly how one step is performed at one station. The format advice is the same: short, visual, at the point of use.

How often should SOPs be reviewed?

Review an SOP whenever the process changes, whenever a related nonconformance or incident occurs, and on a scheduled cycle as a backstop; annual review is common in regulated plants. The key is naming an owner. Unowned SOPs drift out of date silently.

Who should write SOPs?

The people who do the work, with support from a supervisor or engineer for structure and compliance requirements. SOPs written from a desk describe the process as imagined; SOPs written at the station describe the process as it runs, including the hard-won tricks experienced operators carry.

Standard Operating Procedures: Writing SOPs Operators Actually Use

Q: How do you write an SOP?

Watch the best operator actually do the task, draft short numbered steps (one action each), add photos at the steps people get wrong, flag decision points, then have a different operator follow the draft literally. Every hesitation is a fix for the document. Publish one version at the point of use with an owner and review date.

A standard operating procedure (SOP) is a written, step-by-step instruction that describes how to perform a routine task correctly and consistently, every time, regardless of who is doing it. A good SOP captures the one best-known way to do a job so quality does not depend on which operator happens to be on shift.

That is the definition. The problem is what happens next. Most plants have hundreds of SOPs, and most of them are dead documents.

Why do most SOPs go unused?

Most SOPs go unused because they were written to satisfy an audit, not to help an operator do the job. The symptoms are always the same:

Too long. A six-page SOP for a ten-minute task will not be read at the station. It will be signed once during training and never opened again.
Written from a desk. The author never watched the task being done, so the document describes the process as management imagines it, not as the line actually runs.
No pictures. A wall of text describing a torque pattern is worse than one photo with three arrows on it.
Stored in a binder or a shared drive. If the operator has to leave the station to find the procedure, the procedure has already failed.
Out of date. The process changed two years ago. The SOP did not. Operators learn to ignore documents that contradict reality, and that habit spreads to the documents that are still correct.

When the written procedure dies, the real procedure lives in people's heads, which is exactly the tribal knowledge problem: the plant runs fine until the one person who knows the real setup retires.

How do you write an SOP operators will follow?

Write it on the floor, with the people who do the task, and keep it to one page. Here is the framework we see work:

Pick the task and the trigger. One SOP per task, and name the moment it starts ("at changeover," "when the alarm shows E-42"). SOPs that try to cover a whole job description cover nothing.
Watch the best operator do it. Do not write from memory or from the old document. Stand at the station, time the steps, and ask why at every step that looks odd. The odd steps usually encode a lesson someone learned the hard way.
Draft the steps as short imperative sentences. "Torque the four bolts in an X pattern to 25 ft-lb." One action per step. If a step has an "and," it is usually two steps.
Add photos at the failure points. You do not need a photo of every step. You need one at each step people get wrong: the correct orientation, the right gap, what a good seal looks like next to a bad one.
Mark the decision points. Real work branches. "If the reading is above 140°F, stop and call maintenance" belongs in the SOP, in bold, not in someone's head.
Have a different operator run the draft. Give the draft to someone who does not normally do the task and watch them follow it literally. Every place they hesitate is a defect in the document, not in the operator.
Publish one version, in one place, at the point of use. Kill the copies. There should be exactly one current version, and it should live where the work happens.
Set a review trigger. Date it, name an owner, and review it whenever the process changes or a related nonconformance appears, with a scheduled review (annual is common in regulated plants) as the backstop.

What should a one-page SOP look like?

The best format we know is a single page (or single screen) with a header, numbered steps with photos, flagged decision points, and a revision footer. Here is the anatomy:

Anatomy of a one-page SOP: header, photo-backed steps, a flagged decision point, and a revision footer.

One page is a discipline, not a limit on complexity. If a task genuinely needs more, split it into linked SOPs rather than growing one document nobody reads.

Are SOPs a regulatory requirement?

In many industries, yes. U.S. FDA drug GMP regulations require written procedures for production and process control (21 CFR Part 211, see 211.100), and food GMPs under 21 CFR Part 117 lean heavily on documented procedures. OSHA's process safety management standard (29 CFR 1910.119) explicitly requires written operating procedures for covered processes. If you are working toward GMP compliance, SOPs are the backbone of the whole system, and auditors will check both that they exist and that people actually follow them.

That second part is the trap. An SOP that exists but is not followed is worse in an audit than no SOP at all, because it documents the gap between what you say and what you do.

How do you keep SOPs current?

Treat SOPs as living documents with an owner, a version, and a change trigger, and make the current version the only one anyone can see. Paper makes this nearly impossible: every printed copy is a fork, and every binder is a graveyard of superseded revisions. This is one of the quieter payoffs of digitizing floor paperwork. When procedures and the forms built on them live on tablets at the station, as in Harmony's paperwork digitization module, updating an SOP updates it everywhere at once. There is no version 3 hiding in a drawer, and captured tribal knowledge can be folded back into the procedure instead of staying in someone's head.

Basic revision control does not need fancy tooling, but it does need rules: every SOP has a unique ID, a version number, an owner, an approval, and a date; superseded versions are archived, not deleted; and every change notes what changed and why. In regulated environments, that history is what proves control.

Finally, connect SOPs to improvement. Every kaizen event should end by updating the affected SOPs, because an improvement that never reaches the standard document evaporates within a few shifts. That loop — standardize, improve, re-standardize — is the engine of lean manufacturing. The standard is the baseline you improve from; without it, you cannot even tell whether you improved.