What's the Difference Between PROCESS and SOPs?

A business process is the overall flow of how work gets done. An SOP is the detailed, step-by-step instructions for doing one specific task. You need both to run a business smoothly.
You ever find yourself just kind of mixed up between a business process and a standard operating procedure? In the world of business operations, we use these two terms a lot, but the difference between them can be a little murky. If this is something you can relate to, you are not alone inside the process driven membership. I feel like this question is probably one of our most commonly asked questions. And because these terms are pretty connected, as we'll see in a moment, it's understandable these can be a little murky. In this video though, we're going to break down the definition between a process and an SOP and go through a few examples so it can stick in your head a little bit better. Let's start off with the term process. A process is a series of steps to achieve a defined result. Basically, when we know what we're going to do to achieve an outcome, we have crafted a process. Often a process will not be a tangible thing. While we can record a process by making a process map. The most common processes we have are simply habits are ways of doing things that are never documented in any form. It's just our manner and that becomes our process. Anytime you have a set way of doing things to achieve an outcome that is predictable and repeatable, you have built a process. But where do SOPs tie in? Well, an SOP is an instruction for how to execute a process. I know, tricky, right? We've got one word, define the other word. What is this? Think of SOPs as instructions. If we know we need to walk to the mailbox, and we have a way of walking to the mailbox, that might be a process. But if we were to write out a map defining each step to get to the mailbox, we would have an sop. In other words, if we have a process that we've defined over here, and we want to make it something that other humans can understand, and we either write it down, talk about it, record it, create a video, something. We are creating an sop, a standard operating procedure, an instruction booklet. By creating these written instructions, we have taken something from being just a process that's out there floating and supported it with a standard operating procedure guide or reference file. Just to go through a few examples, let's picture this one. A process might be. Let's go to Grandma's house. We've got the name of the process reflecting the outcome we're trying to achieve. And there we go. We have Grandma's House, the instructions for how to get to Grandma's house. If anyone remembers MapQuest, you have to print out Your instructions back in the day. That's kind of what we're talking about with an SOP. For example, MapQuest instructions might say, you know, pull out of your driveway and go left, turn right on Main street, turn left on south street, and all of a sudden you've arrived. Grandma's house is on the left. Those instructions that MapQuest creates is effectively an SOP for the process of how to get to Grandma's house. It's the directions. For another example, we could think about submitting payroll. We might call it the submit payroll process because it's how we submit payroll. But just knowing how to do it is generally not enough to have somebody help us with it. Instead, we might support process of submitting payroll with an SOP called How to Submit Payroll. I know, really creative with the naming. This could look like a document, a video, or just a recorded training where we walk through how to submit payroll. For a third example, let's look at the process of preparing client contracts. Straightforward name equals an outcome. And our process would be how to prepare client contracts. Yeah, by now I think you've got the rhythm. But do not get too cozy here. Even though it's easy to think of process and SOP as similar terms that are a one to one relationship, it's not quite that simple. But before I go into why it's not that simple, let's do a quick word from our sponsor of today's video. Ooh, and just a quick productivity tip here from our sponsor of today's video who allows you to watch this video for free. Textexpander. Thanks. Textexpander. Textexpander is a software that saves you time by allowing you to have things that you type regularly available in a few keystrokes, rather than having to write out long form text. Textexpander is a great way to boost your productivity anytime you need to involve keystrokes at all. Whether that's creating a new task in your task management system, emailing a client, a standardized email structure, or even doing things like calculations. Inside my own textexpander account here at the bottom, I actually use the past and future date snippet library thingy. And basically this comes pre built with a bunch of keyboard commands. So I can do things like a week from now and have textexpander do the math and figure out that date. And in this case if I wanted to have a week ago, I would do comma D7 and it would populate the date for me. If you'd like to learn more about textexpander or check it out for yourself. Check out the link in the description below. They've got a cool little trial thing on their website that lets you test out the whole experience, and a free trial that's generous. So check that out if you're interested. I know it saved me a whole lot of time. Now, even though this is probably feeling pretty understandable right now, I don't want you to get too cozy because it's easy. Easy to think, okay, process is the outcome, SOP is the how to achieve outcome, and otherwise they're pretty much telling me similar things. If we want to expand our definitions just a little bit further to highlight some of the differences, a process being a path to a defined result is going to be generally short. It's going to focus on the path to one result, but it's generally going to be inclusive and looking out for detours in the process. Process is likely going to include variables that could come up such as, oh, you know, we are ready to prepare the client contract which services it. If service A do this, if service B do that. Forks in the road are pretty common when it comes to a process that you have in your business. If you have a process with no deviations, no forks in the road, it's a very unusual process. Almost every process you will ever map will have variations or if thens or forks in the road. Let's contrast that though with SOPs. SOPs, because they are not just flowcharts, they are very detailed. Instructions generally are also short. They follow one path to a result, and they do not usually accommodate detours. Let's compare the difference here. So just to go back to the example we talked about before of using MapQuest instructions to get to grandma's house. In that example, MapQuest is only going to show you one path to grandma's house. If you have those instructions printed out in your SOP and all of a sudden Main Street's closed, you have to go back to the drawing board and whip up another set of instructions because those original ones only show you one path. That goes for SOPs in most categories. Because we want to make SOPs be nice, short, brief and concise, you are generally only going to have one SOP per variation of the path. Let me show you some examples here. Here we have a best case scenario where we have one SOP and one process. This matches what I've been showing you in the earlier examples of this video. Typically this SOP will be called how to Whatever it is and it will outline the normal path to the outcome for simple processes, or whenever you're just getting started on documentation, this might be the only SOP you have, but that does not mean it's the only SOP you need if you really want to systemize a process. In fact, many processes in my own business here, and probably many of yours, have multiple SOPs per process. You might have one SOP for the normal situation, one SOP for how to handle a common issue, and another SOP for how to make a special variation. And all of these SOPs together equip somebody to complete the process with all the possible variations. If we only had one SOP or one set of MapQuest instructions to get to Grandma's house, we'd have some challenges. But for now let's remember that multiple SOPs can be related to one process. It is not always a one to one relationship. To show you some examples of this, just like we did before, let's picture Grandma's house, right? We might have one SOP or instruction for how to get to Grandma's house using those MapQuest instructions. And we might have another set of instructions if we want to go to Grandma's house by bike. And we might have yet another set of instructions if Main street is closed, but we still want to get to Grandma's house. All three of these SOPs are outlining paths to the same result, ways to execute the same process, but they have different variables or inputs involved with them. So depending on what your situation is, all one SOP is going to be more helpful than the other. Granted, our normal case is in the middle, but we need to be prepared for variability because even though SOPs assume situations are always perfect, reality is not so. So creating SOP variations can be very helpful. Second example, submit payroll. Remember this from before? Well, we could just have our how to submit payroll sop that could be great. But if you are like most human beings, sometimes mistakes happen. So having SOPs for zoomed in parts of this process that could get tricky can be very helpful. In this case, maybe we want an SOP for how to fix a mistake. That way when we're in the main payroll sop, if something goes wrong we could have a little PS saying hey, need to dig deeper on this, do something wrong, Go over to this other SOP to get more information on that. Having two SOPs here will allow us to not only execute the process, but be prepared in case an issue comes up. Plus on the other side here we have yet another variation where we want to focus on all off cycle payrolls. Maybe There's a special edition of the payroll that we need to be prepared for because of a termination or something else. We can have a variation of this process right here. These two SOPs could overlap or they could reference each other, such as this SOP might say, follow the normal payroll instructions and when you get to step four, come back to here for the specialty steps. Whatever is unique, we don't have to repeat ourselves, but we do want to network these together. So overall, the process of submitting payroll is super well documented. Next up, we have Prepare client contracts. Our third example, of course, we've got our normal path here of assuming everything's plain and straightforward. What do we do? And then we've got two variations over here. What happens if a client's renewing? Are there special steps we need to follow? We could have this SOP say, hey, if this is a renewal client, go over to this SOP in order to finish this process to follow specialty steps again, networking sops together to accomplish the result, to account for variations on the other side. Here we've got how to resolve a client not signing the contract, how to handle that awkward follow up in case a contract is sent off but something doesn't go as planned. Again, these SOPs are going to be networked together, meaning they're going to link, mention each other, build on each other, and avoid retyping the same information. But by having all three of them, or 10 of them, or four of them, whatever your number is, you can make sure you're prepared for every possible fork in the road in your process. Now, all that information aside, this process in system space is pretty vague. There are going to be people who have processes defined as such, huge overarching things that they're basically systems. And then there's others who will have processes so dialed in and clearly defined that you may only have one SOP per process. But on average, and in general, the layout I shared here in this video of having one process to define your outcome and your SOPs as your defined path to that or variations thereof, that's generally the healthy balance that I have found be most useful to the small teams that we work with here. There's no right or wrong about the number of processes or the number of SOPs per process. But just realizing that these are distinct things can be a really helpful tool in your own arsenal. Defining your processes and optimizing those involves looking at your process maps, examining your workflows, and asking why you do the things you do in the way that you do them. Whereas sops and optimizing them is usually not about changing the way you work at all, but looking at finer details like how do you do that work, what step are the orders in? As well as finer details like what do you name that file in step six, Section C? You know, those kinds of detail things are in the SOP piece of the equation. And when you can view these things as different terms, you can realize how different stakeholders need to be involved in optimizing each half and understand that SOPs are just one tool for equipping your processes. There are some processes out there that do not need SOPs, but yep, that's right. ProcessDriven here telling you that you don't always need an SOP. If you have a process that is not being done by a human or doesn't need a human to understand the steps of the process, skip the sop. Instead of that form of equipment, add an automation, add a template, add something else. SOPs are really only the tool we want to use if we are trying to communicate to a human brain what needs to happen in a process. If you're not talking to a human, or if you're looking for something slightly different, you're going to end up using a different form of equipment than an sop. Now, I think I probably just used the word SOP like 50 times in this video. So if you are sitting there thinking, okay, SOP is standard operating procedure. It's instructions. I get that, but I don't know which ones I actually need. I've actually got a resource for you in the description below where you can find 109 examples of what SOP topics might be relevant for you and your business. If that sounds interesting, check out the description below. And if you'd like to learn more about systemizing your process beyond just thinking about sop, you might want to watch this this way this video next. Thanks so much for watching. Thanks textexpander for sponsoring this video. Link below for that and until next time, enjoy the process.










