How to Identify AI Use Cases: Start With the Problem, Not the Chatbot

Ask a weak candidate where AI could help their team, and the answer usually starts with the tool: "we should build a chatbot" or "we could add an AI assistant." Ask a strong candidate the same question, and the answer starts somewhere completely different: "three way invoice matching takes our team about four hours a week, and it follows a clear, repeatable pattern every time."

The difference is not enthusiasm or technical skill. It is where the thinking starts. A chatbot first pitch is solving for "how do we use AI" before anyone has established there is a real problem worth solving. A problem first pitch starts with a specific, measured pain point and only then asks whether AI is actually the right tool for it, which connects directly to the judgment covered in the earlier guide on when not to use AI.

This guide gives you a repeatable method for finding real AI use cases, starting from the problem every time, with a worksheet built directly into this post.

Why "start with the problem" separates real candidates from enthusiastic ones

By 2026, most companies hiring for AI enabled roles have already sat through a wave of chatbot first pitches, most of which went nowhere, because "let's add AI to this" is not a use case, it is an unfinished sentence. A real use case names a specific task, states how much time or cost it currently consumes, and explains why that specific task's pattern is a good fit for AI, in that order.

Employers have learned to specifically screen for this ordering because it predicts real outcomes. A candidate who leads with the tool tends to keep leading with the tool throughout a project, forcing problems to fit whatever they already know how to build rather than genuinely evaluating what a business actually needs. A candidate who leads with a measured problem tends to stay anchored to real value throughout, and is far more likely to actually ship something that gets used rather than something that gets demoed once and abandoned.

This is a specific, learnable discipline, not an innate talent, which is exactly why it shows up as a testable interview competency rather than something employers simply hope candidates already have.

There is a related, quieter reason this matters to a hiring manager specifically: a problem first candidate is easy to evaluate. A specific claim, this task takes four hours a week, can be checked, questioned, and either confirmed or corrected in the interview itself. A chatbot first pitch offers nothing concrete to evaluate, which forces the interviewer to either take enthusiasm on faith or press for specifics the candidate was not prepared to give, neither of which reflects well on the candidate.

Three signals of a genuinely strong AI use case

Three signals reliably separate a strong AI use case from a weak one, and all three should be present, not just one.

High volume, repeated task. A task done once a year, however painful, rarely justifies building and maintaining an AI solution. A task done daily or weekly, across many instances, is where automation and AI both earn their cost back quickly.

A clear pattern with a checkable right answer. This connects directly to the deterministic versus probabilistic distinction from the earlier guide on when not to use AI. A task with genuine structure, even if it requires judgment on messy inputs, is a good AI fit. A task that is different every single time, with no real pattern at all, is a poor fit for either AI or a script.

Real, measurable time or cost currently being spent. "This feels slow" is not a use case. "This takes four hours a week across two people" is. A real, specific measurement is what turns a vague sense of inefficiency into a defensible business case.

The five step method for finding real use cases

This method works whether you are looking for your first project idea or evaluating a team's workflow for a real opportunity.

1. Shadow a real workflow. Watch, or walk through yourself, an actual task from start to finish, rather than relying on a secondhand description of how it supposedly works.
2. Time each step. Note roughly how long each part actually takes, including the parts that feel routine, since routine, repeated steps are often the biggest hidden time cost.
3. Find the slowest repeated step. Not the most interesting step, the slowest genuinely repeated one, since that is where the real time is going.
4. Check if the pattern is clear enough for AI. Apply the three signals above, and the when not to use AI framework, honestly, rather than assuming every slow step is automatically an AI opportunity.
5. Estimate real hours or cost saved. A specific, defensible number, not a vague sense of improvement, turns a use case idea into something worth actually pitching.

A worked example: finding a use case in a real invoice workflow

Shadowing a procurement team's invoice processing for one day surfaces the following: an analyst spends roughly fifty minutes a day, across about twelve invoices, manually checking that each purchase order, invoice, and receipt match on vendor, amount, and quantity, the classic three way match. Across a five day week, that totals just under four hours on one specific, repeated, highly structured task.

Applying the three signals: volume is high, twelve invoices a day, every day. The pattern is exceptionally clear, three specific fields need to match within a defined tolerance, exactly the kind of deterministic, rule based task covered in the earlier guide on when not to use AI, meaning the real opportunity here may actually be a script rather than an AI model, an important, honest distinction a strong candidate makes rather than reaching for AI reflexively. The time cost is real and specific: four hours a week, which at a fully loaded cost estimate is a genuine, defensible number to bring to a business case.

This is exactly the finding that led one team to build a deterministic three way matching script rather than an AI tool, freeing the analyst's four hours a week for exception handling, the smaller, genuinely ambiguous share of cases that do benefit from AI's flexibility. The use case was real. The correct tool for it was not AI, which is itself the mark of a strong use case analysis, not a weak one.

Score effort against real value.

Once shadowing surfaces several candidate use cases, this simple two by two matrix, effort to build against real business value, helps prioritize which to pursue first. Low effort, high value use cases should almost always come first, since they build momentum and credibility quickly. High effort, high value use cases deserve real planning rather than being dismissed, but should rarely be the first project a new team or candidate takes on.

Practice these interview questions

Use case identification questions test whether you actually start from a real problem, or reach for AI because it's the fashionable answer. Work through your own answer first, then compare with the sample.