Skip to content
All insights

Implementation

The first workflow decides whether there is a second.

Most organizations pick their first AI workflow on enthusiasm: the one somebody is most frustrated by, or the one that would impress the board. Both are bad selection criteria, and the cost of getting it wrong is the whole program.

Published March 24, 20266 min read

What this covers

  • Score candidates on volume, whether the rules can be stated, whether the data is reachable and whether the outcome is defined.
  • Frequency beats complexity. A dull workflow that runs 300 times a month beats an interesting one that runs twelve.
  • The biggest pain point is usually the worst first choice, because pain is often caused by the absence of a rule.
  • Decide what success looks like, in a number, before anything is built.

There is a pattern in how automation programs end. The first project is chosen because it is the thing everyone complains about. It turns out to be complicated for reasons nobody anticipated. Eight months later it half works, the sponsor has moved on, and the organizational conclusion is that this technology is not ready.

The technology was usually fine. The selection was the error, and it is avoidable with about two hours of honest assessment.

Four criteria, scored

Take every candidate workflow and score it one to five on each. A workflow that scores below three on any one of them is not the place to start, whatever its total.

CriterionWhat a five looks likeWhat a one looks like
VolumeHundreds of cases a month, every monthA handful, seasonally
Rules can be statedSomebody can write down what makes a case correct, and others agreeEvery experienced person answers differently
Data is reachableLive access to the records the decision needsThe authoritative version lives in a spreadsheet on a laptop
The outcome is definedThe work ends in a specific record in a specific stateIt ends with somebody taking a look

The second criterion is the one that is most often scored generously. The test is not whether a rule exists in principle. It is whether two experienced people, asked separately, give the same answer to the same edge case. If they do not, the rule does not exist yet, and the deployment's first job is to create it.

Four traps

The biggest pain point

The most painful process in a business is frequently painful precisely because nobody has agreed how it should work. That makes it the worst possible first automation: you are asking software to apply rules that the organization has been avoiding writing down, sometimes for political reasons. Fix the process, then automate it.

The most interesting workflow

Technically interesting usually means high variance and low volume, which is the opposite of what pays back. The first project should be slightly boring. Boring means predictable, and predictable means it finishes.

The one that touches everything

A workflow spanning six departments requires six sets of agreement before anything ships. Sequencing matters more than scope: a narrow workflow that goes live in weeks builds the credibility that a broad one needs and does not have.

The one nobody owns

If no single person is accountable for the workflow's outcome, nobody can set the approval thresholds, nobody can decide the tolerances, and nobody will defend the project when it needs defending. An unowned workflow is not a technical problem, but it will fail for a human one.

Pick the workflow that is high volume, well understood, owned by one person, and slightly dull.

Why quoting and order entry usually win

Across distributors, manufacturers and B2B service firms, the same two workflows tend to top the scoring, and it is not a coincidence.

  1. 01Volume is high and constant rather than seasonal.
  2. 02The rules exist in a written form already, as contract pricing and order entry requirements.
  3. 03The data has to be reachable, because people are reading it manually today.
  4. 04The outcome is unambiguous: a quote sent, a sales order created.
  5. 05Both have a commercial story, not just a cost story, which makes the project easier to sponsor.

Invoice processing scores similarly on the first four and differently on the fifth: the case is a control and accuracy case rather than a revenue one. That is not weaker, it is just argued to a different audience.

Decide what success is, first

Before anything is built, write down the number that would make this worth repeating, and where it will be read from. Not a percentage from a vendor's deck. A measurement from your own system.

  • Baseline: measure it now, before deployment, or you will be arguing about it later.
  • Target: what would make this obviously worth doing, stated as a number.
  • Source: which system the figure comes from, so nobody constructs it afterwards.
  • Review date: when you will look, and who will be in the room.

Elapsed time is usually the better first metric than the automation rate, because it is what the customer experiences and it is harder to game. Building the business case goes further into which numbers hold up.

The two-hour version

If you do nothing else: list your candidate workflows, score them on the four criteria, strike anything scoring below three on any one, and from what remains pick the highest volume workflow with a single named owner. Then take ten real cases from last month and trace them end to end, timestamp by timestamp.

That trace is what a Workflow Review produces, and it is worth doing whether or not anything gets automated afterwards.

Questions

Questions we get about this.

Should we start with the process that causes the most complaints?

Usually not. Processes are often painful precisely because nobody has agreed how they should work, which means an automation would be applying rules the organization has been avoiding writing down. Fix the rule first, then automate.

How much volume is enough?

There is no universal threshold, but frequency matters more than complexity because setup cost is amortized across cases. A workflow running hundreds of times a month is a better first candidate than a more interesting one running a dozen times.

What if our rules are not written down?

That is common and it is worth knowing before a build rather than during one. The test is whether two experienced people, asked separately, give the same answer to the same edge case. Where they do not, establishing the rule becomes the first piece of work.

Can we automate more than one workflow at once?

You can, and it usually slows both down. A narrow first workflow that goes live quickly builds the credibility and the shared foundation that makes the second one cheaper, which is a better sequence than two parallel builds.

What should we measure?

Decide before anything is built: a baseline measured now, a target stated as a number, the system the figure will be read from, and a review date. Elapsed time is usually a better first metric than automation rate, because it is what the customer experiences.

See what this would look like in your operation.

A Workflow Review traces one of your real workflows end to end and names the first step an agent could take over. No platform to evaluate first.

Start with one workflow

Fixed scope for the first workflow, agreed before we start. Expansion is your decision once it proves value.

How it works

Security, stated plainly

Where the agents run, what they can and cannot do, and exactly what we do and do not claim.

Security