How Much Detail Do You Need?

How much detail should you be putting into your business systems?

There are times when you’ll need more detailed systems and other times when you won’t need much detail at all. And there are a lot of things to consider when you think about how detailed your systems should be, things like:

➡️ Who’s doing the task?
➡️ What level of skill do they have?
➡️ Are they internal or a contractor? 
➡️ What is the attrition rate?

So how do we determine the level of detail to put into our systems? How do we approach this?

The trick is to start small and develop them into bigger systems over time, don’t try to document every little thing first. You might start with something as small as a short video and a title. Then over time, you and your team can add refinements like an overview, bulleted lists, detailed steps, workflows, and diagrams. 

Watch this video as David Jenyns explains the most efficient approach to building business systems without wasting time overcomplicating them.

Timestamps:

00:15 – What to consider when creating business systems
00:58 – How much detail do you have to go into
1:15 – An example of the level of detail to put into a system
2:42 – Considerations for lower-skilled or new workers
3:20 – Level of detail matrix explained
4:47 – What a fully detailed system looks like
5:00 – Examples of systems with a high level of detail
5:40 – Grab your copy of SYSTEMology today.

Transcription:

I wanted to answer the question about the level of detail you should be going to when documenting your systems, processes, and standard operating procedures. Now, there’s a few considerations, some systems will need more detail, and other systems are going to need less detail. Some of the things I think about first are who’s going to be completing this task? What level of skill does that team member have? Are they an internal team member or an external team member? And oftentimes probably one of the most frequent questions I’ll ask is how likely am I going to be to need to train a new team member to do this task? Like, how frequently is this a task that a team member might start with when they join our organisation, but ultimately pass the responsibility of that task on to newer team members as they join? Because once I get an idea of that, it can help answer the question, well, how much detail do I need to go into? 

Obviously, the Holy grail here is to have everything in your business documented in some sort of system or process to back it up. But that’s not always the case, particularly when you’re starting out. You’re going to have to prioritise. You can’t go down to minute detail for every single thing, and oftentimes that might be overkill. So we just need to kind of think it through and have a little bit of a framework. Perhaps one of the best ways to think about it is to give a couple of examples. So let’s say you had Sally in accounts and she’s been with you for ten years, and once a month she creates a budget variance report. 

Now, obviously, she’s a skilled team member who has been in that role for a very long time and is most likely going to continue doing that task for some time. So we don’t need a super detailed process here of exactly how to log into your finance package to navigate to the right report and click file and print and generate and all those sorts of things, because she’s got that level of skill. Not only that, if you were to recruit someone to take over her position, then that particular person is also going to come with some level of skill like an accounts person or a bookkeeper is going to have some level of training baked in. So you don’t need to kind of tell them how to suck eggs. If you’re just saying, hey, I want you to create a budget variance report, they might just need something very simple. And because sometimes we see software changing and interface changing, we don’t want to go down to too much detail anyway, because the system can very quickly become out of date. 

Now, if we compare that against something like handling an incoming inquiry in your business or handling a support ticket. These are tasks that might be more frequently executed. Oftentimes it might be by someone, maybe lower skills on the team, or maybe they’re just getting started out with you, and that’s how they learn the ropes at your company. The first thing that you do is you put them into customer support and they learn about the questions that your clients are asking. Well, they might need a little bit of extra detail because they don’t exactly know what it is that they’re doing. So there’s a couple of things to think about there around to what level of detail are you going to go? Now, I’ve also drawn this on the iPad here, and I just want to give you some thinking about when I’m talking about the level of detail, what might I mean? So let’s say the example with Sally in accounts, and we’re thinking about creating a budget variance report that might be just as simple as a system that has the title and a video that shows Sally going through that process. Very high level, easy for someone to be able to kind of step in and take it over if needed. 

Now, oftentimes this is also where a system starts. We always like the idea of making it simple and easy to start with. Either it’s going to start with some sort of video of someone doing the task, or it might be something as simple as a checklist, and then you might record it. So the level of documentation on version one, I always think about systems, and the first time that they’re created is it’s version one. And this can evolve over time. In fact, the ultimate goal here is to build a systems culture where the team is looking to improve the systems and the process as they go. So in this example, as it evolves, maybe now we’ve got some bullet points in addition to the video. Then over time, it can continue to evolve where you’ve got the bullet points and then you might have sub-bullet points that sit underneath that, plus the video. And then a fully formed system might have the title, it might have some sort of workflow diagram. It might have the bullets and the steps and additional graphics. It might also have the video. 

So, for example, that idea of handling a customer support ticket or an incoming inquiry because it’s for a position that might get retrained and new team members come on board, you might go to this level of detail or work towards that level of detail, whereas if it’s something that a more highly skilled team member might be doing and the chance of retraining on that is low, or if you do recruit, you’re going to have someone come with a certain level of skill, then maybe you’re closer to the other end of the spectrum. So just some ideas on what to think about to what level of detail. And we don’t want to necessarily over-engineer the process. Hopefully. That helps if you want some more tips, make sure you check out my copy of SYSTEMology. Create time, Reduce errors, and Scale your business with proven business systems.