Buyer guide

Choosing the first AI workflow to automate, and the one to leave alone.

Start with a workflow that is frequent, rule-bound, cheap when it is wrong, low in data sensitivity, and reviewable by a person before anything takes effect. Score the candidates on those five points and take the highest, even if it is the least exciting.

Written for Owners and operations leads deciding where AI belongs in the business, and anyone asked to justify a first AI project to a partner, a board or a regulator.

The method

  1. List the candidates as workflows, not as departments.

    "Answer the first line of every support ticket" is a workflow. "Use AI in support" is a wish. Ten to twenty candidates is normal for a firm of a few hundred people.

  2. Score each candidate on five points, from one to five.

    Volume: how often it runs. Rule clarity: how much of it can be written down as rules today. Cost of a wrong answer: what a mistake costs and how quickly you would notice. Data sensitivity: what data the workflow touches and where that data is allowed to be processed. Reviewability: whether a person can read the output and approve it before it has an effect.

  3. Prefer high volume, clear rules, cheap mistakes, low sensitivity and high reviewability.

    A workflow that scores low on reviewability is the one to leave alone, whatever it scores elsewhere. The first project is there to build the review habit, not to remove it.

  4. Define the approval step before choosing a model.

    Write down who reviews the output, what they see, how long they have, and what happens if they do nothing. If that person does not exist yet, the workflow is not ready.

  5. Set the stop condition.

    Decide before you start what result would make you switch it off, and how you would switch it off without losing the records it produced.

  6. Run it for a fixed period against a comparison.

    Keep the old way running alongside for an agreed number of weeks and compare outcomes you can count: time to complete, corrections needed, exceptions raised. Decide at the end of the period, not during it.

The checklist

What to have in place, or to have asked for, before you decide. Each line is something you can point at.

  • Candidates written as workflows with a start, an end and an owner.
  • Each candidate scored on the five points, with the scores kept.
  • The chosen workflow scores high on reviewability.
  • A named reviewer, what they see, and their time window.
  • What the reviewer does when the output is wrong, and where that correction is recorded.
  • The data the workflow touches, where it is processed, and who approved that.
  • A stop condition written down before the first run.
  • A comparison period with the counts agreed in advance.
  • A way to switch the workflow off that keeps its records.
  • Who outside the team will be told, and what they will be shown.

Questions to ask

Ask these of any vendor, including us, and of any internal team proposing the work. A vague answer to any of them is an answer.

  1. What happens when the model is wrong, and who notices first?
  2. Where is the approval point, and can it be bypassed?
  3. What data leaves our environment, where is it processed, and is any of it retained?
  4. Is an AI-generated record marked as such, with its confidence and its reason attached?
  5. What is logged about the workflow's own decisions, and who can read that log?
  6. Can we switch it off without losing what it produced?
  7. What would you measure in the first eight weeks, and what result would make you stop?
  8. Which parts of this are built today, and which are planned?

Related products, and where each one stands

← All guides