Buying an artificial intelligence tool does not turn a confusing process into a reliable one. If the team does not share a consistent way of working, exceptions live in private messages, and nobody knows what to do when something fails, technology will only accelerate one part of the disorder.

The useful question is not “where can we add AI?” but “which workflow is worth changing, what result do we expect, and how will we stay in control?”. This framework helps answer it without promising savings before they have been measured.

1. Describe the real process, not the ideal procedure

Start with one specific, recent case. Follow a request from the moment it arrives until it is resolved: who receives it, what information they consult, which decisions they make, which tools they use, and what they hand to the next step. Official instructions often omit shortcuts, waiting time, and corrections. Observing a real case brings those details into view.

The initial map can be simple. For each step, record the input, action, output, owner, tool, and waiting time. Add a marker whenever somebody has to interpret information, request missing data, or make a decision outside the usual rule.

You do not need to model the whole company. A workflow with clear boundaries is enough: from receiving a request to classifying it, for example, or from receiving an invoice to preparing it for review.

2. Score six criteria before setting priorities

A matrix will not make the decision for you, but it forces the team to compare candidates using the same language. Score every process on a short scale—low, medium, and high is usually enough—and keep the evidence behind each score.

  • Frequency and volume. How often does the workflow run, and how does demand fluctuate? A frequent process offers more opportunities to learn, but volume alone does not justify automation.
  • Stability. Do the steps and rules repeat, or do they change every week? Automating a rule that is still moving usually transfers the rework into the system.
  • Exceptions. What share of cases requires context, negotiation, or special approval? Record the type of exception, who resolves it, and how it returns to the workflow.
  • Information quality. Are the inputs available, readable, and consistently understood? If data is missing or teams use different categories, that debt belongs in the scope.
  • Impact and risk. What happens if the system is wrong, late, or unavailable? Increase oversight when customers, money, security, rights, or compliance may be affected.
  • Reversibility. Can you stop the workflow, recover the previous state, and continue manually? A first pilot needs a practical exit, not merely a theoretical backup.

The conclusion does not have to be “automate” or “do not automate”. It may be better to document the work first, simplify a rule, improve data capture, or build an assistant that helps a person make a better decision.

3. Separate conventional automation, AI assistance, and human decisions

Many operational problems do not need AI. When inputs are structured and rules are explicit, an integration, validation, or deterministic workflow is usually easier to test and maintain.

AI may be useful when a task involves classifying text, extracting information from documents, summarising, drafting a proposal, or detecting patterns. In those cases, a successful demonstration is not enough. The team must define test data, a minimum acceptable quality level, edge cases, and what the responsible person will do when the output is uncertain.

The NIST AI Risk Management Framework recommends establishing context and intended purpose, defining a targeted scope, and documenting human oversight. The same discipline is useful for a small pilot: first understand where the system will operate, then measure whether it is appropriate.

The GAO AI Accountability Framework organises practices around governance, data, performance, and monitoring. In operational terms, someone must own the outcome, the data must be suitable, behaviour must be evaluated, and monitoring continues after launch.

4. Choose a pilot that can learn—and stop

The best first process is not always the one with the largest potential impact. Choose something valuable enough for the learning to matter, yet contained enough to observe, correct, and reverse without putting the operation at risk.

Before work begins, write down:

  1. Where the workflow starts and ends, including the cases that are out of scope.
  2. The process owner and the person authorised to stop the pilot.
  3. The baseline and the result you will observe: cycle time, rework, detected errors, deadline compliance, or review workload.
  4. The sample used for testing, including normal cases and known exceptions.
  5. The human checkpoint and the criteria for accepting, correcting, or rejecting an output.
  6. The rollback procedure and how traceability will be preserved.

Do not turn a hypothesis into a commercial promise. A pilot exists to produce evidence in your context. Only then can you decide whether to expand, redesign, or retire the solution.

5. Use a simple decision matrix

You can arrange candidates into four practical zones:

  • High repetition and few exceptions: a strong candidate for deterministic automation.
  • High repetition with identifiable exceptions: a candidate for a hybrid workflow, with explicit rules and escalation to a person.
  • Unstructured information with a verifiable outcome: a possible AI-assisted task, with evaluation and clear limits.
  • A changing process with no owner or consequences that are difficult to reverse: clarify the process and its governance first.

The matrix is a starting point, not a universal formula. Adjust the weight of each criterion to the risk of the process, and document why one candidate moves ahead of another.

Checklist for the first conversation

  • One real, anonymised example of the workflow.
  • Approximate volume and changes across periods.
  • A list of exceptions and current owners.
  • The systems involved and their access constraints.
  • Errors or delays that can already be observed.
  • The consequence of an incorrect output.
  • The baseline metric and the criterion for stopping the pilot.
  • Data that must not leave the authorised environment.

With this information, the conversation changes. It is no longer about buying AI; it is about deciding which part of the work should be redesigned, which technology is sufficient, and which controls the team needs.

Start with a process, not a tool

If you have several candidates, select two or three and compare them using the six criteria. The purpose of the first session is not to lock in a solution. It is to identify the workflow that can generate useful learning with controlled risk.

Codiloop can help you prepare an automation assessment around one concrete process, its exceptions, and the signals you can already measure.