How to choose your first AI workflow

Every AI programme starts with the same question, and it is the right one: where do we begin?

The usual answer is a workshop. Forty ideas on sticky notes, scored on impact and effort, plotted on a two-by-two. It feels like progress and it produces a decision, but both axes are guesses. Effort is unknowable before anyone has looked at the data, and impact is a number the room invents to justify the ranking it already prefers.

The workflows that survive to production are rarely the ones that score highest in that room.

Three criteria that reliably pick the wrong workflow

The most visible one. The process the executive team sees weekly. It is chosen because success would be obvious, which is exactly why it is the wrong first system: high visibility comes with the lowest tolerance for the error rate a first deployment actually has.

The most painful one. The thing everyone complains about. Usually it is painful for reasons that have nothing to do with automation — ambiguous rules, contested ownership, a data source three teams disagree about. AI does not resolve any of those. It inherits them.

The most impressive one. The workflow that demonstrates well. Demos have no edge cases, no angry customer, no malformed input, no Friday afternoon. A workflow selected for how it presents is selected on the one dimension production does not care about.

Four questions that predict better

Ask these in order. Any no is a reason to choose a different workflow, not a reason to push harder — a no here is the cheapest information you will get all year.

Is there a named owner?

Not an executive sponsor. The person whose own work changes when this ships, who can approve a change to how it is done, and who can be asked six weeks later whether it is actually being used.

Workflows without that person do not fail loudly. They get built, demonstrated, congratulated, and quietly not adopted, because nobody's job description changed.

Does the work already happen the same way twice?

If two experienced people do it differently and both are right, there is no workflow to automate yet. There is a decision the organization has not made.

This is worth sitting with, because it is the most common hidden blocker. Teams describe a process in a meeting, everyone nods, and then the first ten real examples turn out to have been handled six different ways. You cannot encode a rule that does not exist. Making the decision is the work, and it is worth doing whether or not AI is involved.

Can you see the inputs?

Not "does the data exist" — it always exists. Can a system read it, today, with permissions someone can actually grant?

Data access is where more promising first workflows die than anywhere else, and it dies late, after the design is agreed and the enthusiasm is spent. Find out in week one. A workflow with mediocre value and clean access beats an excellent one behind a system nobody will open.

Is a wrong answer survivable?

Your first system will be wrong sometimes. That is not a reason to avoid it; it is a constraint on where to put it.

Choose work where a mistake is caught before it reaches a customer, visible when it happens, and recoverable without a phone call. That usually means a human reviews the output before it commits — which is not a limitation of the first version, it is how the workflow should be designed regardless.

What a good first workflow looks like

Put together, the profile is unglamorous and consistent: happens often, matters moderately, has clear inputs, has one owner, and produces something a person can check.

High frequency matters more than high stakes, for two reasons. You get enough examples to evaluate properly within weeks rather than quarters, and the people involved encounter the system often enough to form a habit rather than forgetting it exists.

Before you build: capture the baseline

Whatever you choose, measure the current state before anything changes. How long it takes now, how often it is reworked now, how many cases per week now.

It is unglamorous, it delays the interesting work by about a week, and skipping it is the single most common reason a successful AI project cannot prove it succeeded. Without a baseline you are left comparing the new system against people's memory of the old one, which is generous when the project is popular and brutal when it is not.

The first workflow is not the one that matters most. It is the one that teaches you the most, for the least risk, in the shortest time — and leaves you able to choose the second one from evidence instead of a two-by-two.