Most first AI projects get picked because they demo well. A chatbot on the homepage. A tool that writes social captions. Something you can show the team in a meeting. Six weeks later the chatbot answers questions nobody asks, and the thing that actually drains your week (rebuilding the same quote from scratch, retyping intake forms into your CRM) is still done by hand.

The first use case is a diagnostic decision, not a technology decision. You are not asking what AI can do. You are asking which repeated task in your business costs you the most and tolerates being done imperfectly the first few times.

Start with the task you already do too often

Good first candidates share a shape. They happen many times a week, follow roughly the same steps each time, produce an output someone can eyeball in seconds, and already leave a paper trail you could hand to a model.

Spend a week writing down every task that gets repeated. Not a formal audit. A running note on your phone, plus the same note from two or three people who do the operational work. You are looking for the tasks that never make it onto the calendar because they are assumed: the follow-up email, the weekly numbers pull, the copy-paste from inbox to spreadsheet.

Score candidates before you build anything

Once you have a list, rank it on five dimensions. Do this on paper. It takes twenty minutes and it kills most bad ideas for free.

• Frequency: How many times a week does this happen? Once a quarter is not a use case, it is a chore.
• Time per instance: How long does one pass take, including the context-switching to get into it?
• Cost of being wrong: If the output is off, does someone catch it in ten seconds, or does it reach a customer, a contract, or a bank account?
• Data on hand: Do the inputs already exist somewhere readable (past emails, tickets, docs, a spreadsheet), or would you have to create them first?
• Owner: Is there one named person who does this task today and will judge whether the output is good enough?

The winner is usually the boring one: high frequency, moderate time, low cost of error, data already sitting in a tool you pay for, one clear owner. Not the most impressive item on the list. The most repetitive one.

Where first use cases usually hide

For most small teams, the strong candidates cluster in a few places:

• Intake and triage: Sorting inbound requests, tagging them, routing them to the right person, flagging the urgent ones.
• First drafts: Proposals, follow-up emails, job descriptions, scope documents. The draft is the slow part. Editing is fast.
• Summarizing: Turning a call recording, a long thread, or a stack of notes into the three lines someone actually needs.
• Internal lookup: Answering "what did we quote them last time" or "what is our policy on this" without anyone digging through folders.
• Structuring messy input: Pulling names, dates, and amounts out of unstructured text and putting them into fields.

Notice what these have in common. A human still makes the decision. The tool removes the setup work in front of the decision.

Four filters that eliminate bad candidates

Before you commit, run your top choice through these:

• Can you describe the correct output in one sentence? If you cannot, neither can a model, and neither can whoever reviews it.
• Is the underlying process already broken? Automating a process nobody agrees on just produces disagreement faster. Fix the sequence first, then automate it.
• Is it rare and high-stakes? Rare means you cannot iterate. High-stakes means you cannot afford to. That combination belongs later, not first.
• Will anyone actually use it? If the person who owns the task did not ask for help with it and does not want the change, adoption will quietly go to zero.

Design the pilot so it can fail cheaply

Scope the first attempt to one task, one owner, and a fixed window of two to four weeks. Before you start, write down the baseline: how long the task takes now, how often it is done, and where it currently goes wrong. Without that number you will have no way to tell whether anything improved, and you will end up arguing about impressions.

Keep a person in the loop for the entire pilot. The output gets reviewed before it goes anywhere, every time. This is not a temporary safety measure you rush past. It is how you find out what the tool consistently gets wrong, which is the only information that tells you whether to expand, adjust, or stop.

Write your kill criteria in advance, too. Something like: if the owner is still rewriting more than half the output at the end of week three, we stop and pick a different task. Deciding that upfront is much easier than deciding it while defending a project you have grown attached to.

How to tell whether it worked

Judge the pilot on four things, in this order:

• Time returned: Is the owner spending measurably less time on the task than your baseline?
• Edit rate: How much of the output survives review unchanged? A falling edit rate over the pilot is the strongest signal you have.
• Throughput: Are more of these getting done, or done sooner, than before?
• Voluntary use: Does the owner reach for it when nobody is watching? This is the one that predicts whether it still exists in six months.

If the answers are good, the natural next step is the task immediately upstream or downstream of the one you just handled. That is how a first use case turns into a system instead of a one-off experiment.

FAQs

What should my first AI use case be?

The most repetitive task in your business that has a clearly correct output, existing data, and a low cost of being wrong. In practice that is often drafting, triage, summarizing, or moving information between tools.

How do I know if a use case is feasible?

Ask three questions: do the inputs already exist in readable form, can you describe a correct output in one sentence, and is there a named person who will review the results. If any answer is no, the use case is not ready yet.

How long should a first pilot run?

Two to four weeks on a single task is usually enough to see whether the edit rate is falling and whether the owner is using it without being reminded. Longer pilots tend to blur into normal operations before anyone decides anything.

Should I start with a customer-facing tool?

Usually not first. Internal tasks let you learn where the output breaks without a customer absorbing the mistake. Once you know the failure patterns, customer-facing work becomes a much safer second step.

What if the pilot fails?

A pilot that fails in three weeks against a written baseline is cheap information. It tells you the task was a poor fit, the process underneath needs work, or the data was not there. Move to the next candidate on your scored list rather than scaling the disappointment.

Conclusion

The wrong first use case is almost never the one that was technically too hard. It is the one that was too rare, too vague, or too disconnected from anyone's actual week. Score your candidates, pick the boring repetitive one, keep a person reviewing the output, and set the conditions for stopping before you start. That sequence is what separates a working system from an expensive demo.

Visuals