How to Write a Restaurant SOP: A Practical Guide with Template

Most restaurant SOPs fail for the same reason: they were written to satisfy an auditor, not to be used by a line cook at 11:40am with wet hands and four tickets on the rail.

A standard operating procedure is not a document. It is a decision you have already made, written down so nobody has to make it again. If your team has to interpret it, guess at it, or ask someone, it isn't finished.

This guide walks through how to write SOPs that hold up on the floor — the structure, the level of detail, the rollout, and the specific mistakes that turn a good procedure into a binder nobody opens.

What an SOP actually is (and isn't)

An SOP answers one question completely: how do we do this specific thing here, every time?

It is not a recipe card, though it may contain one. It is not a training manual, a policy, or a job description. Those things describe context. An SOP describes execution.

The distinction matters because most operators write hybrids. A document titled "Bar Standards" that mixes uniform policy, pour costs, cocktail specs and closing duties is four SOPs wearing one coat. Nobody reads it, because no single person needs all of it.

One task, one procedure. That's the first rule.

Start with the tasks that hurt

You cannot document an entire operation at once, and you shouldn't try. Every group that tries to write 200 SOPs in a quarter produces 200 mediocre ones.

Instead, rank by pain. Ask three questions:

1. What goes wrong most often? Look at your complaint log, your waste sheet, your food safety near-misses.
2. What costs the most when it goes wrong? A mispoured cocktail costs pennies. An allergen error costs everything.
3. What do people ask about constantly? Recurring questions are a documentation gap with a flashing light on it.

The overlap of those three is your first ten SOPs. Write those well and the rest becomes obvious.

The structure that works

After watching hundreds of operations, the procedures that get followed almost always share the same skeleton:

1. Title — task-shaped, not topic-shaped

"Opening the Espresso Bar" beats "Coffee Standards." A title should name an action someone performs at a specific moment.

2. When this applies

State the trigger explicitly. Every morning before service. Whenever a keg is changed. At every handover between shifts. Without a trigger, the procedure has no place to live in someone's day.

3. Who does it

By role, not by name. "Opening barista" survives staff turnover. "Marta" does not.

4. What you need

Tools, equipment, ingredients, PPE. Listing this first prevents the classic failure mode: someone gets four steps in and discovers the sanitiser is empty.

5. The steps

This is the whole document, and it has rules:

• One action per step. If a step contains the word "and," it's probably two steps.
• Start with a verb. "Purge the group head for two seconds." Not "The group head should be purged."
• Be specific with numbers. Not "warm the milk" — 60–65°C. Not "a splash" — 15ml. Vague quantities are where consistency dies.
• Say what right looks like. "Steam until the pitcher is too hot to hold comfortably for more than a second" gives a cook a sensory check they can actually use.

6. How you know it's correct

A short verification: the visual, the temperature, the taste, the weight. If there is no way to check, the standard is aspirational.

7. What to do when it goes wrong

The step most operators skip and staff need most. If the machine won't hold pressure, if the delivery is short, if the product fails the check — who do they tell, and what do they do in the meantime?

A worked example

Here is a weak SOP:

Coffee Quality All espresso should be made to a high standard. Baristas must ensure correct dosing and extraction. Milk should be steamed properly. Check taste throughout the day.

Every sentence is true. None of it is usable. A new starter cannot execute a single word of it, and two experienced baristas will read it and do different things.

Here is the same intent, written as a procedure:

Pulling a Double Espresso

When: Every espresso-based drink. Who: Anyone on bar. You need: Scale, tamper, timer, purge cloth.

1. Purge the group head for 2 seconds.
2. Wipe the basket dry.
3. Dose 18g ±0.5g. Weigh it — don't eyeball it.
4. Level and tamp flat.
5. Lock in and start extraction immediately.
6. Stop at 36g out (±2g), which should take 27–32 seconds.

Correct looks like: Steady honey-coloured stream from second 5. No blonding before second 25. If it runs fast (under 25s): Grind finer by one step, discard, re-pull. If it runs slow (over 34s): Grind coarser by one step, discard, re-pull. Escalate if: Three consecutive shots fail after grind adjustment — tell the shift lead, the burrs or the beans may be the issue.

Same subject. The second one produces the same coffee whoever is standing there, and a new starter can be running it in an afternoon.

Write it with the people who do it

The fastest way to write an accurate SOP is to stand next to your best performer and narrate what they do. They will do things they have never told anyone about — the small adjustments that make their output better than everyone else's. That tacit knowledge is the actual asset. Your job is to capture it before they leave.

It also solves adoption. A procedure your senior staff helped write is a procedure they will defend. One that arrived from head office is one they will work around.

Keep the format ruthlessly short

If a procedure runs longer than a phone screen, it will be skimmed at best. Long documents are usually a sign you've bundled several tasks together — split them.

Two practical formats beat prose almost every time:

• A short checklist for sequential tasks (opening, closing, handover).
• A 30–60 second video for anything physical. Plating, knife work, latte art and machine cleaning are all faster to show than to describe. A phone video with three lines of text beats two pages of instruction.

Rollout: the part that determines whether any of it matters

Writing the SOP is maybe 30% of the work. The rest:

Put it where the work happens. If a cook has to walk to the office and open a laptop, the SOP does not exist. It needs to be on the phone in their pocket, findable in seconds.

Assign it to a role, not to everyone. A dishwasher receiving 60 bar procedures learns to ignore all notifications. Relevance is what protects attention.

Confirm it landed. Not a signature on a printout — actual visibility into who has seen the current version and who hasn't. Otherwise you are guessing.

Give it one owner and a review date. Every SOP needs a named person responsible for keeping it true. Unowned documents rot silently, and a wrong SOP is worse than none — it teaches your team that the system lies.

The mistakes that kill SOP programmes

• Writing for compliance instead of execution. Audit-shaped language ("staff shall ensure") is unreadable at pace. Write how you'd say it out loud.
• Documenting the ideal instead of the real. If your procedure describes an operation you don't actually run, staff will notice immediately and discount everything else you publish.
• Version chaos. The single most common failure in multi-site groups: three versions of the same procedure in circulation, each site convinced theirs is current. One source of truth, updated in one place, or you don't have standards — you have regional dialects.
• Never revisiting. Menus change, suppliers change, equipment changes. An SOP written 18 months ago and never touched is a liability.
• No verification step. Without a way to check the output, you've written a suggestion.

A template to start from

Copy this, fill it in, keep it to one screen:

Task name:
When this applies:
Who does it:
What you need:

Steps:
1.
2.
3.

Correct looks like:
If it's wrong:
Escalate to:
Owner:            Last reviewed:

Where to go from here

Pick your three most painful tasks this week. Stand next to the person who does them best. Write them in this format — one screen each, specific numbers, a verification step. Then get them onto your team's phones and see who actually opens them.

That feedback loop, repeated, is how an operation builds standards that survive turnover. The documents are just the medium. What you're really building is an operation that doesn't depend on any one person remembering.