How to Write an SOP That People Actually Follow
The Problem Nobody Talks About
Most SOPs in commercial real estate are either never written, never read, or both.
You've seen them. A 12-page Word document buried in a shared drive that nobody touches until something breaks. Or worse - the SOP exists entirely in one person's head, and they just gave their two weeks notice.
This isn't an organization problem. It's a design problem.
SOPs fail before they're even tested - not because people don't care, but because most SOPs are written for the writer, not the reader. They're too long, too vague, and stored somewhere nobody can find them when it actually matters.
The good news: this is completely fixable. Here's how to build an SOP that actually gets used.
Why Most SOPs Fail
Before you write a single word, understand the failure modes.
Written for the writer, not the reader - the person who created it already knows the process, so they skip the parts that seem obvious. To everyone else, those are the parts that matter most.
Too long, too vague - a huge document is not an SOP. It's a burden. Nobody reads it under pressure. Nobody updates it, so nobody trusts it.
No ownership - if a department owns the SOP and nobody specific does, nobody owns it. It drifts out of date and becomes the thing everyone knows is wrong but nobody fixes.
Stored where nobody looks - buried in a shared drive folder that hasn't been opened in years is not a filing strategy. It's avoidance.
No decision points - real operations involve judgment calls. An SOP that doesn't account for "if this, then that" situations leaves leaders stranded exactly when they need guidance most.
Treated as a one-time project - SOPs are living documents. If they're written once and never revisited, they become wrong, then become irrelevant, then become dangerous.
The real cost of all this: tribal knowledge. Every year, experienced leaders retire, transfer, or move on and their institutional knowledge walks out with them. The building keeps running, but nobody knows why certain decisions get made the way they do. The next failure is just a matter of time.
Three Questions Before You Write Anything
Not everything needs an SOP. Writing one for every task creates noise that buries the documents that actually matter. Before you start, ask three questions:
Does this happen more than once? If it's a one-time situation, handle it case by case. If it recurs, document it.
Does failure here cost real money, safety, or tenant relationships? High-consequence procedures get documented first. Low-consequence tasks can wait.
Could a new person execute this without asking for help? If the answer is no, you have a knowledge dependency and a risk. An SOP eliminates it.
If you answer yes to all three, write the SOP. If not, your time might be better spent elsewhere.
The Five-Part SOP Structure
Every SOP that actually gets used shares the same anatomy. Keep it tight. Keep it clear.
1. Purpose
One sentence. Why does this procedure exist? What problem does it solve? What risk does it prevent? If you can't write the purpose in one sentence, you don't understand the procedure well enough to document it yet.
Example: "This procedure ensures consistent after-hours emergency response that protects tenant safety, limits building liability, and keeps ownership informed without delay."
2. Scope
Who uses this, in what situations, and for which properties or buildings. Define the boundaries so people know when to apply it and when not to.
Example: "Applies to all property management staff at [Building Name] when responding to after-hours tenant calls classified as emergencies."
3. Steps
Numbered. Action-verb driven. Appropriate amount of pages for the documents topic. This is where most SOPs go wrong - they describe the process instead of directing the person executing it. Every step should start with a verb and tell the reader exactly what to do.
Wrong: "Tenants should be contacted and informed of the situation."
Right: "Call the tenant at the number listed in their lease file. Confirm the nature of the emergency. State your estimated response time."
4. Decision Points
This is what separates a usable SOP from an academic exercise. Real operations involve forks in the road. Build them directly into the procedure.
Format: "If [condition], do [action]. If [different condition], do [different action]."
Example: "If the tenant reports active water flow, proceed to Step 7: Emergency Shutdown. If the tenant reports water damage with no active source, proceed to Step 9: Damage Assessment."
5. Resources
Contacts, forms, keys, access codes, vendor numbers - everything the person executing the procedure needs, listed at the bottom. Not in a separate document. Not in someone's email. Right there.
If someone has to stop and search for another resource in the middle of an emergency, your SOP failed.
The Formats That Actually Get Used
Not every procedure needs the same format. Match the format to how the procedure gets used.
One-page checklist - best for recurring tasks: inspections, seasonal prep, monthly reports, fire drills. Sequential, checkbox-driven, can be printed and carried.
Decision tree - best for emergencies: water loss, power outage, security incident, medical emergency. Branches based on conditions. Can be laminated and posted.
Process flow- best for onboarding, vendor setup, tenant move-in, lease administration. Shows how a process moves through multiple people or departments.
Communication template - best for ownership reporting, capital requests, incident summaries. Pre-built structure that ensures nothing gets left out under pressure.
Where to Store It So It Gets Found
The best-written SOP is worthless if nobody can find it.
Shared drive structure - organize by situation, not by department or date. "Emergency Response" should be a top-level folder, not buried three levels deep inside "Operations > Documentation > 2023 > Q3."
Physical binders - for emergencies and critical building procedures. Paper doesn't need wifi. Keep one in the management office, one in the mechanical room, one in the security desk.
QR codes posted on-site - in mechanical rooms, at elevator banks, near fire panels. A QR code linking to the relevant SOP means the person who needs it can find it exactly where they need it.
The test - if someone unfamiliar with your filing system can't find any SOP in a couple minutes, your system isn't working.
Keeping It Alive
A document that doesn't get updated isn't a living document - it's a liability.
Assign an owner to every SOP - not a department, a specific person. That person is responsible for keeping it current, testing it, and updating it when processes change.
Annual review minimum - build it into your operations calendar. Every SOP gets reviewed once a year. Any SOP involved in a significant incident gets reviewed immediately after.
The drill test - the best way to find gaps in an SOP is to run it cold. Give it to someone who has never seen it and ask them to execute. Every place they hesitate or ask a question is a gap that needs to be filled.
Update when they fail - when a procedure doesn't work as written, that's not a failure. That's data. Fix the SOP before the next incident.
The goal of documentation isn't job security through complexity. It's to replace yourself with a system - so that your building continues to operate at the same standard whether you're there or not. That's not weakness. That's what advancement looks like.
Start Here
You don't build an SOP library overnight. You build it one document at a time, starting with the highest-consequence procedures you have.
This week: identify the single procedure in your building that exists only in someone's head right now. Write the SOP. Test it. Then build the next one.
Knowledge in your head is a single point of failure. Knowledge in a documented system scales infinitely.
The library you build today becomes the foundation the next leader inherits.
What's the one procedure in your building that would be lost if your most experienced person left tomorrow? Drop it in the comments and tell us if you've already documented it.
