Every squadron I commanded had thick binders of Standard Operating Procedures—official documentation of how we were supposed to do everything. Most of it sat on shelves collecting dust while people did things the way they'd always done them.

Then I deployed to Iraq as the Comptroller for Office of Security Cooperation-Iraq, managing $33 billion in funds across complex programs in a combat environment. Personnel rotated every six months. New people arrived constantly. If procedures weren't documented clearly and actually usable, operations failed.

That deployment taught me the difference between SOPs that exist and SOPs that get used. The difference isn't about how official they look or how comprehensive they are. It's about whether they're actually useful to the people doing the work.

Most business SOPs fail the usefulness test. They're written to satisfy some compliance requirement or because a consultant said you should have them. But nobody actually uses them to do their job. That's a waste of effort and a missed opportunity.

Let me show you how to write SOPs that people actually follow.

Why Most SOPs Fail

Before we talk about what works, let's understand why most SOPs don't.

Too Long: A 40-page procedure manual for a task that takes 15 minutes doesn't get read. People want quick reference, not novels.

Too Generic: SOPs written by consultants who don't understand your actual process are filled with generic business-speak that doesn't match reality. "Ensure proper authorization protocols" means nothing. "Get approval from Sarah in Finance" is actionable.

Too Old: SOPs written three years ago for systems or processes that have since changed. People ignore them because following them literally would be wrong.

Too Formal: Written in stilted corporate language that nobody actually talks in. "Personnel shall endeavor to ascertain..." Just say "Check whether..."

Not Accessible: Stored in some shared drive folder that nobody can find without searching for ten minutes. Or worse, in a binder in someone's office.

No Pictures: Complex procedures described entirely in text with no diagrams, screenshots, or flowcharts. People are visual. Text-only SOPs don't work for procedural work.

The result: People learn procedures informally from whoever trained them. Those procedures drift over time. Errors accumulate. When someone leaves, institutional knowledge walks out the door.

The Military SOP Philosophy

Military operations depend on SOPs that actually work. When you're managing a 140-person squadron with constant personnel turnover, you can't rely on institutional memory. Everything has to be documented so the new person can pick it up and execute.

The principles that make military SOPs effective:

Task-Focused: Each SOP covers one task or process. Not "all accounting procedures"—that's a tome. Instead: "Month-End Close Procedure," "Invoice Approval Process," "Bank Reconciliation Steps." One task, one document.

Action-Oriented: Written in imperative voice with numbered steps. "Do this, then this, then this." Not "The process involves..." but "Step 1: Open the system. Step 2: Navigate to..."

Visually Supported: Screenshots, flowcharts, decision trees. Show, don't just tell.

Maintained: SOPs have owners responsible for keeping them current. When the process changes, the SOP gets updated within one week. Stale documentation is worse than no documentation.

Accessible: Stored where people actually work. If the team uses a specific system, the SOP is linked in that system. If they work from an intranet, SOPs are prominent on the intranet homepage.

Tested: Before finalizing an SOP, someone who didn't write it tries to follow it. If they can't complete the task using only the SOP, it's not done.

The Structure That Works

Effective SOPs follow a consistent structure. People learn the pattern and know where to find information quickly.

Standard SOP Template:

1. Header (Top of page):

  • Process name
  • Owner (who's responsible for keeping this current)
  • Last updated date
  • Frequency (how often this process occurs)
  • Estimated time (how long this takes)

2. Purpose (2-3 sentences):
Why we do this. What objective it serves. This provides context for people who need to understand the "why," not just the "how."

3. Roles and Responsibilities (bullet list):
Who does what. Be specific. "Finance Manager approves transactions over $5,000. Department heads approve under $5,000."

4. Prerequisites (if applicable):
What needs to be in place before starting this procedure. Required access, systems, information, approvals.

5. Procedure (numbered steps):
Step-by-step instructions. This is the core content. Write it clearly.

6. Common Issues and Troubleshooting:
What goes wrong frequently and how to fix it. This saves massive time and prevents people from bothering experts for common problems.

7. Related Procedures:
Links to related SOPs. "After completing this process, proceed to [Month-End Close Checklist]."

8. Revision History (at bottom):
Date, person who updated, summary of changes. Helps people understand what's new if they used an older version.

This structure should be identical across all your SOPs. Consistency reduces cognitive load.

Writing the Procedure Steps

The procedure section is where most SOPs go wrong. Here's how to write steps that people can actually follow.

Use Numbered Steps: Not bullets, not paragraphs—numbered steps. "1. Do this. 2. Then do this. 3. Then do this."

One Action Per Step: Don't combine multiple actions in one step. "Log into the system and navigate to the reports module and select the month-end report" should be three steps, not one.

Start with a Verb: "Open the file. Click the button. Enter the data. Review the results." Action-oriented language.

Be Specific: "Click the Submit button in the lower right corner" beats "Submit the form." "Enter invoice date in MM/DD/YYYY format" beats "Enter the date."

Include Screenshots: For any system-based procedure, screenshots are essential. Mark up screenshots with numbered circles or arrows showing where to click or what to enter.

Handle Conditional Logic Clearly: When there are decision points, use clear if/then structure:

"5. Check the transaction amount:
   • If under $5,000: Proceed to step 6
   • If $5,000-$25,000: Get department head approval (see Appendix A), then proceed to step 6
   • If over $25,000: Get CFO approval (see Appendix B), then proceed to step 6"

Number Sub-Steps Appropriately: Use 1, 2, 3 for main steps. Use 3a, 3b, 3c for sub-steps within a main step. This preserves reference clarity.

The One-Page Rule

During my time managing an $11 billion accounting database at Peterson AFB, I learned that if a procedure couldn't fit on one page (or two pages maximum for complex processes), it was too long to be used effectively.

The one-page rule forces clarity:

  • Eliminate unnecessary words
  • Focus on essential steps only
  • Use visual elements efficiently
  • Relegate detailed information to appendices

If your procedure is running four pages, you're either including too much detail or you're documenting multiple procedures. Break it up.

Use appendices for:

  • Detailed reference information (account codes, approval limits, contact lists)
  • Background information (regulatory requirements, system architecture)
  • Examples and templates
  • Troubleshooting details for rare problems

The main procedure should be quick reference. Appendices are for when you need more depth.

The Visual Enhancement

Text-only procedures fail for procedural tasks. Add visual elements that actually help.

Flowcharts: For procedures with decision points or multiple paths, flowcharts beat numbered steps. People can see the logic flow at a glance.

Screenshots: For any software-based procedure, screenshots with annotations (arrows, circles, numbering) guide users visually. Update screenshots when the system changes.

Checklists: For procedures that require verification or multiple parallel tasks, format as a checklist people can print and mark off.

Tables: For information that has multiple attributes (approval limits by transaction type, processing timelines by scenario), tables communicate more clearly than paragraphs.

Before/After Examples: Show what correct output looks like. "The reconciliation should look like this" with a sample image beats describing what it should look like.

Don't make SOPs pretty for the sake of design. Make them visual for the sake of clarity.

The Maintenance System

SOPs decay rapidly without systematic maintenance. Processes change, systems update, people learn better ways to do things. If SOPs don't evolve, they become obsolete.

Implement these maintenance practices:

Assign Owners: Every SOP has a named owner responsible for keeping it current. Not "the finance team"—an actual person. That person's performance evaluation includes maintaining their SOPs.

Trigger-Based Updates: When certain events occur, SOPs must be reviewed and updated if necessary:

  • System upgrades or changes
  • Process improvements implemented
  • Regulatory changes affecting the procedure
  • Persistent problems indicating the procedure needs clarification

Quarterly Review Cycle: Even if nothing has changed, every SOP gets reviewed quarterly by its owner. Quick check: Is this still accurate and complete?

User Feedback Mechanism: Make it easy for people following SOPs to flag issues. "Didn't work as written" or "Step 7 is unclear" feedback should go directly to the SOP owner.

Version Control: Every update creates a new version. Track revision history. This lets you rollback if a change causes problems and helps people understand what's new.

Maintenance isn't optional. It's the difference between useful SOPs and useless documentation.

The Accessibility Principle

SOPs buried in shared drives don't get used. Make them accessible at the point of need.

Put SOPs where people work:

  • In the system: If you have an accounting system, embed links to relevant SOPs within the system itself. Context-sensitive help.
  • On the intranet: Prominent location, organized by department and function. Search functionality so people can find procedures quickly.
  • QR codes: For physical processes (receiving shipments, equipment operation), post QR codes that link to digital SOPs. Scan with phone, access procedure immediately.
  • New hire onboarding materials: Provide new employees with links to all SOPs relevant to their role on day one.
  • Training materials: When training people on a process, give them the SOP. The training reinforces the SOP; the SOP reinforces the training.

Accessibility isn't about having SOPs available somewhere. It's about making SOPs immediately available exactly when someone needs them.

The Testing Requirement

Before declaring an SOP complete, test it.

The testing process:

1. Expert Review: Someone who knows the process reviews the draft SOP for accuracy and completeness.

2. Peer Review: Someone at similar skill level but who didn't write the SOP follows it and provides feedback on clarity.

3. Novice Test: Ideally, someone new to the task tries to complete it using only the SOP. This is the ultimate test—if a reasonably intelligent person who's never done the task can follow the SOP successfully, it works.

This testing reveals gaps in logic, unclear instructions, missing steps, and incorrect assumptions. Fix these before publishing the SOP.

The Training Integration

SOPs and training should reinforce each other, not exist separately.

Training sessions: Walk through the SOP step by step. Show people where to find it, how to use it. Demonstrate each step while people follow along in the SOP.

Practice exercises: Have trainees complete the process using the SOP while you observe. Identify where they struggle—that's where the SOP needs improvement.

Certification: For critical procedures, require people to demonstrate competency by successfully completing the task using the SOP before being certified to do it independently.

Refresher training: When SOPs are significantly updated, conduct refresher training. Don't assume people will notice and adapt on their own.

The goal: Nobody should perform a procedure significantly differently from the SOP. If they are, either they're doing it wrong or the SOP is wrong. Either way, something needs to change.

The Quality Through Standardization

The real value of SOPs isn't documentation for its own sake. It's quality through standardization.

When everyone follows the same procedure:

  • Quality improves: The best practices get encoded and consistently applied
  • Training accelerates: New people learn the right way from day one
  • Errors decrease: Common mistakes get eliminated through process design
  • Efficiency increases: No wasted time figuring out how to do things
  • Knowledge persists: People can leave without taking critical knowledge with them
  • Improvement accelerates: When you improve a process, you update one SOP and everyone benefits immediately

This is how the military achieves consistent operations despite constant personnel turnover. The standards are documented, maintained, trained, and followed.

The Bottom Line

After 20 years managing military operations and now working with civilian businesses, I've seen both extremes: organizations with no documentation (chaos when people leave) and organizations with beautiful documentation nobody uses (wasted effort).

The goal is the middle: Simple, clear, useful SOPs that people actually follow because following them makes their jobs easier.

Write SOPs from the user's perspective. Keep them short and visual. Test them with real users. Maintain them obsessively. Make them accessible at the point of need.

Don't write SOPs to check a compliance box or because consultants said you should. Write them because standardized, documented procedures improve quality, speed, and resilience.

Start with your most critical 5-10 processes. Document them well. Build the discipline of maintaining them. Then expand from there.

Within a year, you'll have SOPs that actually get used. And that's when you'll see the real benefit: consistent quality, faster training, and institutional knowledge that survives personnel changes.

That's not bureaucracy. That's operational excellence.

—Gabriel Denny is a retired Air Force Major and fractional CFO who helps businesses build operational discipline through effective documentation. Learn more at gabrieldenny.com.