Most companies have plenty of candidates for AI and automation. The hard part is choosing the first one. This article provides a concrete method: four criteria, an example, the typical wrong choices and a checklist that can be used tomorrow.
In this article
The short answer
Choose a case that is small enough to be bounded, frequent enough that the value can be measured, and harmless enough that errors can be handled with drafts or approvals. The first case must prove the way of working, not transform the company.
It may sound obvious, but choosing a large, visible and complex case first is a common reason AI projects disappoint.
Why the first case decides the rest
The first AI case sets the standard for everything that follows: how data is handled, how approvals work, how value is measured and how confidently the organisation can proceed afterwards. A successful small case builds confidence, experience and a pattern that can be reused. An unsuccessful large case can undermine that confidence, sometimes for years.
Therefore, the most important choice is not the supplier or model, but the case itself. And the choice can be qualified with four simple criteria.
Four criteria for a good first case
- Value: time, quality, throughput or risk, that can be captured in a baseline. "It feels faster" is not a baseline.
- Complexity: how much of the task requires interpretation rather than fixed rules? Rule-heavy tasks can often be solved with classic automation, cheaper and more predictably.
- Data foundation: Does the necessary data exist, is the quality known, and can it be used for the purpose?
- Risk: what happens when the solution goes wrong? Not if, but when. Can the consequence be handled with drafts, approvals and logs?
Score the candidates roughly on the four axes, for example low, medium and high. The best first case is rarely the one with the greatest potential, but the one with the best balance: measurable value, known data foundation and manageable risk.
Three candidates, one choice: a worked example
Imagine three typical candidates in the same company:
- A. Automatic quotation writing for customers. High value, but high complexity, sensitive customer promises and direct external consequence in case of failure.
- B. Triage of shared mailbox. Medium value, bounded interpretation, data resides in the mailbox and case system, and errors are caught by an approval step.
- C. Chatbot on the website "for everything". Unclear value, open demarcation, no natural approval point and difficult measurement.
B wins not because it is the most impressive, but because it can be clearly scoped and measured, and because failures can be contained before they affect customers. A can become case number two or three when the working method has been proven, typically in a draft-based version with commercial approval reserved for a person. C is in practice a project without a success criterion.
Common mistakes
- Choosing the biggest pain first. It is usually also the most complex and politically sensitive.
- To start with an open chatbot "for everyone". Without a defined task and target group, neither quality nor value can be measured.
- To automate a process no one can describe. The obscurity does not go away; it is executed faster and more consistently.
- Skipping the data foundation. If the sources are scattered, undefined or not permitted for the purpose, that is where the work really starts.
- Building action from day one. Write actions without an approval design move risk directly into operations.
All five wrong choices have the same root: the case was chosen for visibility rather than measurability.
Who should be involved in the decision?
Three roles are necessary, regardless of the size of the company: the process owner, who knows the workflow in practice and can detect the exceptions; a decision maker who can prioritise and own the business case; and, for workflows involving several or business-critical systems, a person with insight into IT, access and data quality.
The employees who carry out the task today should also be involved early. Not out of politeness, but because the acceptance test is ultimately theirs: do they use the suggestions or work around them?
This is how you measure whether the case works
Determine the baseline before building: how long the task takes today, how often it fails, what impact the failures have, and who is using the time. Define few, concrete acceptance criteria for the pilot, for example the proportion of drafts that can be used without significant rewriting, or the time from inquiry to correct distribution.
Measure at the same points after an agreed period and decide in advance what to do if it succeeds, produces mixed results or fails: scale, adjust or stop. This makes the evaluation honest and the decision simple. A pilot who cannot fail is not a pilot.
From selection to pilot
A good pilot is read-only or draft-based: the solution reads approved sources and submits suggestions while humans decide. It removes most of the risk, while value and quality are measured on real tasks in real operation.
Only after the pilot has demonstrated its value against the baseline should the system authority be expanded step by step: more sources, more users or controlled write actions with approval. Each step is a decision with documentation, not a slippery slope.
The data foundation determines more than the model
Before locking down the case, three data questions are more important than any technology choice. Is the data available: are the inquiries, documents or measurements somewhere, can a solution read them? Is the quality known: are the fields filled in the same, and does the same number mean the same in all systems? And may they be used: is there personal data, customer data or confidentiality that requires clarification of access, storage and deletion?
An honest no to one of the three is not a stop, but a reprioritization: the first deliverable should then be a defined piece of data-foundation work rather than an agent. It is less expensive to identify this before implementation than afterwards.
After the pilot: scale, adjust or stop
A pilot ends with a decision, not with a demo. If the pilot succeeds against the baseline, scale in a controlled way by adding more users, more sources or the next workflow while retaining approvals and logging. In case of mixed results, one thing at a time is adjusted, typically data quality, instructions or scope, and measurements are taken again. In case of failure, the case is stopped and the learning is documented: what was missing and which candidate is next?
The most important output of the first case is rarely the solution itself, but the pattern: a tested path from idea, through baseline and pilot, to a decision, which can be reused on cases two and three with far less friction.
Short checklist
- Can the case be described on one page: task, users, input, output?
- Is there a baseline or can it be established quickly?
- Are the data sources designated and may they be used for the purpose?
- Is the consequence of an error manageable with draft or approval?
- Is it agreed who owns the decision after the pilot?
If you can answer yes to the five, the case is probably good enough to start. If you can't, a structured mapping of the workflow is the right first step before investing in development.
Also read
More opportunities than clarity?
An Automation Audit maps workflow, data and risk and delivers a prioritised case list so that the first investment is focused on the right opportunity.
Assess a workflow →