Skip to content

How to Document a Process Before You Automate It in a Single Sitting

Most process documentation dies because it was scoped as a project. Somebody decides the business needs a proper knowledge base, a template gets chosen, two people get assigned, and nine weeks later there are four documents nobody has opened since the week they were written.

The version that works is smaller and more selfish. You are not documenting the process so that it exists in a folder. You are documenting it because an agent is about to run it, and an agent will do precisely what the document says, including the parts you left out. One process, one sitting, and you should be finished inside an hour.

This is the method underneath episode 124 with Ty Givens, where she described walking into operations after they break and finding, nearly every time, that the software was fine and the instructions were not. She gave the diagnosis on the show. This is the treatment.

Pick the process by pain, not by how easy it looks

The instinct is to start with something simple, because a win feels good. The instinct is wrong, and it is why so many businesses end up with a folder of documented processes that nobody needed documented.

Choose the process that costs you the most time this month and that you would be most annoyed to explain to a new hire for the fourth time. That annoyance is a reliable instrument. It measures exactly the thing you are trying to remove, which is Admin Drag sitting on your calendar.

One process. Not a category, not "customer onboarding." Something with a start and a finish, like "a new client signs and we get them into the first call."

Write the trigger and the finish line before anything in between

Two sentences, and do them first.

What starts this? Not roughly, but the specific event. A form submission. A signed agreement landing in the inbox. A date passing. If you cannot name the trigger precisely, you have chosen a category rather than a process, and you should go back a step.

What does finished look like? Again specifically. Not "they are onboarded" but "the kickoff call is on both calendars and the welcome pack has been opened."

Doing these first stops the thing that kills most attempts, which is discovering forty minutes in that the process you are documenting has no edges and quietly includes half the business.

Walk it forward once, without correcting yourself

Now write what actually happens. Not what should happen. What happened the last time you did it.

Do it in one pass and resist every urge to improve it as you go. The moment you start fixing the process while recording it, you stop describing reality and start describing an intention, and the gap between the two is where automation breaks. Ugly steps stay in. The bit where you check a spreadsheet you have been meaning to retire for a year stays in.

Ty made this point about herself on the show, which is the version I trust:

"I might go in and start building that agent without a proper foundation. And what ends up happening is I spend so much more time fixing and tweaking and editing and changing than I would have if I had just sat down and said, what do I want it to do?"

Her threshold for catching it is thirty minutes. If half an hour into building something you still cannot see the end of it, stop building and go write this document instead. That rule has saved me at least one wasted afternoon since I heard it.

Add the branches, which is where the actual work is

You now have a linear document, and a linear document is a description of the day everything went right. That day is rare enough that automating for it is close to useless.

"When I make a list, it's linear. This will happen after this, after this, after this. But the reality is, when you're building out any resources or any agents or tools using AI, you have to have more than just one outcome as a possibility."

Go back through what you wrote, and at every step where you used the word "then," ask one question: unless what?

The client signs, then we send the welcome pack. Unless what? Unless they signed a different plan than the one we quoted. Unless the signature came from someone who is not the billing contact. Unless they signed on a Friday evening and the pack would land at a useless moment.

Each "unless" becomes a branch. Most steps have none and you move on in seconds. A few have two or three, and those few are the entire reason the last attempt at automating this failed. An agent meeting an unhandled branch does not stop and ask. It picks one.

Expect this pass to take longer than writing the original walkthrough. That is the pass doing its job.

Read it from the outside in

Here is the step almost nobody includes, and it comes straight from how Ty's team opens an engagement. Before they look at any system, they read what the business has told the world, and then what it has told its own people.

Do the same to yourself. Two questions.

What has the customer been told? Your help centre, your FAQs, your published policies, the automated emails you set up in 2023 and have not read since. That is the promise on record.

What has your team been told they can do beyond that? The unwritten latitude. The refund a good rep gives without asking. The exception everyone makes for a long-standing client.

The gap between those two answers is where every ugly service moment you have ever had came from, and it is the gap an agent will fall straight into, at volume, without the instinct that stops a human. Closing it is most of the value of this exercise, and it has nothing to do with AI.

Settle the decisions you would otherwise improvise

A process document tells an agent what to do. It does not tell it what you are willing to do, and those are different documents.

Ty's list of the decisions that have to be settled in advance is the most practical thing in the episode:

  • When you issue a refund, and whether you issue money back at all rather than credit
  • How much notice you require to end an engagement, and what happens when someone gives less
  • What happens when something is not delivered, and how many times before you stop delivering
  • How you respond when someone gets loud about you in public
  • How long an order or a request sits before it becomes irreversible, and whether the customer can still change it

Her framing was a prenuptial agreement, and the comparison holds for the same reason. You write these while nothing is going wrong, because the entire point is that you will not be thinking clearly when something is.

"I have emotions and the agents don't. They just follow your process."

That line is worth sitting with. It is not a warning about agents. It is a description of the only advantage they actually have over you, and it is unavailable until the process exists.

Name the decision the agent never makes

The last step takes a minute and it is the one that turns a document into something you can safely hand over.

Read back through what you have written and find the decision that should never be automated. Every process has at least one. The discount above a threshold. The refusal of a refund. The message that goes to a client who is already unhappy. Write it down, with the reason, before the agent runs.

That is a Flight Rule, and it answers the fourth question of the Seat Test: is there a decision it never makes? An agent without one is not a crew member. It is a subscription that has been given too much rope.

The other three questions of the test have effectively been answered by the work you just did. The process has a named role attached to it, a defined job with a trigger and a finish line, and you are the human who owns it. Building a Digital Crew starts here rather than in a tool.

How to document a process before you automate it, in one sitting - The AI Hat

What you have at the end of the hour

A document with a trigger, a finish line, the real steps, the branches, the two sets of expectations reconciled, the policies settled, and one decision reserved for a person.

That document is now two things at once. It is how you would train a new hire. It is also what an agent answers from, which is the part that has changed in the last couple of years and the part most businesses have not caught up with yet.

Ty's full diagnosis, including what she looks at first when she walks into an operation that is already on fire, is in episode 124 of The AI Hat Podcast.

Share with your network!
Mike Allton

Mike Allton

Mike Allton is a practitioner, not a futurist - founder of The AI Hat, which runs on a Digital Crew of his own. He helps teams clear the Admin Drag burying their best people - redesigning the work first, then building a Digital Crew of AI agents to take the busywork. He is the host of The AI Hat Podcast and a keynote speaker who works the rooms he teaches - from national sales meetings to insurance and Medicare distribution conferences. He also helps organizations bring Shadow AI into the light through governance and training.View Author posts