Extraction Playbook

Okay, I know the Heroes reference in the previous chapter was a little obscure so I have one more for you. And I promise this will be my last pop culture reference!

Have you read any of the Harry Potter books? I’ve just finished The Half-Blood Prince. Please don’t judge me. I started reading the series to my son … Okay, okay, it’s true, I’m kind of enjoying it too now.

Anyway, there’s this moment in the book where Harry stumbles across an old, battered potions textbook. It’s filled with scribbled notes, crossed-out instructions and tiny tweaks to the recipes. Shortcuts that turn him into a potions master.

Instead of following the textbook’s steps to “Cut the sopophorous bean and add it to the cauldron,” Harry’s version says to “Crush the sopophorous bean with the flat side of a silver dagger to release the juice more effectively.” These simple tweaks make his potion far more effective than everyone else’s, including Hermione’s (which, if you’ve read Harry Potter, you know is a big deal). Harry shoots to the top of the class, catching the attention of Professor Slughorn.

To cut a long story short, it turns out the book was once owned by the mysterious Half-Blood Prince, who spent years perfecting those recipes. Now, I don’t want to give any spoilers, but I would like to offer you the same advantage given to Harry.

Let me be your Half-Blood Prince of systems documentation.

As you can imagine, over the years, I’ve collected plenty of helpful tips and shortcuts that can dramatically improve how you document systems. Surprisingly, many common assumptions about creating systems turn out to be wrong.

For instance, many believe systems should be comprehensive, documenting every possible scenario – yet the best systems are often the simplest. Others think documentation should be formal and technical – but systems written in a more conversational language get used more often. And contrary to popular belief, writing systems for the lowest skill level can actually hurt your business by driving away your most talented team members.

What follows is a collection of battle-tested lessons that might challenge what you think you know about systemisation. Each one addresses a specific challenge you’re likely to face. Whether you’re dealing with resistant team members, struggling with the level of detail to include or trying to decide what’s worth documenting, you’ll find guidance here.

So, just like Harry with his potions book, you now have access to my notes that will make extractions, documentation and systemisation faster, easier and way more effective. Let’s get started.

Lesson #1: Create only useful systems¶

Arguably one of my most important rules of extraction is to ensure you’re creating systems that add value. Avoid the trap of creating systems for systems’ sake. You already reduce that chance of misstepping here by sticking to the MVS, but beyond that remember this: not everything needs documenting.

Before you invest time, ask yourself one crucial question: “Will this documentation genuinely help the business?” If you can’t clearly see how this system will enhance customer experience, free up more skilled team members, improve efficiency, reduce errors or deliver some other tangible benefit, pause and reconsider.

Every system you create requires time to extract, document and maintain. Time is money, and that’s time you could spend on other, more valuable systems. Remember that the documentation is not the goal; the goal is to improve the business!

Lesson #2: Master the art of extraction¶

There is a direct correlation between how well you handle the extraction process and the quality of the documented system you produce.

Ever heard the computing expression “garbage in, garbage out”? It perfectly describes what happens when you don’t get this part right. If your recording is poor quality, if the knowledgeable worker rushes through the steps or if you miss crucial details during extraction, your final system will be limited in its usefulness. Or worse, it might introduce errors into the process.

This is especially true now that you’re using AI to help create your documentation. AI works best when you provide clear, structured input. Speaking clearly, marking transitions between steps (“That completes step three, now let’s move on to step four”) and maintaining a logical flow makes a massive difference. The better organised your extraction is, the better job AI will do at creating your initial draft. Think of AI as your documentation assistant – the clearer your instructions, the better its output.

Yes, the knowledgeable worker is the source of the process, but you are the driving force behind its successful extraction. You have the power to ask the right questions, uncover hidden gems of knowledge and ensure nothing is lost in translation.

Remember, every minute you invest in getting a quality extraction will save you multiple minutes in documentation and revisions later. Taking time to prepare, both yourself and your knowledgeable worker, is always worth the effort.

Lesson #3: Capture what’s working¶

When you start documenting a process, it’s tempting to immediately look for ways to improve it. Your analytical brain kicks in, and suddenly you’re seeing dozens of potential optimisations. While that innovative thinking is valuable, it’s not what you need right now.

Your goal is to capture what’s already working in your business today, focusing on the most probable path. That is, what’s most likely to happen. We’re looking for the path that represents the “blue sky scenario” where everything goes according to plan.

You don’t have to document every possibility. When exceptions occur (and they’re not accounted for in the system), team members will escalate things to more experienced members of the team. Your documented systems allow newer team members to master the core process without getting overwhelmed by every possible variation.

By focusing on what’s currently working and the most probable path, you create several crucial benefits. Firstly, it creates a baseline: after all, you can’t measure improvement without knowing where you started. Secondly, it keeps things moving forward. The moment you start trying to optimise processes or account for every exception, everything tends to slow down. Thirdly, and perhaps most importantly, it makes training easier because new team members can learn the core process first, then gradually understand how to handle exceptions as they gain experience.

Remember: right now, your job is to create consistency. Get everyone following the same main path, even if it’s not perfect. Once you have that consistency, you’ll have the foundation needed for meaningful improvement.

Lesson #4: Choose the right system type¶

As you begin extracting systems, you’ll notice they generally fall into two categories: higher level overview systems and more detailed “how-to” systems. Understanding the difference helps you choose the right documentation approach from the start.

Overview systems are exactly what they sound like: high-level processes that give you the big picture. Think of creating an annual marketing plan or managing a large project. These systems often span longer timeframes and involve multiple steps that can’t be completed in a single sitting. When documenting these, you’re usually having a discussion rather than recording someone performing a task in the moment.

For example, if you need to document the way your primary product or service is delivered. There’s a chance it could be quite complex with many moving parts. That might be an overwhelming place to start. Instead of jumping right into the detail, you might start with an overview. You’d sit down with your knowledgeable worker and have them walk you through just the key milestones at a high level.

How-to systems, on the other hand, are your detailed, task-specific processes. These are the day-to-day operations like issuing invoices in QuickBooks or updating your CRM. For these systems, it’s best to record the actual process being performed, capturing every click and keystroke. This is where you need that step-by-step precision because these systems are often used to train new team members or serve as reference guides for tasks that might only be done occasionally.

Here’s my hot tip when recording detailed how-to systems: slow everything down. Your knowledgeable worker probably performs these tasks on autopilot, which means they might zip through important steps without explanation. Encourage them to move deliberately and narrate their actions, and be sure to ask lots of questions if they’re not clear. These seemingly obvious details often make the difference between a useful system and one that leaves new team members confused.

The key is being flexible in your approach. Sometimes you’ll need to record a process in action, and other times you’ll need to extract it through discussion. Let the nature of the system (and who will be using it) guide your documentation method. And when in doubt, start with a high-level overview and look to add more detailed “how-to” systems over time.

Lesson #5: Balance detail with usability¶

“How detailed should my system be?” There’s no perfect answer to this question. It depends. What works beautifully for one process might be completely wrong for another. But there are three key factors that will guide your decision:

1. Who’s using it? A highly skilled team member with years of experience might only need a high-level checklist, while a new hire will need more step-by-step guidance. For example, your experienced bookkeeper might just need bullet points for month-end reporting, but your new admin assistant will need detailed screenshots for processing invoices.
2. What’s the complexity of the task? Simple, straightforward tasks might only need a few bullet points and a video. Complex processes often benefit from being broken into smaller chunks.
3. How often is it used? Tasks performed daily might need less detail as people quickly become familiar with them. But processes done quarterly or annually? Those need more detail because people don’t have the benefit of regular practice to reinforce their learning.

The best systems are like a good pair of jeans. They fit well in most situations and get better with use. If you find yourself writing a system that only works under perfect conditions with a specific person at a specific time, you’ve probably gone too far into the details. Think about it. The more specific and rigid your system becomes, the more likely it is to break when circumstances change even slightly.

Keep your systems flexible enough to handle most situations yet specific enough to still deliver consistent results. You want to create a framework that guides people to success, not a straitjacket that restricts their ability to think and adapt.

Remember, you can always add more detail later. Start with what’s necessary to get the job done correctly, then refine based on feedback and actual use.

Lesson #6: Make systems human-friendly¶

You’re writing for humans, not robots (at least, for now). Your systems need to feel like a helpful colleague guiding someone through a task, not a cold technical manual dictating commands.

This starts with language. Write conversationally, as if you’re explaining the process to a colleague over coffee. Instead of “Initiate the customer complaint resolution protocol,” write “Here’s how to handle a customer complaint.” Skip the corporate jargon and speak in terms your team actually uses.

You might not realise it but while you’re writing for humans, this approach works better for AI too. Clear, conversational language that’s well-structured and logical helps both people and machines understand your processes. It’s a win-win. Make it clear enough for a person to follow, and you’ve probably made it clearer for AI to process too.

Put yourself in the shoes of a new hire using your system for the first time. They probably don’t know your internal acronyms or have years of experience doing this task. What seems obvious to you might be completely foreign to them. This perspective helps you identify what really needs to be explained and what can be assumed.

Just be mindful to keep it engaging. Long, dull systems are like long, dull meetings – people find ways to avoid them. If a system feels too lengthy, consider having an overview system and then breaking up the detail into smaller detailed how-to systems.

Lesson #7: Simplify everything¶

Einstein said we should make things “as simple as possible, but not simpler”. He could have been talking about business systems.

Most people overcomplicate their systems, thinking they need elaborate templates and rigid frameworks. The reality is much simpler. As long as your approach is consistent and helps people get the job done, you’re on the right track.

Most effective systems include these key elements:

• Title: A clear heading that tells people exactly what this system achieves. Make it descriptive and searchable. I’ll often start with a verb, like “Processing Customer Refunds” or “Creating a YouTube Thumbnail”.
• Purpose: A statement that explains the “why” behind the process. This helps people understand the value of what they’re doing and make better decisions along the way. For example, “This system ensures customers receive prompt refunds while maintaining accurate financial records.”
• Trigger: An explanation of what kicks this system into action. Is it a customer complaint? A monthly deadline? A specific request? Make it clear when this system should be used.
• Inputs: What you need to have ready before you start. This might include information, documents, tools or access to specific software. Nothing is more frustrating than getting halfway through a process and discovering you’re missing something essential.
• Steps: The actual process, laid out in a logical sequence. This is your meat and potatoes of the system. What needs to happen from start to finish? Break it down into manageable chunks.
• Endpoint: How people know when they’re done. What does success look like? How do they know they’ve completed the process correctly? Define your outputs and what happens next. Does another system kick in? Does someone need to be notified? Make the hand-off points clear.
• Resources and examples: Any templates, tools or links needed along the way, plus real-world examples of the system in action. Nothing beats seeing how something works in a real situation.

That’s it. No need to overcomplicate things. Find a format that works for your team and stick with it. The goal is to make your systems useful, not win any documentation awards.

Lesson #8: Update when needed, not scheduled¶

I remember working with a business owner who proudly told me they review all their systems every December. When I asked why December, they paused and realised it was simply because that’s what they had always done. Like many businesses, they had fallen into treating system updates like an annual tax return – something to check off once a year and forget about.

This “review everything annually” mindset often comes from ISO certification requirements or corporate policies. But forcing updates on a rigid schedule usually leads to one of two problems: either it becomes a meaningless checkbox exercise, or worse, people wait to fix broken systems because “the annual review is coming up anyway”.

Think of it like maintaining your car. You don’t wait for an annual service to fix a flat tyre, right? You fix it when it’s broken. The same goes for your systems. Update them when they need updating.

I want to make sure an important distinction is clear. Updating a system is not the same as re-engineering it. Updating means tweaking and improving what is there, clarifying steps, adding missing information or reflecting minor changes in how things are done. Re-engineering is about fundamentally rebuilding the process from the ground up, which is a different exercise entirely.

I will talk a little more about re-engineering and optimising systems later, but for now, the key is creating a culture where everyone feels empowered to flag when a system needs updating. Your team members are your best early warning system. They know when something is not working well.

Putting it all together¶

There you have it: some practical tips drawn from years of helping businesses just like yours capture their way of doing things.

Remember, your goal isn’t to create perfect systems. It’s to capture what’s working in your business today, make it repeatable and build a foundation for continuous improvement. Start with clear recordings, focus on what matters most and keep your systems human.

You might be surprised how quickly things start falling into place once you begin. That first system might take a bit longer as you find your rhythm, but by system three or four, you’ll have developed your own style and the process will feel natural.

I’ve seen this transformation happen countless times. Business owners and their Systems Champions who once struggled with systemisation are leveraging these ideas and AI and suddenly find themselves with a growing library of practical, usable systems. Their teams become more confident, their operations more consistent and their businesses more scalable. Most importantly, they’ve created a culture where “I didn’t know how” becomes “Let me check the system.”

Now it’s your turn. Pick your first system, schedule that extraction and start building.