How To Write A Standard Operating Procedure (SOP)

David Jenyns walks through capturing how your team actually does things, then turning those recordings into written procedures. He runs a summit with experts, has someone transcribe the steps, and refines them until anyone can follow them without asking questions.
Chapters
So this planted an idea in my head, right? I thought, oh, this is a pretty good idea. The solutions are already out there. People already know how to do it. So I thought, how can I batch this? I always think, and you'll learn about positive constraints later. How can I do something that that forces me to get the outcome that I want and I pass the point of no return? Kind of like running a workshop here. Do you think having a workshop, knowing that 50 people are going to be turning up in the room, didn't force me to make sure that this presentation and everything was super polished and it was a line in the sand? So I look for where I can these positive constraints that force me to do something. And I decided to run the Business System Summit. I know that's how Michael got to know. And some people may or may not have seen this. Basically, I recognize that business is just a collection of systems. And if I could identify experts in the different departments in their business. And the brief to the speakers was basically, I want you to share a system or a process that you use within your business that solves a specific problem. And I picked all of the speakers you can see sales, marketing, client fulfillment, human resources, and basically put on a summit. It started at 30, very quickly ballooned to 40 experts. Each expert was sharing a system that they use in their business to solve a specific problem from their department. I then recorded the interview with them, and then we did the extraction. So I gave it to my team, got them to document it, and turned it into systems and processes. So there was the knowledgeable person who knew how to do it, and then there was the extractor. The end of it was the people who attended the workshop got 40 documented systems that they could swipe and deploy in their business and that were already three quarters of the way there. Take the system, customize it, make it your own. Once you identify your critical client flow, you know which pieces are missing, and some of the systems we'll talk a little bit later about for scale. You then start to build your business together like LEGO pieces. And you kind of think about, what is the missing piece here, where can I go to get that knowledge? And then what's the easiest way we can extract it? So that's kind of really what informed me and moved me along to this idea. The big insight is that there are two people in this process. There's the knowledge worker, it's the person who does the task, and then there's the extractor. You've already identified your primary owner and your secondary owner. On your sheet. That's what we did a little bit earlier before or at least your primary owner, who that knowledge worker is. We just now need to make this as easy as we can for them. They're busy, they don't have time. And it's a four step process. There's a lot of systems in here. It's the system for system and you'll find it inside your book here. But the steps we'll go through is the pre extraction. How do you prep the person on what they're about to do? Like you want them to do a little bit of pre thinking just so they've got the logins or whatever they need for the particular task. We then record it. The recording could happen. Screen flow, it could be Handicam, it could be Kane, who I'll get to jump up a little bit later. He works in a company where they, it's called Portavac and they clean the gutters of people's houses when leaves and stuff come in. So part of that process, there are field workers that go out into the field and hop up on the roofs and do all that they need to. So in about a week or two we're going to put a GoPro on Kane and send him out into the field with one of the field workers and he's just going to walk behind the field worker and record it actually happening. The key is you capture it as it's happening. You don't look to over optimize it, you just kind of record it. That's what the record is. Sometimes if it's on the phone, you might put a mobile phone next to the person who's on the phone and record them taking the incoming call. You just capture it and then that is a great way to then go to the documenter who can then extract what's actually happening. Then we document it, which is a separate person. And everybody likes to edit. No one likes to write from scratch. So we can then do the extraction, give it to a documenter, they document it and then it goes back to the person who did the task and then they review it. Cool. Okay. So you've had a chance to do one of the pre extraction forms. The key is the people already know how to do the thing anyway. If you've identified the right person. You just want to make sure that we avoid the deer in the headlight situation. Oh my God, I'm being recorded. And then sometimes some people really struggle. You just capture them doing it. And what the extractor does is they ask the questions as far as that wasn't clear. Why did you do this? Why did you click there? Kane and I have been doing a bit of work at the moment. We got Christie on the other day and she's been doing this particular step in the CCF for years. So she'll just whip through it and fly. And she's clicking here and clicking there and I'm like, oh, what are we doing there? Why are we clicking there? That's what the extractor does to try and just make sure that you capture what is done and ask the right questions. So there is a little bit of a skill there that will develop over time, but that's what you're looking at doing. You think objectively as a person who's never done this task, I might understand the broad concepts of it, but if I was to do this and try and replicate it, what would I need to know or do? So you just have to be the extractor, has to be someone who's curious in nature and someone who likes to learn and understand the way that lots of things work together. I find great extractors return to work. Mum or dads who are ex corporate coming back into life, they've got all that heavy training, they understand business. Sometimes at a bigger level, they work incredibly well. The other ones that work well is ex military. So if you find someone who's been in the army, reserves or something like that, and then they're coming back, that they can work really well as documenters because that's what they do and that's what they're trained for. So we just need to think about then recording it. So again, you just capture it in wherever it's happening with whatever mode that could be screen capture, video. I'll show you. We do stuff through Zoom. Sometimes I'll do stuff through screen Flow. I think another one Snagit, if you're on PC, I think that works on both using the iPhone, get a GoPro digital SLR. Just whatever. You just record the thing happening and make it as easy for the person as possible. Then you move to the documentation and on page number 15 you can have a flip. That's the system for creating systems. So it shows, you identify who knows how to do this thing, figure out how we're going to extract it. And there's two versions of that system for creating systems. You'll see version one is very simple, just the main bullet points. You flip a few more pages in and then I've got a much more detailed expanded version of the system for creating systems. And the reason I gave you the two as well when it comes to documentation is to understand that you might look at one of my completed systems and go, oh, wow, there's so much detail there. There's so much work here on the left here. This is version one. Systems might start as simple as this, just the main bullet points, and then over time you evolve it and you add extra detail. When you go to train someone, they might have a question. You get the person to go back and tweak the system and improve it so the question gets answered in the system again. We just want to make sure that the on ramp to getting this done is really low. I'm trying to set the bar for you, so low bullet points is fine if that's where you want to start. You just have to start the process. The first time you write a system or get a system written, that is the worst it'll ever be. It's kind of like every time it will get better and better and better and better. The structure. I try and keep it relatively simple. Like, I'm thinking you've got an overview at the top which explains what the system is about. Sometimes I put a flowchart. I'm not a huge fan of flowcharts. Occasionally I'll put it in. It depends on the task. Like if it's a very complex system that's got a lot of moving parts, sometimes a flowchart will just connect with the reader in a different way. They kind of get an overview. Don't start with the flowchart first, though. Start with the steps written down because they'll change and adjust and things like that. You've got the steps, which is usually you've got the main step and then you might have some detail underneath those steps. And then you'll have any supporting videos, documentation, email templates. And at the end, when I show you the optimize, I'll hop into Melbourne SEO services. I've got all the tabs open. We'll have a look in my asana. I'll show you the email templates. I'll show you. I just have to be really careful. I don't want to. Not that we're McDonald's, but we've been doing systems for a while, so our systems will be quite well evolved. If you're just starting out, I don't want you to look at it and then get the deer in the headlights thinking, oh, shit, I have to start there. Whereas you don't. You start very simply, just like that. That's enough to get you moving and then the review process. And usually that's when more detail comes in. So there's always a secondary person. As we talked about, you've got the primary owner. You've got the secondary owner. The secondary owner. Actually, that's the other thing to mention with regards to the documenter. This can. Oftentimes it's a different person. It'll be the, the extractor and the documenter can be the same person or it can be even different. At this point, you've just got a recording of the task getting done. You want to get that recording now to someone who is going to do the documentation, who is not the knowledgeable worker. That's the hack. That's the way to break through and get team members to document things where they've previously struggled is just have someone else do the documentation for them. Like that's the breakthrough there. And then you just get them to review it. Usually the primary owner then will get the secondary owner to do it. So I'll say, great, now you do the particular task, you let me know where you get stuck. So Sally writes out a system for invoicing and then we say, all right, Gillian, can you run through the system now and then see if you can follow it? And then Sally knows if Gillian has questions, oh, wow, there must be a hole in the system. We've got to plug that piece. And it's always good to have two people in your business. That's that you want to avoid single person dependency. Like the business owner is usually the worst single person dependent. But often it happens with staff as well. And that happens oftentimes as well. Where you think, hey, if I'm going to have to make up a name because I don't want any of my team to get hit by a bus, but let's say Jane got hit by a bus. And if Jane had all of that IP on her particular role and it wasn't documented, now no one knows how to do that thing. You need someone to be able to step in and do it because the business machine must keep functioning.
More from David

Remember me? Subscribe To My Channel For More Free Business Systems Content 📈









