How to Write Down Your Process So It Repeats the Same Way

Write your process from memory tonight and you will produce the smooth version — the job where the part is in stock, the customer is in, and nothing has to be looked up. That version is useless the first time reality shows up, which is the first time you use it.

So the document gets built during a job, by the person doing the job, while the annoying parts are still happening.

Write it while you do the job, not afterwards from memory

Open a notes app or a voice recorder before you start and narrate. Not a polished commentary — a running log. Loading the van, forgot the extension lead again. Called ahead, no answer, went anyway. Had to look up which sealant.

The things worth capturing are the ones you would never write from a chair: what you went back for, what you had to look up, where you waited, what you guessed at, what you did twice.

Clean it up that evening while it is still warm. Twenty minutes of tidying a real log beats two hours of inventing a process, and the log has the friction in it.

Do one job this way, not five. A procedure written from one honest job and corrected over the next few is alive. Five logs waiting to be turned into a document is a project you will never start.

The three sections a usable procedure needs, and nothing more

First: what has to be true before you start. Tools, materials, access, information, confirmations. This is the section that prevents the wasted trip, and it is the one people leave out.

Second: the steps in order, in the words you actually use out loud. Not formal language. If you call it the little gray box, write the little gray box.

Third: what finished looks like. The check. Photograph taken, area swept, customer shown the work, invoice sent, keys back through the letterbox. Without this, done means whenever you stopped, and that varies with how tired you are.

Anything else — the reasoning, the history, the philosophy of your trade — goes somewhere else or nowhere. Every extra paragraph lowers the odds you open the thing under time pressure.

Record the decisions, not only the actions

Steps rarely vary. Decisions do, and they are the part that lives only in your head.

So write the forks in as conditions. If the wall is plasterboard, use the toggle fixings from the blue box. If the customer is not home, do the outside and message; do not let yourself in even when invited. If the quoted part is out of stock, ring before substituting, never after.

The test of a good fork is that somebody without your judgment could act on it. Words like assess, evaluate and use your discretion are the ones to hunt down and replace — they mean the decision still has to come back to you, and the whole point is that it should not.

The forks are also what makes the document survive contact with a second person, which is the awkward part of handing work to your first help.

Keep it where you will actually open it

The document goes on the phone in your pocket, reachable in one tap, in the same place every time. Not a folder on a laptop you left at home. Not a paper binder in the van you did not take today.

A document nobody opens is worse than not having one, because it makes you believe the knowledge is safe when it is still entirely in your head.

Test it honestly: next job, open it and follow it even though you know the work. You will find three lines that are wrong or missing within the first hour. That is the document earning its place. If you get to the end of the job and never opened it, the problem is where it lives, not what it says.

A shared note, a free cloud document, or a pinned message to yourself all work. Options and their trade-offs sit with the rest of the free tools for starting a business with no money.

Update it the moment something goes wrong, as part of the fix

When a job goes sideways, the fix is not finished when the customer is happy. It is finished when the line is changed.

Do it while you are still annoyed. Annoyance is precise: you know exactly which assumption failed and what you would have needed to know. A week later you will remember that something went wrong and write a vague warning that helps nobody.

Keep the edits small and specific. Add the missing precondition. Change the fork. Delete the step nobody does. Resist the urge to restructure the whole document, which is how people spend an afternoon and change nothing about the work.

As volume climbs, this same habit is what stops standards drifting, which is the mechanical half of keeping quality consistent when volume goes up.

Bespoke work where the only thing in common is you

If you are still testing what the business even is — different services, different customers, different way of delivering it each week — a procedure is a document about a job you are about to stop doing. Writing it costs evenings and produces something stale.

The same applies to genuinely bespoke work, where every project starts from a different brief and the only thing in common is you.

Both cases still get one page: the preconditions. What you need before you can start anything, and the check at the end. Those hold steady even when the middle changes completely, and they prevent the two failures that hurt — turning up unable to work, and leaving without finishing properly.

And if every job is different because you have never decided what you sell, writing the process is the wrong problem to work on. Fix the offer first: building a repeatable offer instead of custom work. Documenting chaos just gives you a written record of it.