Should the first use case be customer-facing?

Usually not. Customer-facing AI is visible but riskier and harder to measure. A contained internal workflow gives cleaner proof and faster ROI.

How many use cases should we start with?

One, done end-to-end. One strong concept shipped and measured beats a dozen pilots that each only prove a model can technically do something.

What if our data isn't ready?

Then data readiness is your first project. A model is only as reliable as the data feeding it; siloed data is fine for a pilot and fatal at scale.

Who should own the first use case?

One accountable person who owns the outcome metric — not just the rollout. Shared ownership across functions is how a promising use case quietly stalls.

← Guides

guides 10 June 2026 2 min read

How to choose your first AI use case

Diego Santana

To choose your first AI use case, ignore what demos well and find the highest-friction, highest-volume, lowest-glamour workflow in the business — the one everyone complains about and no one wants to present. Define its outcome metric before you build, rebuild it AI-first end to end, ship a thin production slice, and measure. That sequence is how a first use case becomes proof instead of another stalled pilot.

Why visibility is the wrong filter

MIT found that more than half of generative-AI budgets go to sales and marketing — the most demo-able work — while the biggest measured ROI sits in back-office automation: eliminating outsourced process work, cutting agency costs, and streamlining operations. Companies spend where the slides look good, not where the money is. Picking your first use case by visibility is the single most common way to walk straight into the AI implementation gap.

A simple scoring rubric

Score each candidate 1–5 on five dimensions. The winner is rarely the flashiest; it's the one that is repetitive, measurable, and quietly expensive.

Volume — does it happen often enough that improvement compounds?
Friction — is it slow, error-prone, or universally disliked?
Measurability — can you state the outcome metric in cash or time?
Data readiness — does usable, integrated data already exist?
Containability — can you ship a thin slice without boiling the ocean?

Worked scoring example

The pattern is consistent: the unglamorous back-office workflows score highest because they are frequent, measurable, and contained — exactly the traits a first project needs to produce proof.

Define the metric before you build

A use case without a pre-agreed outcome metric becomes a pilot that can never justify scaling. Decide, up front, the single number that will move — handling time, cost per transaction, error rate, throughput — and who owns it. "We deployed it" is an activity; "it cut handling time 31%" is an outcome. Pilots optimize for the first; impact requires the second.

Then decide how to build it

Once the use case is chosen, the build-vs-buy line is usually obvious: rent the commodity layers, build the workflow that is your moat. And approach the redesign AI-first, not as a feature bolted onto the existing process.

Common mistakes to avoid

Starting with the most visible use case instead of the most valuable.
Running several pilots at once so none gets the focus to reach production.
Choosing a workflow whose data isn't ready, then blaming the model.
Shipping without a metric, so success can't be proven and scaling can't be funded.

FAQ

Should the first use case be customer-facing?: Usually not. Customer-facing AI is visible but riskier and harder to measure. A contained internal workflow gives cleaner proof and faster ROI.
How many use cases should we start with?: One, done end-to-end. One strong concept shipped and measured beats a dozen pilots that each only prove a model can technically do something.
What if our data isn't ready?: Then data readiness is your first project. A model is only as reliable as the data feeding it; siloed data is fine for a pilot and fatal at scale.
Who should own the first use case?: One accountable person who owns the outcome metric — not just the rollout. Shared ownership across functions is how a promising use case quietly stalls.