The first system you hand work to sets the tone for every one after it. Choose well and the team sees a tool that takes a chore away and gets it right. Choose badly and the team learns that AI is something that needs watching. This guide is the method we use with an owner to pick the first workflow. It takes an afternoon.
What a good first workflow looks like
The best first candidates share three traits. The work arrives in one channel. It follows a rule a person could write down. It ends in a record. Check all three before you look at anything else.
It arrives in one channel
The work shows up in one place: a shared inbox, a phone line, a web form, a folder that fills up overnight. One door is easy to watch. If the same request can come by phone, by text, by email and in person, a system has to watch four doors, and each one behaves differently. Start with work that comes through one.
It follows a rule
Ask the person who does the work today to explain how they decide. If they can say it in a few sentences, it is a rule. "If the invoice matches the purchase order, approve it. If it does not, send it to Dana." That is a rule. "I just know when something is off" is not a rule yet. It may become one after you watch a few cases together, but it is not where to start.
A rule can have exceptions. Write those down too. The exceptions are where the system will stop and ask a person, and knowing them in advance is half of the design.
It ends in a record
The work finishes by writing something down: a booking in the calendar, a line in the ledger, a note on the client's file, a ticket marked closed. A record gives the system a clear finish line. It also gives you a way to check the work afterward, because the record either matches what a person would have written or it does not. If the work ends in a conversation and nothing is written down, there is nothing to test against.
Where to look
Good first workflows hide in plain sight. They are the tasks nobody talks about because everyone has done them for years.
- The inbox someone clears every morning before the real work starts.
- The form that comes in and has to be retyped somewhere else.
- The calls that ask the same five questions.
- The document that gets checked against another document.
- The report assembled on the first of every month from the same three sources.
Ask each person on the team one question: what do you do every day that you could explain to a new hire in ten minutes? The answers are your shortlist.
What to leave alone
Some work looks like a good candidate and is not. Leave these for later, not forever.
- Anything where the rule changes every week.
- Anything where a mistake is hard to reverse: sending money, deleting a record, telling a client no.
- Anything that depends on one person's relationships or judgement about people.
- Work you have not done yourselves for long enough to describe.
- Work that touches the most sensitive information you hold, until you have run something smaller first.
The point of the first workflow is not to save the most time. It is to learn how a system behaves inside your business, and to build the habit of checking its work. A small, boring workflow teaches that lesson better than a large one.
Pick the workflow you would be comfortable explaining to a new hire on their first morning. If you cannot, a system cannot learn it either.
A quick test
Put each candidate through this table. A workflow that sits in the left column on every row is ready. One that sits in the right column on any row needs more shape first.
| Trait | Start here | Leave for later |
|---|---|---|
| Arrival | One inbox, one line, one form | Several channels, or in person |
| Rule | Written down, stable for months | Changes often, depends on feel |
| Finish | A record in one piece of software | A conversation, nothing written |
| Mistakes | Easy to catch and reverse | Costly or hard to undo |
| Information | Ordinary business records | The most sensitive files you hold |
The one-page worksheet
We ask owners to fill one page before a call. It does not need a template. A blank page with these parts in order is enough.
At the top, name the workflow in one line, in the words the team uses for it. Under that, write where the work arrives and roughly how often, as a sentence rather than a count. Then write the rule the way the person who does the work would say it out loud, including the cases where they stop and ask someone. Next, name the record the work ends in and the software that holds it. Then list every system the work touches along the way, even the spreadsheet nobody admits to. After that, write what a bad outcome looks like and who would notice it first. Finally, name the person who does the work today and whether they would be willing to review the system's output for the first month.
If the page fills easily, the workflow is a good first candidate. If you get stuck at the rule, or you cannot name the record, that is useful too. It tells you the workflow needs more definition before a system can take it, and it tells you exactly where.
What happens next
Once you have a candidate, the next step is to find out where its information goes. Ask for a data map before anyone touches a file; we describe what one should contain in Ask for a data map. After that, the system is tested on your own records before it goes live, which is covered in Shadow mode before launch.
Keep the worksheet. It becomes the first page of the scope, and six months later it is the clearest record of what the work used to look like.