Most SOPs suck because they're written by someone who has never worked the shift they're describing. A working SOP is written by the person doing the job, tested on a slow day, and revised when it breaks. This playbook shows you exactly how to build one.
I've been inside a lot of bars and restaurants over the past 20 years, and I've seen the same thing play out over and over. An owner or manager disappears for a weekend, something goes sideways, and they come back Monday morning fired up. "We need SOPs." They spend a few hours writing something up. It gets printed, maybe laminated, filed in a binder near the host stand or the office printer. Within two weeks nobody looks at it again.
It's not because the staff doesn't care. It's because the document was written from memory and imagination instead of observation.
The person who wrote it has not worked that shift in years, if they ever did. They described the ideal version of the process, not the actual one. So the new bartender reads it, gets to step three, hits a situation the document doesn't cover, and improvises. Then they stop reading it because they learned it's not reliable.
The other failure mode is more subtle. Some operators write SOPs as performance. For the health inspector. For the investors. For the GM they just promoted and want to look organized in front of. The document is never meant to be used. It's meant to exist.
Neither of those is an operating document. Both are wasted hours.
An SOP that works is a different thing. It's humble. It was written by someone close to the actual work, it acknowledges that exceptions happen, and it has a date on it that tells you whether it's current. When your newest person can follow it without asking for help, it's doing its job.
A good SOP isn't long. It's complete. There's a difference.
Purpose. One or two sentences. Why does this process exist? What breaks if it doesn't happen? Keep it honest. "Because the health department requires it" is a valid purpose if that's the truth.
Scope. Who this applies to and when. Not everyone on the floor needs the opening side-work SOP. Be specific. A document that applies to everyone often gets used by no one.
Definitions. If you use any term a new hire might not know, define it. "86'd," "on the fly," "the rail" -- these mean different things in different operations. Don't assume.
Materials and tools. What does the person need before they start? List it. A bar opening checklist without a reference to where the par sheet lives is incomplete. Someone will figure it out eventually. That figuring-out is waste.
Responsibilities. Who owns each part of this process? If two people are both responsible, nobody is. Name the role, not the person. People change. Roles are more durable.
Procedure steps. This is the core. Write in second person, active voice. "Place the cutting board to the left of the station." Not "The cutting board should be placed." Each step gets a short name that starts with a verb. Keep total steps between five and nine. If you have fifteen steps, you have two or three processes jammed into one document. Split them.
Exceptions. This is the part most SOPs skip and the part that matters most on a real Tuesday night. What happens when the normal thing doesn't work? What's the call if the supplier didn't deliver? What does the bartender do if the POS goes down mid-rush? If the document is silent on exceptions, the team has to improvise, and the improvisation becomes the real procedure whether you like it or not.
Revision log. Date, who changed it, what changed. One row per revision. This is not bureaucracy. It's how you tell whether a document is alive or dead.
Optional but useful: a short Tips section for things learned from experience that don't fit neatly into a step. A short Traps section for the mistakes that keep happening. Not every SOP needs these, but they're worth adding when the institutional knowledge is real.
This is the baseline. Not your best bartender. Not your senior floor lead. The person who started last week and is still finding the supply closet.
If they can execute the process correctly the first time using only the document, it works. If they have to ask three questions to get through step two, the document isn't finished.
The fastest way to find out is to hand it to them. Watch. Don't explain. See where they pause, where they guess, where they ask. Every pause is a missing sentence.
Real operations have variance. The keg is empty. The delivery came short. The system is down. A regular is visibly intoxicated and it's only 7pm.
An SOP that only covers ideal conditions is a document for a kitchen that doesn't exist. Your team needs to know what to do when the normal path is blocked. That means your exceptions section is not optional. Write it like a person who has actually closed on a slow Monday and knows what can go sideways.
A document without a revision history is a snapshot. It was true once. It may not be true now.
The revision log is how you tell the difference between a living document and a filing artifact. If the last revision date is from eighteen months ago and you've changed your POS, your staffing model, and your menu since then, the SOP is lying to your team and they know it.
Set a review cadence when you write the document. Quarterly is usually enough for stable processes. Monthly if it's anything tied to a specific season or staff rotation. Put it in a calendar. Assign it to a role, not a person.
Pick one process. Not the whole operation. One. The thing that breaks most often, or the thing you're tired of re-explaining, or the thing that new hires consistently get wrong. Start there.
Shadow the best person doing it. Not the fastest person. The best one. Watch the whole thing without interrupting. Take notes on what they actually do, not what they're supposed to do. Those two things are often different, and the gap tells you something important.
Write the draft yourself. Not in a meeting. Not by committee. You write a rough draft based on what you observed, then bring it to the person you shadowed and ask them to read it. Ask them: "Is anything missing? Did I get the order wrong?" They will catch things. That's the point.
Test it with someone who has never done it. Hand it to a new team member or someone from a different position. Watch them work through it. See where they hesitate. Revise accordingly.
Set the review date before you file it. Before you do anything else with the finished document, write the next review date at the top. Set a calendar reminder. It takes ninety seconds and it's the thing that separates a document that ages well from one that quietly becomes fiction.
Resist the urge to document everything at once. One good SOP is worth more than twelve mediocre ones. Build the library slowly. Add a process per week if you can. Within a quarter you'll have the core of something real.
The SOP nobody reads. You can write a perfect document and still have nobody look at it. The document needs a home your team actually visits. That might be a printed binder at a specific station. It might be a digital system on a tablet near the prep area. If the document isn't accessible at the moment it's needed, it doesn't matter how good it is. Placement is not a document problem. It's a systems problem. Solve both.
The SOP that goes stale. A document that doesn't get reviewed becomes a liability. It's worse than no SOP at all, because it creates false confidence. The team thinks there's a system. The system is outdated. Mistakes happen that the current team attributes to the process, when the real problem is the document hasn't kept up with how the operation actually runs now. Review cadence is not optional.
The manager who uses SOPs as weapons. This one is harder to write about because it's a management failure, not a documentation failure. But it happens. The SOP becomes a gotcha. "It says right here you should have done X." The document becomes a paper trail instead of a training tool. When that happens, the team learns to avoid the SOPs or to perform compliance without internalizing anything. The document has to come from a place of wanting the team to succeed, not a place of wanting to be right. Your staff can tell the difference.
The team that treats SOPs as prison. Some teams push back on documented process because it feels like they're being told they don't know what they're doing. That's a real feeling, especially in a craft industry where people take pride in their judgment. The framing matters. A good SOP is scaffolding. It handles the routine so people can focus their attention on the things that actually require judgment. The best bartenders I know want documented process for the mundane parts because it frees them to be present for the guests. That framing, delivered honestly, changes the conversation.
The SOP written for the inspection, not the operation. Some bars have documents that exist purely for compliance. They don't describe the actual process. They describe the process that would satisfy a third party. Everyone in the building knows the difference. The real process lives in people's heads and in tribal knowledge that walks out the door every time someone quits. At some point that catches up with you.
How long should an SOP be?
As long as it needs to be and no longer. Most bar and restaurant SOPs run one to three pages. If you're hitting five pages, you're either documenting multiple processes in one document (split them) or you're adding explanation where you should be adding clarity. The test is the new hire test. If they can execute correctly from the document, you're done.
Who should write the SOP?
The person closest to the actual work, with input from whoever manages that area. Not the other way around. A GM writing an SOP for a process they haven't touched in two years will produce a document that your team will quietly ignore. The person doing the work knows the actual path. The manager's job is to review it, ask the hard questions, and make sure it connects to broader standards.
What format works best?
Numbered steps for procedures. Bullet lists for reference information. Short paragraphs for context. Bold the actions. Don't rely on a wall of prose. If someone is reading the SOP in the middle of a shift, they need to be able to find their place in three seconds. Format is a service to the reader.
How often should SOPs be reviewed?
Quarterly is a good default. Any time you change a tool, a supplier, a key piece of equipment, or a team role that's referenced in the document, review the document immediately. Don't wait for the quarter. Menu changes, POS changes, and staffing structure changes all create SOP debt. Pay it quickly.
What's the difference between an SOP and a checklist?
A checklist confirms that the right things happened. An SOP explains how to make them happen. A good opening checklist is often the output of a good opening SOP. Build the SOP first, then extract the checklist. Using only the checklist without the underlying procedure is what creates a team that knows what to check but doesn't know what to do when something on the list is wrong.
If you want the full SOP library built for your operation, including templates for every stage of service, pre-opening and post-service, and the systems that keep them current, that's what ASM Command at jlittrell.com is built for.
If you want more operator playbooks like this one delivered weekly, The Ops Wire is where they go first.
Jason Littrell spent 10 years behind the bar in NYC (including Death & Co) and served as USBG NYC president. He now runs his hospitality consulting firm entirely on AI. He hosts the Hospitality Strategy Lab podcast and writes The Ops Wire newsletter.
Jason