- The reason a solo business cannot hire is rarely money. It is that nothing is written down, so the first week of a new person costs more time than they save.
- A model is good at turning a rambling recording of you doing a task into a structured procedure. It is bad at knowing which steps you actually take.
- Checklist research is blunt about where this works: routine tasks done on autopilot, not tasks that need active problem solving.
- The WHO surgical checklist is 19 items across three phases, and its own guidance stresses verbal confirmation over ticking from memory.
- Write standard operating procedures for the tasks that repeat and carry a cost when done wrong, and leave the rest alone.
- The test of a procedure is somebody following it without asking you anything. Every question is a missing step, not a slow learner.
You know how to do everything in your business and none of it is written down. That is not disorganisation, it is the natural state of a thing one person built. It becomes a problem at exactly one moment: when delegation is finally forced on you and you try to hand a piece of it to somebody else, and discover that explaining takes longer than doing, so you take it back. A first hire is where this bites hardest, but it bites long before that.
Most advice about this tells you to document your processes, which is like being told to get fit. The obstacle was never agreeing it was a good idea. The obstacle is that writing a procedure from a blank page is slow, boring work that competes with paying work, and the version you produce at eleven at night is worse than what is in your head.
What has changed is the cost of the first draft. That is a smaller change than it sounds, and it is still the change that makes this feasible.
Which tasks are worth writing down?
Fewer than you think, and the research on checklists is unusually direct about the boundary.
The AHRQ patient safety literature notes that checklists work best for tasks involving schematic behaviour, meaning routine actions done on autopilot, and are a poor fit for errors that require active problem solving such as diagnostic mistakes. It also names weak evidence and poor implementation as the two reasons checklists fail to reproduce their results elsewhere.
Translate that into a shop or a studio and you get a clean test. Packing an order, opening up, processing a return, invoicing a wholesale customer, the weekly stock count: all schematic, all worth writing. Deciding whether to take on an unusual custom job, pricing something you have never made, handling a customer who is upset in a way you have not seen before: not schematic, and a procedure for them will either be useless or actively harmful because it will encourage somebody to follow it instead of asking you.
The second filter is cost of error. A task done wrong that costs nothing does not need a document. Sort your candidates by how often they happen multiplied by what a mistake costs, take the top handful, and ignore the rest until those work.
How do you get it out of your head?
By talking, not by writing, and this is the part that makes the whole thing tractable.
Do the task while narrating it out loud, and record yourself. Not a summary afterwards, which is where the omissions creep in, but a running commentary during the actual work. You will say things you would never have written: that you always check the second box before sealing, that this particular supplier's boxes arrive taped differently, that you skip a step on Fridays because the courier comes early.
Then transcribe it and hand the transcript to a model with an instruction to impose structure on it. Steps in order, inputs required at the start, decision points named, and anything ambiguous flagged rather than resolved. This is genuinely the thing language models are best at: taking unstructured speech and giving it a shape. If you already use transcription for meetings you know both the value and the limits, which we went through in a piece on what an automated note taker leaves out.
The output will be about seventy percent right and will feel like a small miracle. The next step is the one that decides whether the document is worth anything.
What does the model add that you must delete?
Generic best practice, presented in the same confident register as the steps you actually described.
Ask for a procedure for packing an order and you will get steps about verifying the shipping address against the order, inspecting items for damage, and recording the tracking number in your system. Some of those you do. Some of them you do not, because your volume does not justify it or because your system does it automatically. All of them will look reasonable, and a new person following the document will do all of them, slowly, and wonder why the job takes twice as long as you said.
The rule is mechanical and it works: delete every step that does not appear in your transcript. If the model added a check you think is genuinely a good idea, that is a separate decision about changing how you work, and it should be made deliberately rather than smuggled in by a document. Write the procedure for what you do now. Improve the process afterwards, on purpose.
The same failure appears in reverse. A model will smooth over the step you mumbled, the exception you mentioned once, the thing you do without noticing because you have done it four thousand times. Read the transcript, not just the structured output, at least for the first few procedures. The unglamorous detail you almost skipped is usually the one a new person gets wrong.
How do you know the procedure is any good?
Somebody else follows it, start to finish, without asking you a single question. That is the only test, and it is unforgiving in a useful way.
Sit somewhere you can see them and say nothing. Write down every point where they hesitate, guess, or turn round to ask. Each one is a defect in the document. Not a shortcoming of the person, and not a sign they need more training: if the procedure required knowledge that was not in it, the procedure is incomplete, and the same gap will catch the next person.
Expect the first run to produce five to ten gaps on a task you thought was simple. That is normal and it is the entire value of the exercise. The version after two runs by two different people is a genuinely usable document, and it took you an hour rather than a weekend.
What to write down, and what not to
| Task | Repeats | Cost of an error | Verdict |
|---|---|---|---|
| Packing and dispatching an order | Daily | A return and a bad review | Write it first |
| Opening and closing | Daily | Security and stock loss | Write it, keep it short |
| Processing returns | Weekly | Refund errors, disputes | Write it |
| Answering a routine enquiry | Many times a day | Low, one at a time | Write the five common answers |
| Pricing a bespoke job | Occasionally | High and specific | Do not write it, keep it yourself |
| Handling an angry customer | Rarely | High and situational | Give principles, not steps |
The 19 items that get quoted, and the part that gets ignored
The surgical safety checklist is the reference example everyone reaches for, and it is usually cited for the wrong reason. It is 19 items across three phases, before anaesthesia, before incision, and before the patient leaves the room, created after extensive consultation to reduce errors and improve communication.
The part that gets ignored is in the same guidance: the checklist depends on genuine team participation and verbal confirmation at the pause points, rather than items being checked from memory. In other words, the document is not the intervention. The moment where somebody stops and says the thing out loud is the intervention.
For a two person business that translates cleanly. A procedure filed in a folder changes nothing. A procedure that produces a moment where somebody confirms out loud, or ticks a physical thing, or sends a one line message saying the count is done, is what actually catches errors. When you write yours, build in the pause rather than assuming reading is enough.
What a good procedure looks like on the page
Short, ugly and specific. The documents that get followed share a shape, and it is not the shape of a company handbook.
One task per document. Not a chapter covering dispatch. A page covering how you pack a standard order, and a separate page for how you pack a fragile one. Anything long enough to need a contents list will be skimmed rather than followed, and a skimmed procedure is worse than none because everybody believes it was used.
Inputs at the top. What you need in front of you before you start: the order screen open, the scales, the roll of tape that is not the wrong one. Half the hesitations in a first run happen because somebody got three steps in and had to go and find something.
Decisions written as questions with answers. If the parcel is over two kilos, do this. If the customer paid for next day, do that. A decision buried in a paragraph gets missed. A decision written as a branch gets followed, and it is also the form that tells you when a procedure is trying to cover a task that is not schematic after all, because the branches multiply past what anybody can hold.
The reason, only where it prevents improvisation. Not a rationale for every step, which nobody reads, but one line where a step looks pointless and somebody will otherwise skip it. Explaining why you photograph the label before sealing is worth twenty words. Explaining why you use tape is not.
A date and a name. Whoever last ran it and when. A procedure nobody has touched in two years is a claim about your business that may no longer be true, and knowing that at a glance is what stops it quietly rotting.
Keeping them alive without a system
The failure mode is not that procedures are never written. It is that they are written once, get overtaken by how the work actually changed, and become something everyone politely ignores.
Two habits prevent that and neither needs software. The first is to update the document at the moment you deviate from it, not later. If you found a better way to do the third step this morning, change the third step this morning, in one line, badly. A procedure that is roughly right and current beats a polished one describing last year.
The second is to let whoever follows a procedure edit it. The person doing the work daily knows where it is wrong, and if they need your permission to fix a sentence they will simply stop reading it instead. Ownership sitting with the doer is what keeps documentation honest in a small team, and it costs nothing to grant.
Storage matters less than people think. A shared folder is fine. What matters is that there is exactly one place, that everybody knows where it is, and that nobody keeps a private copy, because two versions of a procedure is the same problem as two versions of a catalogue and it resolves the same way: one master, everything else a reference to it.
Where the paperwork stops being optional
At the point you actually employ somebody, a second category of documentation arrives that has nothing to do with efficiency and everything to do with compliance. It is worth separating the two in your head, because people who dread the first often dread it because they are quietly dreading the second.
In the United States the SBA sets out a ten step sequence for hiring: get an employer identification number, check state tax registration, decide whether the person is an employee or a contractor, collect a completed W-4, set a pay period aligned with withholding, decide leave and holiday, choose how payroll is run, name who runs it, keep the required records, and file payroll taxes on schedule. It notes that employment records covering taxes must be kept for at least four years, that Form I-9 must be completed and retained, and that new employees must be reported to a state directory within 20 days of hire.
Two things follow. The classification question, employee against contractor, is the one with real teeth, since getting it wrong can mean back taxes, penalties and owed wages. And this compliance work is genuinely separate from your operating procedures, so do not let the size of it stop you writing the packing procedure. Other countries have different lists, and the shape is the same everywhere: statutory records on one track, how the work gets done on the other.
What a procedure lets you hand over that you could not before
More than a person. This is the underrated second return, and it arrives whether or not you hire anybody.
A written procedure is also the specification for a tool, a template or an automation. Once the routine enquiry answers exist as text, they become the basis for a canned response set, and eventually for anything automated that handles the same questions. We looked at where that line falls in a piece on which support tickets are worth handing to a machine first, and the prerequisite in both cases is identical: somebody has to have written down what the right answer is.
The same document also protects you from yourself. Procedures are how a business survives its founder having a bad week, being ill, or going on holiday without the phone. A solo operation with nothing written down cannot take a fortnight off, and that is a constraint people accept for years without ever naming it as the thing a few hours of writing would fix.
One practical caution about procedures that reference software. A step that says click the third tab is worthless the moment the interface changes, and interfaces you do not control change without asking. Write steps in terms of what you are achieving rather than where the button is, and keep the systems your procedures depend on as stable and as yours as you can. That is part of the wider argument for running your store on something whose behaviour and data stay under your control, and it applies to your documentation as much as to your catalogue.
Start with the one you resent most
Not the most important. The one you find yourself doing at nine in the evening thinking that anybody could do this. That resentment is a reliable signal: it marks a task that is genuinely routine, genuinely repeated, and genuinely not a good use of the person who owns the business.
Record yourself doing it once. You will have a working procedure inside an hour, and the second one takes half as long because you will already know what to delete. Whether you hire anybody this year is a separate question, and the document is worth having either way, since a business that exists only in one head is worth less and is harder to leave for a week.
If you write standard operating procedures for nothing else, write the one for what happens when you are unreachable. Most solo businesses have never answered that question in writing, and it is the one where the cost of a bad improvised answer is highest.