How to choose your first AI use case so the company sees a return
Many companies start an AI rollout with a tool or a flashy demo. Then it turns out there is no process owner, no data, and no agreement on what success looks like. ROI does not depend on whether you pick Claude Opus 4.6, Grok 4.5, ChatGPT, or something else. What matters is choosing a problem that already creates a measurable cost or blocks customer value, and running the first project so it changes a business outcome, not just looking modern.
In this article, we walk through how to do that.
Key Points
- An impact × feasibility matrix is a solid start: go first for high impact and high feasibility.
- Companies that cannot name the business value often end up with an abandoned proof of concept.
- Before you buy a tool or build a pilot, define the baseline, the target, and the cost of the rollout.
What the numbers say about choosing a use case
Hard data shows where companies most often get stuck when picking and shipping a first AI use case.
| Statistic | Takeaway: what to do |
|---|---|
| According to Gartner, by the end of last year at least 50% of GenAI projects were abandoned after the proof of concept. Reasons: poor data quality, weak risk controls, rising costs, or unclear business value. | Do not start with a demo. Start with a process where you can name the value: hours, errors, cycle time, lost conversion. If you cannot write that down before you start, it is not a candidate for your first use case. |
| In a Gartner survey of infrastructure and operations leaders, only 28% of AI use cases fully meet ROI expectations, and 20% fail outright. A common theme: scope that is too ambitious or poorly chosen. | Keep the first project narrow. One closed process beats “AI across the company.” Leave the ambitious transformation for later, once you have proof you can deliver a result. |
| In the same study, leaders who had a failed rollout most often pointed to missing team skills (38%) and weak or unavailable data (38%). Gartner also forecasts that through 2026 companies will abandon 60% of AI projects that lack AI-ready data. | Before a slide deck wins everyone over, verify real access to data and context for that one process, and name the person who will own the outcome. A use case with beautiful impact but messy context is a trap. |
Start with the matrix: impact and feasibility
Take the list of ideas circulating in the company and plot them on two axes.
Business impact answers: how much does this process cost today, or how much customer value / business outcome do you lose to errors, delays, and scale limits. Look for things you can roughly quantify: time from request to response, rework rate, incomplete proposals, conversion, ability to handle more volume without growing the team in lockstep. “Hours saved per week” is a useful leading metric, but it should not be the only argument for the choice.
Feasibility answers: can you deploy AI here in your current situation. Look at data access, number of systems to integrate, regulatory risk, dependence on one person, and whether a repeatable process already exists, not only knowledge locked in someone’s head.
Candidates for the first use case sit in the high impact / high feasibility quadrant: real value at a reasonable difficulty. Do not start with something mega-hard just because “if it works, it will be wow.” Everything else can wait.
- High impact, low feasibility: big upside, hard to deliver (missing data, access, or an owner). Park it or remove the biggest blocker first.
- Low impact, high feasibility: easy to ship, little business value. Fine for a demo, weak for convincing decision-makers.
- Low impact, low feasibility: skip it.
“If the first argument for adopting AI is ’employees will save a bit of time,’ you have probably picked the wrong use case. Companies do not build lasting advantage on someone writing an email five minutes faster. The biggest return shows up when AI helps the company deliver more value to the customer: answering needs better, offering something that was not possible before, or doing it at a scale that used to be out of reach. A good AI use case should change the value delivered to the customer or a business outcome, not only tidy up a single task.”
Marcin Byrdziak, CTO at Pragmatic Coders
How do you know the use case will deliver a real return, not just look good on a slide?
Once you have a shortlist from the matrix, pressure-test every candidate against the same criteria. No clear answer on any of them means: it is out as a first use case.
1. What is the baseline, and how will you know you succeeded?
Before you start, write down today’s numbers (time, errors, handling time, rework) and a concrete, measurable goal for 6-8 weeks, for example: cutting proposal prep from 4 hours to 90 minutes, dropping rework from 25% to under 10%, or handling more tickets per week without growing the team. Success is not an opinion (“people are happy”) or finishing a PoC. If nobody measures the process today and nobody plans to collect data for even two weeks, AI will not fix a lack of control.
2. Who owns it, and who will use it day to day?
You need a named person (not a committee) who owns the pilot’s business outcome, defines success, and makes sure the result lands in real work: a ticket queue, proposals, support. Separately, name someone accountable for quality, feedback, and edge cases. If ownership is fuzzy or sits only with IT, the project usually ends as a demo.
3. Will data or context be available within about two weeks?
You do not need a data warehouse. You need current sources for that process: folders, spreadsheets, CRM, procedures, knowledge base, ticket tables, templates.
What not to pick as your first use case
Some ideas look great on slides and make a weak first step.
- “We’ll save five minutes on every email.” If the time saving does not translate into a better customer response, more scale, or a business outcome, you are not building advantage.
- A website chatbot “because everyone has one.” Without a measured question volume, answer quality, and cost to serve, you have nothing to measure return against.
- Full automation of hard judgment calls. Start by assisting: draft, ranking, suggestion, quality check. Increase autonomy only once the effect is stable.
- Rebuilding five systems at once. That is a transformation program, not a first use case. Split the scope or park it.
- Success = a demo for the board. A demo builds mood. Return shows up in the numbers after weeks of work on real cases.
- “AI is a company-wide topic.” Everyone’s topic is usually nobody’s topic. A first use case needs a narrow owner and a narrow process.
Next Steps
If the shortlist is empty or every idea breaks on data, ownership, or scope, fix the foundations for that one process first. Do not build a data lake “just in case.” And if you want a second pair of eyes on choosing the first use case, you can book a short diagnostic call.
Conclusion
Take one narrow process, write the numbers down before you start, and treat the pilot as proof that you can work with AI in your company. Only that proof should unlock the next investments.
