Do you ever scroll through 14 different Google Docs trying to find that one process you know you have written down somewhere?
Have you ever worked really hard on a new SOP, only to discover that you made one years ago that you could have just updated?
Or maybe a team member has messed something up, and you discovered that they did follow an SOP…just not the right one?
I know you’ve heard so many times that you should document your processes. You probably have dozens of documents floating around in your drive from your attempts to follow that advice. Why aren’t they more helpful?
What do you DO with all those documents once you have them?
The Library vs. The Pile
In a library, you don’t just have books. You have a system for finding them.
The Dewey Decimal System. A digital card catalog. Subject sections. Keywords. Cross-references. I’m in a library as I write this, and it’s organized to within an inch of its life. You could give me any topic and I could find you a relevant book in 3 minutes (2.5 of which would be me walking through this cavernous place).
Without a strong system, you just have a pile of books. And a pile of books—no matter how valuable each individual book might be—is basically useless when you need to find something quickly.
That’s what most Google Drives (or One Drives, or what have you) look like. They become semi-organized stacks of valuable information that you struggle to navigate.
Can Titles Do All the Work?
A natural first solution is using Search, which means you need your document titles to do a lot of heavy lifting.
Let’s say you want to document your process of what to do when weather disrupts your outdoor event. You’ll want to cover communications with attendees and vendors, lightning protocols, what items to prioritize protecting, and more.
What title should you give it?
Option 1: a ridiculous title like “Weather protocol – communication, tech, lightning, tornados, wind, hail, and snow”
Option 2: a simple title like “Weather SOP”…but then your team needs to know what to type into search to find it (and you might end up with people making separate documents for different sub-sets of this topic without realizing it’s covered).
Granted, AI will help a lot with things like this, but my point remains. I’ve seen my own drive, and I’ve seen dozens of others. Things get wild fast if you rely on search by itself.
What About Folders?
Another thing we all do is create folders.
But where does our little Weather SOP live, exactly? Under Policies? Event Docs? Operations? Coordinator Docs? God forbid, under a folder for one specific event?
It’s next to impossible to set up your folders so that any given document would only make sense in ONE place. There would be a logical reason to put it in a lot of places, and what then? You find yourself digging through a few before you find it (and now you’re annoyed).
Big Manuals vs. Small Topical Documents
Another question that many of my clients wrestle with is how to batch topics. Is it better to have one big manual that covers everything, or a lot of individual docs that make Search easier?
This is a fair question no matter what system you use, but the important thing to know is this: neither path will save you from ‘pile of books’ syndrome. Without a good library system for organizing SOPs, finding information will be confusing either way.
My System: The Library Catalog Approach
Here’s what I do now, and what we implement for our clients:
1. A searchable database in a table format
The easiest way to do this is with a spreadsheet in the drive you already have (like a Google Sheet). It can be a simple table you add everything into. To start, you need a column for Name, URL, and Keywords (more on this later).
We use Notion because it’s easier to create multiple views to break the information down by category (and to add visuals). You could do something similar in a tool like Airtable. The biggest challenge with a Google Sheets-style spreadsheet is that once it gets north of 20 SOPs, people will stop wanting to look at it. It’ll work, and it’s better than nothing, but it’s worth keeping in mind.
2. Clear, simple titles Each SOP gets a straightforward name that describes the main topic – it doesn’t need to handle more than that.
If an SOP needs to be archived, we’ll add something like OLD into the title so people know not to use it if they find it outside the library (you can put it in an archive folder, but Search will still find it, and people will still use Search sometimes). Other than that, we don’t force the title to do too much.
3. A dedicated keywords section This is a game-changer. Your library needs to have a section for keywords and related terms. It’s like subject tags in a library catalog. That way, when someone searches for “hail,” they get sent straight to the Weather SOP, even though it’s not in the title.
4. Categories and types This is optional. Just like library sections help you find the Children’s area or the Biography section right off the bat, I organize my SOPs by category: Marketing, Operations, Finance, Team, etc.
I also organize my library by type: Process, Policy, Template, Resource.
If you have a lot of SOPs and/or want to create different views to see a subset of the whole library, these come in handy.
5. Bonus categories
Other columns you may want to consider are percent complete, date last reviewed, owner, and audience. It’s better to add columns as you need them than spend too much time on things you won’t use!
Individual SOPs > large manuals
Let’s return to the question of how much to put in one SOP document. The way we decide what should go into an SOP is this: if someone could be delegated a unit of work on its own, it should be its own document.
“Event planning SOP” is WAY too broad.
“How to communicate with attendees about a tornado warning” is too narrow. It’s only one step in a connected set of steps that belong together.
“Weather SOP” is just about right. If someone is in charge of handling everything that happens if the weather doesn’t cooperate, that’s a good sign the SOP should hang together. Another good sign in this example is that there’s a single triggering event for everything in it.
You can use tabs (in Google docs) and things like headers to break your SOP up into individual tasks (like communicating with attendees about a tornado warning), but you want someone to be able to open an SOP and see everything they need to see to solve a problem or complete a task.
This is less about the length of the SOP and more about how it’s used. For instance, I recently completed a single SOP that was 80 pages long. We kept it as a single SOP because it was the process of onboarding a new client (for a property management company). One person owns that process and completes it in a linear way over the course of several weeks. It all goes together.
For the same client, though, we broke up other, much shorter SOPs because they were handled by different people or were triggered by different events.
Why We Use Notion (with AI)
Tools exist that are built specifically for SOP management. They’re beautiful. You can use them to see who’s accessed which documents and test your team’s knowledge with quizzes.
They also cost $99+ per month, and for most small businesses, they’re overkill.
Here’s what Notion gives us:
- A searchable database where we can filter by category, type, owner, or status
- Customizable views so different team members can see what they need
- The ability to add guests without having to pay for a seat
- The ability to link pages within other pages to help solve for SOPs that might be relevant in a few different contexts
- Notion AI that can help us search, summarize, and even draft SOPs
It costs $20/month/user with the AI add-on. The expensive SOP tools are great if you’re a bigger company with complex compliance needs. But for most of us, simpler tools will do the trick. We also use Notion as our CRM and project management tool to get even more bang for our buck.
Editing and Locking SOPs
Another question to consider when you have a team sharing SOPs is how to handle edits. Can anyone just edit SOPs anytime? What if they mess things up?
To avoid being too much like Wikipedia where things can go off the rails with a small group of people editing at will, here’s what we suggest:
- Each SOP has a single owner with editing rights (you don’t necessarily have to make it physically impossible to edit – you can set clear expectations – but you can also lock things down in user permissions if you wish)
- SOP users are encouraged to leave feedback as a comment within an SOP if they notice a gap or addition
- Each quarter, a batch of SOPs is reviewed so any updates can be made and comments can be incorporated
The Real Win: Peace of Mind
Sitting in this library right now, it’s comforting to know I can find what I need, when I need it. I want you to feel the same way when you’re navigating all the information your business has piled up in that drive of yours.
Start small with one category of documents and SOPs you already have! You can build from there.
Cheering you on.
P.S. Want to see exactly how we structure our documentation library? Email me at hello@smoothoperator.biz and I’ll send you a tour video.
