The first workflow you automate should be the boring one.

Almost every first conversation about automation starts in the same place: the workflow the executive team can see. Sales outreach. Customer-facing summaries. Something that will demo well at the next all-hands. It is an understandable instinct and it is usually the wrong first project.

Visible workflows are visible because they are judgement-heavy. They vary by customer, by deal, by mood. That variance is precisely what makes them expensive to automate well and easy to automate badly. The failure is also public, which means the organisation's first experience of the system is a bad one, and the second project never gets funded.

Three properties that make a workflow ready

When we score candidates during discovery, we are looking for three things, in this order.

1. 01
   It runs the same way every timeIf two people on the same team would do it differently, you do not have a workflow yet. You have a habit. Write the steps down first and see whether they survive contact with a second operator.
2. 02
   Someone owns the outcomeNot the tool, the outcome. A named person who notices when the numbers are wrong and has the authority to change how the work is done.
3. 03
   Failure is loudA reconciliation that does not balance announces itself. A subtly wrong sales email does not. Start where you will find out you were wrong within a day.

Boring does not mean small

The reconciliation above consumed half a person's week, every week, and nobody had ever put a number on it. That is common. Mechanical work hides inside job descriptions rather than showing up on a roadmap, so it never competes for attention with the visible projects.

The best first project is the one an operator can already describe perfectly, and has never been asked to.

There is a second reason to start here. A mechanical workflow gives you a clean baseline. You know how long it took before, how often it was wrong before, and what it cost. When the system goes live, the comparison is arithmetic rather than opinion, and the case for the next project writes itself.

What we leave alone in the first slice

The judgement step stays with the person doing it. Not permanently, and not out of caution for its own sake, but because the exceptions are where the domain knowledge lives. Six weeks of watching which exceptions a human resolves, and how, is the cheapest specification you will ever get for the second phase.

In practice this means the first release does the fetching, the matching and the flagging, then stops and asks. The operator's week goes from twenty hours to three. Nobody has to trust the model with anything irreversible, and the team gets a running system in weeks rather than a pilot in quarters.

A short test before you commit

Ask the person who does the work to describe it out loud while you write it down. If you can produce a numbered list they agree with in under twenty minutes, it is a good first candidate. If the description keeps branching into it depends, keep looking. That workflow is worth automating eventually, but not first.