Your Best Process Lives In One Person's Head. Get It Out.

Every company has one. The order gets processed a particular way, and only Sarah knows why the third step exists. The monthly report is built from four spreadsheets, two of which sit on somebody's desktop. Client onboarding runs beautifully right up until the person who runs it takes a fortnight in Portugal. Nobody planned this. It accumulated. Someone worked out a good way of doing something, it worked, and there was never a quiet week in which to write it down. Five years later the process is holding up part of the business and there is nothing to read, because nothing was ever written. The risk people reach for is the dramatic one — someone leaves suddenly and takes the knowledge with them. That happens, but it isn't the common failure. The common failure is duller. Work you can't see is work you can't improve, cost, check or hand to anyone else. It doesn't show up in a plan. It shows up when someone resigns. Start with the one that would hurt most Don't try to document the company. Pick one process. The test is simple: if the person who owns it left on Friday, what would still be broken on Monday? That's your candidate. Sit down with them, or with the team if it's shared. Give it an hour. This isn't a form to fill in — it's a conversation where someone talks through what they actually do while you write it down. Write it the way you'd train a new hire Plain language, in order, with nothing assumed. Not "process the claim" but the actual steps: where you log in, what you check, what you do when the reference number doesn't match, who you tell. The detail people skip is the exception handling, and that's usually where the real expertise is. Anyone can follow the happy path. The value is in knowing what to do when the supplier hasn't sent the paperwork or the customer's details don't match their account. Then argue with it This is the part that gets dropped, and it's the part that pays. You now have a written process. Read it properly and be honest about it. Are there steps in here that exist only because someone once made a mistake in 2019? Is anything being checked twice by two different people who each assume the other isn't bothering? Is there a step missing — an approval, a data check, something your insurer or your contract with a client assumes you're doing? "We've always done it this way" is not a reason. It's the absence of one. Sometimes there's a good answer behind it and the person just hasn't had to say it out loud in years. Sometimes there isn't, and you've found a step you can delete. Document the plumbing, not just the steps The steps are half of it. The other half is everything the process quietly depends on, and this is where undocumented work does the most damage. Where does the data live, and who can get at it? Which subscriptions does this rely on, and whose card are they on? Which of these accounts is registered to a personal email address? What has to happen before this process can start, and what breaks downstream if it doesn't run this week? None of that is glamorous. All of it is the stuff that turns a resignation into a fortnight of digging around and chaos. Put it somewhere boring and findable Write it up as an SOP and put it in Google Drive, SharePoint, OneDrive, whichever one your team already opens without thinking. Not in a folder that requires a map. Not attached to an email. Give it a named owner and a review date. A document nobody owns rots quietly, and a rotten SOP is worse than none, because people follow it. Do that and you have done most of the work. Not because writing is the hard part, but because the thinking was. Documentation and mapping are two different jobs What you've just done has a name, and it's worth separating the two halves. Process documentation is the written account: the steps, in order, in plain language, so somebody else can do the work. It makes the process transferable. Process mapping is the visual view of the same thing — the sequence drawn out, showing who or what handles each stage, where decisions branch, and where work sits waiting for someone else. It makes the shape of the process visible. You want both, because they show you different problems. The document tells you whether the work can be handed over. The map tells you where the work is being handed over five times, or where it stops dead every Thursday afternoon waiting for one approval. There are formal ways to draw these — swimlane diagrams, BPMN notation — and for most small companies they're more than you need. A box per step and an arrow per handoff on a whiteboard will show you the same bottlenecks. If you'd like a hand with that, our process mapping service is built for exactly this stage. Now ask whether it should be automated Only now. Once a process is written down clearly enough that a new starter could follow it, you can ask a much better question than "where could we use AI": is this repeatable enough to hand to a machine? Some of it will be. A well-documented process is the raw material for a workflow, a reusable skill, or in some cases an agent that handles the routine passes and escalates the rest. Some of it won't be, and that's a real answer too — a step that needs someone's judgement should stay with someone. You cannot make this call before the process is written down. That's the whole point of the order. Automating a process nobody has examined just makes the mess faster and harder to see. Work out what the process should be, then decide what tool it deserves. Bring in whoever you need for that part: your IT lead, an AI lead if you have one, a consultant if you don't. If it's useful, our automation and workflows service picks up from here. What you actually get Someone goes off sick and it isn't a crisis. A new starter is useful in their second week instead of their second month. You can hand a task to someone else without the three-day handover conversation. And when a client or an auditor asks how you do something, you send them a document rather than booking a meeting to find out. That is one process. Do it again next month with the next one. Within a year the thing that lived in people's heads lives in the company, which is where it should have been all along. Frequently asked questions What is process documentation? Process documentation is a written, step-by-step account of how a piece of work actually gets done — in plain language, in order, with the exception handling included. Its job is to make the process transferable to someone else without a handover conversation. How is process documentation different from process mapping? Documentation is the written version — the steps and the plumbing behind them. Mapping is the visual version — a diagram showing the sequence, the handoffs and the decision points. You want both. The document tells you whether the work can be handed over; the map tells you where the work is bottlenecking. Which process should an SME document first? The one that would hurt most if the person who runs it left on Friday. Not the biggest process, and not the easiest — the one that quietly holds up part of the business and only lives in one person's head. Do I need a formal SOP template or BPMN diagram? No, not necessarily but consistency helps. A clearly written document in the tool your team already uses (Google Drive, SharePoint, OneDrive) with a named owner and a review date is enough for most SMEs. Formal notation is useful when a process is complex or regulated — otherwise it's complexity you don't need. Should I automate a process before I document it? No. Automating an undocumented process just makes the mess faster and harder to see. Write it down, argue with it, remove the steps that shouldn't be there — then decide whether what's left is repeatable enough to hand to a workflow, a reusable skill or an agent. Working on this yourself? If you want to talk through one process — one problem, not a transformation programme — I offer a free 30-minute call. A working session, not a sales pitch. Get in touch and we'll book a time. Remember: Problem First. Tools Second.