How to Write an F&B SOP That Your Staff Actually Follow

You wrote the SOP. You printed it out. You put it in the folder.

Nobody read it.

This is not a discipline problem. It's a documentation problem. Most F&B standard operating procedures are written for auditors, not operators — dense, jargon-heavy, and formatted like a compliance manual for a regulated industry. Staff skim them once during onboarding and never think about them again.

The result: every senior staff member becomes a walking SOP. Institutional knowledge lives in people's heads. When they leave, it leaves with them. New hires learn by osmosis — or by making expensive mistakes during a Saturday dinner rush.

There's a better way to write them. Here's what actually works.

---

Start with the failure, not the procedure

Most SOPs begin with the objective. "The purpose of this procedure is to ensure consistent food preparation standards across all kitchen stations." Nobody reads past line two.

Start instead with the specific thing that goes wrong when the SOP isn't followed.

"If portion weights aren't checked at assembly, COGS creep. A 10g overrun on every plate across 200 covers is 2kg of product — every night."

Now you have someone's attention. They understand why the procedure exists before they read a single step. That context is what converts a document into a habit.

If you can't articulate the failure clearly, you probably haven't scoped the SOP correctly. An SOP that covers too much ground is too abstract to be actionable.

---

One SOP per failure mode

The temptation is to write SOPs that are comprehensive — a single document that covers everything about, say, opening procedures. Don't.

Split them by failure mode. Opening procedures break down into at least five distinct things that can go wrong: mise en place not completed before service, fridge temps not logged, station setup inconsistent across shifts, daily prep list not generated from actual orders, delivery not cross-checked against the PO.

Each of those is a separate SOP. Each one can be owned by a specific role. Each one can be trained and tested independently.

Shorter documents get read. Longer ones get filed.

---

Write for a tired person at 6am

This is the only editorial standard that matters.

Your staff are reading this document at the start of a double shift, or after a chaotic close, or in their first week before they've learned your kitchen's shorthand. They are not in a quiet office with a cup of coffee.

What that means in practice:

• Active voice, short sentences. "Check the fridge temp. Log it on the sheet. If it's above 5°C, call the manager." Not: "In the event that refrigeration temperatures are found to exceed the recommended threshold of 5°C, the relevant manager should be notified."
• Numbered steps, not prose paragraphs. Give them a list they can follow with one eye while doing something else.
• Bold the non-negotiables. Every SOP has one or two steps that, if skipped, break everything. Make them visually distinct.
• No jargon they haven't been taught. If your SOP references a system, a code, or an internal term, define it on first use. Don't assume it's common knowledge.

---

Put it where the work happens

A SOP in a folder is a SOP nobody reads. A SOP laminated and taped above the prep station is a different document entirely.

The format should match the location:

• Kitchen stations: laminated one-pagers with photos. Steps on one side, visual reference on the other.
• Delivery and receiving: checklist format on a clipboard, printed fresh each shift.
• Finance and reconciliation: digital, searchable, stored where the team actually does the work — not buried three folders deep in Google Drive.

If your team works primarily off WhatsApp and a shared phone, your SOP needs to exist there too. A pinned message, a voice note walkthrough, a simple photo guide. Meet them where they are.

---

Version it. Don't just edit it.

Menus change. Suppliers change. You add a venue. Your delivery partners update their APIs. The SOP from 18 months ago is probably wrong about something — and nobody knows which parts.

Every SOP should have a version number and a date. Every change should be communicated, not just updated silently in a doc somewhere.

A staff member who follows the old version and gets it wrong isn't the problem. An ops team that can't track what version is live is.

---

Test it before you publish it

Before an SOP goes live, have someone unfamiliar with the process follow it exactly as written. Not someone who already knows how it works. Someone who will follow it literally.

You'll find the gaps fast. The step that assumes knowledge it shouldn't. The instruction that's ambiguous in a way you didn't notice. The sequence that makes sense on paper but falls apart under real conditions.

One walkthrough will surface more issues than ten rounds of editing.

---

SOPs only work if the system supports them

Here's the uncomfortable truth: if your operations are patched together — orders in one system, prep scheduling in someone's head, delivery reconciliation in a spreadsheet that three people can edit — your SOPs will always be fighting the environment.

A procedure for logging prep waste is useless if the data has nowhere to go. A checklist for delivery receiving breaks down when the PO lives in a WhatsApp thread. Consistency at the process level requires consistency at the systems level.

This is where a lot of growing F&B businesses get stuck. They document everything they can, but the infrastructure underneath doesn't hold it together.

If that sounds like where you are, Hippo Labs builds the kind of ops systems that make SOPs stick — custom-built around your actual workflows, not retrofitted onto a generic platform. Worth a conversation if your ops are at that inflection point.

---

The short version

Write for the failure, not the objective. Keep each SOP narrow. Use plain language. Put it where the work happens. Version it properly. Test it before you ship it.

The goal isn't a well-organised folder. It's a team that doesn't need to ask.