You can't automate a process that isn't defined.

Every week I meet leaders who want to put AI on a process. Order handling, onboarding, month-end, customer requests. The ambition is right. The order is usually wrong.

Ask the people doing the work how the process runs, and you get as many versions as there are people. Ask where it is written down, and you get a document last touched two years ago, or nothing. Then the automation project starts, and the first weeks go to discovering the process instead of improving it.

You cannot automate a mess. You get a faster mess.

The test: could a stranger run it?

A process is defined when you can write it down as steps, and someone who has never seen it can do the work correctly from the written guide alone. Not roughly. Correctly, including the checks and the exceptions.

That bar sounds high. It is exactly the bar an AI model or an automation needs. A model does what is written, not what is obvious to the person who has done the task for years.

This is where it usually breaks. Someone asks a tool to “calculate our average cost”. In their head that formula has ten small exceptions: this gets excluded, that gets weighted, this only counts after month three. They never say any of it, because to them it is logical. The tool gets built on the half of the logic that was said out loud. The first numbers match, so it ships. Then the inputs change.

The fastest way to write a process down today

Asking people to sit down and write an SOP rarely works. They do not have time, and the result is either too thin or so long nobody reads it. There is a much faster route now:

1. Record yourself doing the work. Use Loom or any screen recorder. Do the task as you normally would and talk while you do it: what you are doing, what you check, and why. Say the exceptions out loud when you meet them.
2. Give the recording to an AI model. ChatGPT, Claude or Gemini can all do this well. If your tool does not take video, give it the transcript and a set of screenshots.
3. Ask for a short, complete SOP with screenshots where they help. The prompt is below.
4. Revise it yourself. The draft will be good, not finished. Fix what it misunderstood and add what you forgot to say.
5. Run the stranger test. Someone who has not done the task does it from the SOP while you watch, hands off. Where they get stuck is where the knowledge was hiding. Fill it in, and run it again.

A process that has lived in one head for years can be written down this way in a day, not a quarter.

Attached is a screen recording of me doing [task name], with my voice-over explaining what I do and why.

Write a short but complete SOP for this task, so that someone who has never done it can do it correctly from the SOP alone.

- Base the steps on both what happens on screen and what I say.
- Start with: purpose, when the task is done (trigger), who does it, and what you need before you start.
- Then number the steps in order. One action per step. Name the exact system, screen, field and button.
- Insert screenshots from the video where they make a step clearer, with the timestamp.
- Include every check, decision and exception I mention: what to look for, and what to do if it is not as expected.
- End with how to know the task was done correctly.
- Keep it to the point. No introduction, no generic advice.
- Finally, list anything that was unclear or that I skipped over as open questions for me.

Record the task more than once if it varies. Three runs usually surface the exceptions that one run hides.

This gives you a document. Not yet a system.

Be clear about what you have at this point: a good, standalone SOP. That is a real step forward, and it is what you need before any automation or AI.

But a document can sit in a folder and never be used. I have opened more than one “finished” SOP that nobody followed, where each manager did what they remembered that week. Writing it down felt like finishing the job.

If you want the process to actually run this way, every time, the guide has to live where the work happens. That means choosing the tools, and building the SOP into the tasks people do each day. That is the subject of the next note: the intentional process environment.