How NOT to Write Standard Operating Procedures (SOPs)

So you've finally decided to take the time to write your standard operating procedures down. Those SOPs are going to define what your business does if you are writing them. That sounds like an awesome thing. Unless you're writing them in the wrong way. Yeah. Here on the ProcessDriven YouTube channel we talk all the time about systems, processes and the tools you need to make it happen. But today I want to do a quick tip video talking about some of the things you want to avoid and don't want to have happen when it comes to writing standard operating procedures for your team. The first mistake feels a little bit goofy coming from a YouTuber, but using video is the first mistake and the most common mistake I see folks do now. Don't get me wrong, video is great. Obviously we like it here at ProcessDriven. But creating your SOPs entirely in video in is often a mistake. The reason being is when you record a video to describe the entirety of a process and that is the only tool you have as your sop. If someone needs to reference that video in the future, they need to watch an entire video with no timestamps, no transcription, no subtitles, and they just need to scroll through a 15 minute video to find that one detail they needed out of the SOP. Despite how great videos are, they're hard to skim and reference later, which is why Buzzfeed are articles are written articles and not long form YouTube videos. It's why we make blog post versions of our videos which you can find in the description instead of just videos. For the same reason, writing all of your recipes as one big old video is a mistake. Not only is it hard to navigate and find the information you need, it's also hard to update inevitably when a step of your process changes. I make videos here for a living at ProcessDriven, and if you told me I had to refilm a video every day, every time a step in my process change, I'll tell you what happens. I just won't update it and we will have outdated video sops that no one ever uses because they're outdated because it's too much work to edit them. Save yourself the hassle. Do not create long form videos as your SOPs. For example, if this was my SOP here, it might be helpful for me to have it a video inside step one showing me how to do just step one that's small enough that it's easy to skim and easy to update. But I don't want to be in a situation where this entire SOP is just One big video. It's just a headache for later on. That brings me to the second mistake when it comes to writing SOPS, which is having your SOPS written by the wrong person. At ProcessDriven, we believe in a bottom up approach to systemization, meaning it's not something that the business owner or the C suite or the managers are dictating down on everyone else. The biggest challenge we see with systemization in business is people not using it. More than anything else, people don't use the SOPs, the resources, the templates. And why is that? Because they're often top down prescriptions. Just go back to being a kid again and your parents tell you you must eat your vegetables. How many of us are going to eat our vegetables because our parents tell us to? If anything, we'll become resistant to it because it's being dictated upon us. Instead, let's have our team members part of the process of systemizing. And when it comes to SOPs, the people writing the SOPs or creating any other form of equipment should be the people who will use those SOPs. Does that mean other people can't review them or quality control them or make them better over time? Absolutely not. But the authors need to be the people who are going to use them to solve the adoption issue that so often stumps systemization. For more information on that one, you can watch this video up above where I explain in greater detail why the business owner specifically is kind of the worst person to write SOPs. Creating SOPs thinking that they're going to be perfect forever, which kind of ties into mistake number one, is an issue. And one way this manifests is when you create SOPs that are not accessible and editable by the people who need to use them. It should be extremely easy for me to go into your business, find an sop, catch an error, and fix it. If I need to go through multiple intermediaries, if I need to ask permission to leave a comment to get an update potentially made, the odds of me actually giving that feedback goes way down. And if we want to have that bottom up approach to SOPs, where we have the people doing the work, actively teaching us how to best operate that little function of our business that they are the master of, then we need to make this process of updating extremely easy. Otherwise it simply won't happen and we'll have SOPs that were written once, never updated, and again are not trustworthy and are not referenced. The easiest fix for this is whenever you identify your tool of choice for collecting your SOPs, whether that's a Google Doc, your click account, your SmartSuite account, something else. Whatever it is, make sure you allow at least commenting access, preferably suggestion access for your entire team. Doesn't matter if it's not the person doing the process. I want everybody on your team be able to point out opportunities to make things better. If you keep things as view only or accessible only to the elite few, you're essentially saying you don't want your business to improve, you don't want your organization to do better. You don't want ideas that'll make the process more efficient. I know that's not true. You know that's not true. So let's make sure our software infrastructure reflects that value. Oh, and by the way, before we go into our next tip, if you would like to learn a little bit more about standard operating procedures and how to figure out when you need them in your business, how to systemize your business overall. Like what does that journey look like? Check out the free training we have in the description below where I go through our overall approach to systemizing any business. Whether you work with us or not, you can figure out how to kind of dive into this overwhelming topic of systemizing my entire business in a way that's fun and even a little bit like a game. More information around that found in the description below. But with that, let's go back to the video for our fourth quick mistake when it comes to writing standard operating procedures. I'm talking about writing standard operating procedures as if we're in the 1900s and people read standard operating procedures. Now, I know this might run counter to my first point where I said write things down, don't make videos. But we still live in a universe where our attention spans are getting shorter and shorter. And if you are working on a team of people who are proficient at their job, you probably don't want them to spend 30 minutes reading an SOP on how to do a 5 minute task, right? So given people's attention spans and your desire for efficiency, it makes sense for us to build SOP template structures that are built with skimming in mind. And yet so many folks when they write SOPs, they write out these long novels, these 12 page Google Docs that who wants to scroll through? They've got giant images and blurry things and long paragraphs. I don't want to read that. You don't want to read that. We do not need ISO work instructions for most of our business functions unless you are an ISO certified business. And so for our normal businesses out There. Let's keep things light, let's keep things reading like a buzzfeed article and easy to digest and find what we need, making all that we possibly can around sections and searchability and keywords and bold faces and make our styling of our SOP conducive to finding information quickly. There are a number of things we can do to make our SOPs more skimmable, including using a software like we talked about in step number three, which could make all that stuff easier too. But there's one go to step one go to tip that I think really makes the biggest difference and that's making sure you have numerical headers that are the title of sub results. Now that is not the most eloquent way for me to say this, so let me just show you here we have an example of an SOP that the team drafted today. They don't know I'm showing this on the screen and candidly I have now butchered their SOP to be a bad example. It actually wasn't. Sorry team, but here is an example of an SOP where we have a procedure section. It's using the SOP template we talk about in this video where I go through an example SOP structure you might find useful. Here is what is not good about this SOP right here. Do you see the issue with this procedure? There were two issues with this number. One is that we don't have numerical headers even if it takes us a second. Adding step one, step two, step three immediately makes this more digestible. The second issue I have with this is that each toggle each section, each step is not a clear result. When I am writing a clear sop, I want to know how I know that that step is perfectly done. This very first step, for example, tells me to pull up everything I need. If I just read that header as if I was skimming, do I understand what everything I need is pull up? Am I physically pulling things up? Am I opening tabs? I'm confused. And that is not necessarily the indicator of a good step one. And again, I wrote this. I'm not blaming the team. Contrast that with step two that the team actually wrote. Step two says verify that any upcoming holidays reflect from gusto in the Google Calendar. So it's talking about our HR management tool, which is an amazing software by the way. We'll put the affiliate link below and talking about that we're cross referencing it with our Google Calendar. I know even without opening that, what result tells me I finished that step perfectly. It's very Clear. I know whether or not I need to open that toggle because I know whether or not I achieve that result. That is what we want. We want to have sequential numbering such as step two, and we want a title of the step that lets me know clearly by skimming it whether or not I need to toggle open that to achieve that result or not. So in this case, I know I can verify that, so I don't need to toggle it open. And I also know if I can't verify it, which tells me I need to toggle it open and see the additional information tucked inside. That is really important because we don't want to give people false confidence because sure, I've pulled up everything, I need my cup of coffee. But at the same time, we want to make sure that we're keeping things very brief. Now, I mentioned that I butchered the team's actual SOP in order to use that example. So let's go to their actual SOP and let me show you the difference. Here we have the actual SOP the team had written, and this is just a rough draft. So I'm not judging anything, but do you see how this first step is very clear in what I need to have pulled up. If I see this and I do not know how to open up this calendar in Google Calendar, I know to toggle this open and find more info. However, if I understand how to pull up Gusto Calendar, I know I can skip expanding that section, making it very easy to skim. We also see bold faced formatting here and the ability to see sequentially what step we are doing this allows us to reference steps. So for example, in step five, we might say if you see an error, go back to step three. That's great. And we also again, get that beautiful ability to know whether or not we need to dig deeper, whether I need to open that toggle or whether I'm good to keep going. Building our SOPs for speed and ease of retrieval of information is amazing. But the common mistake is that we flip the script. We focus on making it so easy to create SOPs, and then it's such a pain in the butt to actually use the SOPs, and which is totally backwards and undermines our entire mission around systemizing, especially considering you create the SOP once and in theory you use it dozens of times. So why wouldn't we make it easier those dozens of times Right now that was number four. What is our fifth and final mistake that we see around SOPS? Well, I'm gonna be that annoying YouTuber and do this because this video is the next one you wanna watch. Our fifth and final mistake is writing SOPs before you hire as if it's a prerequisite. You think that that's the case, but in reality it is not. Watch that video to find out why. Oh, and if you enjoyed this special, shorter edition of the channel, please do let me know below. Be sure to like and subscribe, and until next time, enjoy the process.