How to Write a Manufacturing SOP From Scratch (With a Free Template)

Most advice on writing an SOP comes from software companies who want you to sign up for a subscription before you’ve written a single sentence. That’s backwards. You don’t need a platform. You need a clear document, a real owner, and a way to keep it from rotting. You can run all of that out of a shared drive and a Word file if you have to.

This is how I write a manufacturing SOP from scratch when the goal is a document the third-shift operator will actually use, not a binder that satisfies an auditor and then dies. There’s a free template you can grab at the end. Let’s build the thing.

Step 1: Pick a process that’s worth documenting

Not everything needs an SOP. If you try to document every task in the plant, you’ll burn out and produce fifty mediocre documents instead of ten good ones.

Write the SOP when at least one of these is true:

• The task is done by more than one person and they do it differently.
• Doing it wrong creates scrap, a safety issue, or a customer complaint.
• The person who knows it best is about to retire, transfer, or quit.
• New hires keep asking the same questions about it.

If none of those apply, the tribal knowledge is probably fine for now. Spend your energy where variation actually costs you money. Changeovers, first-article checks, hazardous material handling, and anything tied to a customer spec are usually the first ten you should write.

Step 2: Know where it sits in the hierarchy

People mix up four document types constantly, and the mix-up is why SOPs end up either too vague or thirty pages long. Keep them separate:

• Policy. The “why” and the rule. “All finished goods are inspected before they ship.” One or two sentences. Rarely changes.
• Procedure (the SOP). The “what and who” across a process. “How we receive, inspect, and put away incoming material.” Crosses roles and stations.
• Work instruction. The “how” at one station for one task. “How to set the torque wrench for the M8 bolts on line 3.” Very specific, often with a photo.
• Form. The thing you fill out. The inspection log, the changeover checklist, the sign-off sheet.

The mistake I see most: people cram a work instruction’s level of detail into a procedure, so the SOP becomes unreadable. Or they write a procedure so high-level it tells you nothing. A good SOP names the steps and points to the work instructions and forms where the fine detail lives. It’s a map, not the whole territory.

Step 3: Build the header block first

Before you write a single step, lock down the header. This is the part that makes the document controllable instead of just a file someone saved on their desktop. At minimum:

• Document number. A simple scheme is fine. SOP-RC-001 (receiving), SOP-QA-004 (quality). Don’t overthink it, just be consistent.
• Title. Plain language. “Incoming Material Receiving and Inspection.”
• Revision. Rev 0 for the first release, then Rev 1, Rev 2. Letters work too, pick one and stick to it.
• Owner. A role, not just a name. “Receiving Lead.” Names leave; roles don’t.
• Approved by. Who signed off, and the date.
• Effective date. When this version becomes the one people follow.

If you ever get audited, this header is the first thing a decent auditor looks at. But forget the audit for a second: the header is what lets you answer “which version is the operator actually running off of?” without a guessing game. That question alone is worth the five minutes it takes to set up.

Step 4: Write the steps with acceptance criteria

Here’s where most SOPs fall apart. They list actions but never say what “done right” looks like. “Inspect the part.” Okay. Against what? How many? Pass on what?

Every step that matters should have a step-level acceptance criterion. Write the action, then write how the operator knows they did it correctly.

Weak:

Check the surface finish.

Better:

Check the surface finish against the boundary sample at the QA station. Accept if it matches or is smoother than the sample. Reject and tag any part with visible tool marks deeper than the sample.

Notice what changed. The second version tells the operator the standard (the boundary sample), the decision rule (match or smoother passes), and what to do when it fails (reject and tag). A new hire can run that. The first version requires them to already know everything the SOP was supposed to teach.

A few habits that keep steps usable:

• One action per step. If a step has three “ands” in it, it’s really three steps.
• Use the words the floor uses. If everyone calls it “the blue jig,” the SOP says blue jig, not “Fixture Assembly B.”
• Put the safety call-out right before the dangerous step, not buried in a section at the top nobody reads twice.
• Add a photo when words get clumsy. “Aligned like this” with an image beats a paragraph describing alignment.

Keep it to the steps that are actually load-bearing. If you find yourself writing “walk to the workstation,” cut it. Operators know how to walk.

Step 5: Run it through the approval and revision loop

A document nobody approved is a suggestion. Get the owner and one approver (usually the supervisor or quality lead) to sign off before it goes live. That’s it for the first release. Don’t build a seven-signature approval chain for a one-line job aid; you’ll just teach people to route around the process.

Then set the revision rule up front so changes don’t turn into chaos:

• Any change to a step, a criterion, or a form bumps the revision number.
• Fixing a typo that changes nothing about the work can stay the same revision (note it if you want, but don’t make people retrain over a comma).
• The old version comes out of circulation the day the new one goes effective. Pull the printout off the wall. A controlled document and a stale printout taped next to the machine cannot both be true.

This is the single most common failure I see: Rev 3 lives on the server, Rev 1 is laminated at the station, and the operator follows the laminated one because that’s what’s in front of them. Revision control isn’t a filing exercise. It’s making sure the version in someone’s hands is the version you blessed.

Step 6: Close the loop with training sign-off

An SOP isn’t done when it’s approved. It’s done when the people doing the work have been trained to it and you have a record that says so.

Keep a simple training matrix or a sign-off sheet attached to the SOP:

• Operator name.
• SOP number and revision they were trained on.
• Date.
• Trainer.
• Operator signature.

When you revise the SOP in a way that changes the work, retrain and re-sign. This is what protects you when something goes wrong: you can show the person was trained to the current version. More importantly, it’s the moment you find out your SOP doesn’t make sense, because the operator reads it back to you and asks the question that exposes the gap. Treat that question as free QC on your own document.

Put it together

A working SOP is a clean header, a clear hierarchy, steps with acceptance criteria, a tight approval and revision loop, and a training record that closes the loop. None of that requires software. It requires you to decide the process is worth getting right.

I keep a free SOP template that already has the header block, the step-and-acceptance-criteria layout, and a training sign-off sheet built in, so you’re filling in your process instead of designing a document from a blank page. You can grab it along with the field notes list at the bottom of this page. If you want the longer treatment, including how to build a whole SOP system that doesn’t collapse the first time someone goes on vacation, that’s what my book on manufacturing SOPs is for. You can find it over on the books page.

Write the ten that hurt the most first. The other forty can wait.