Engagement type
How to choose which AI use case to build first
Last updated
Justas Butkus is a fractional AI officer based in Vilnius, Lithuania, working with mid-market companies and scale-ups across the UK, EU and US. Every engagement begins with a fixed-scope diagnostic, runs on written milestones rather than hours, and leaves accounts and documentation in the client's hands throughout.
Short answer
Rank candidates by frequency multiplied by fully loaded cost per occurrence, then discount by how much is genuinely automatable. The right first project is almost always boring, high-volume and unloved. If your shortlist is exciting, it was selected for demonstration value rather than economics.
What is the arithmetic?
- Find the repeating processConstant, consuming qualified people, and nobody enjoys it. Usually intake, triage, chasing, checking or re-keying.
- Cost one occurrence, fully loadedSalary plus overhead divided by realistic throughput, including the ones handled late or badly.
- Multiply by annual frequencyThis is where people are surprised: nobody experiences the annual number, only the few minutes.
- Discount by the automatable shareHonestly. A realistic share of a large number beats an optimistic share of a small one.
- Compare against the whole cost of the workSpecification, build, oversight and running costs together. If the gap is not obvious, the candidate is wrong.
Why is the exciting use case usually wrong?
Because it was selected backwards. Somebody saw a demonstration, and the justification was assembled afterwards to fit it. The resulting system works and nobody misses it when it stops.
The second reason is compounding difficulty. An ambitious first project means learning how to operate AI systems at the same time as attempting the hard part of the use case. Doing both at once is what produces the pilot graveyard.
What disqualifies a candidate?
- Low frequency. However expensive each occurrence, if it happens rarely the annual number will not carry the work.
- Inconsistent data definitions. If the same field means different things in different systems, fix that first – a model will learn the inconsistency faithfully.
- No owner willing to go live. If nobody will accept the risk, the build produces a permanent pilot.
- A process problem wearing a technology costume. If the process is broken, automation makes it faster and no better.
Frequently asked questions
How do you choose the right AI use case?
Rank candidates by annual frequency multiplied by fully loaded cost per occurrence, discount by the share genuinely automatable, then compare against the total cost of specification, build and running. The winner is usually a boring, high-volume process.
Why do AI pilots fail so often?
Mostly selection: the process was chosen because it demonstrated well rather than because it was expensive. The other two causes are data definitions that differ across systems, and nobody willing to accept the risk of going live.
Should the first project be ambitious?
No. The first one should prove the pipeline end to end – specification, build, evaluation, oversight, rollback – on something low-stakes. Starting with the ambitious case means learning to operate AI and attempting the hard problem simultaneously.
If this is the piece you need
It is a bounded piece of work with a defined deliverable, which makes it quick to scope.