How to Find Your First AI Use Case

A company wants to use AI, so someone opens a document (often a shared one) and starts collecting ideas. A support chatbot goes near the top, followed by meeting summaries, proposal writing, sales research, and an assistant that can answer questions about company documents. Within an hour, the list looks quite convincing.

We’ve been in versions of this conversation, and the ideas are rarely bad, but they are answers to a question nobody has asked yet. Without a recent problem in front of us, almost any capable tool can sound useful, while the harder question of what would actually change inside the business remains conveniently abstract.

There is a less exciting way to find your first AI use case. If you’re looking for one, the most useful starting point is usually a recent piece of work that arrived late, came back for correction, or needed help from the same busy person as usual. Once you’ve followed it from the original request to the moment somebody finally considered it done, you’ll probably find a place where the work waited, and that delay gives the AI conversation something real to explain.

It sounds almost too ordinary to be an AI strategy.

We think that is a feature.

An eight-minute job that takes two days

A quotation needs a manager’s approval before it can go to a customer, and the manager spends about eight minutes checking the price, the discount, and whether the promised delivery date is realistic. The quotation, however, usually takes two days to come back.

If we describe the problem as “quotation approval is slow,” there is a natural response: make the approval faster. A model could read the request, check it against past deals, and recommend a decision in four minutes instead of eight, which would make for a tidy demonstration while saving four minutes in a process where the customer has already waited for two days.

The arithmetic is obvious once it’s written down, but the mistake is easy to make because process diagrams show the steps and hide the time between them. A box labelled “manager approval” looks like eight minutes of work, but it doesn’t show that the salesperson sent the request at 11:20 on Tuesday, that the price was missing, that the manager asked about it at 4:45, or that the reply didn’t arrive until Wednesday morning. The eight-minute task is sitting inside a much longer story (and the story is where most of the delay lives).

This is why we prefer a slightly awkward question when looking for an AI use case: what waited last week?

People can usually name an example once the question is asked this way: a lead sat untouched because only one person knew which questions to ask, a weekly report waited for three spreadsheets to agree, or a customer request moved from email to chat and then into the CRM, losing one important detail on the way. These don’t necessarily look like queues. Sometimes the queue is an inbox, and sometimes it’s a draft that nobody wants to finish because the next step is unclear.

There is a formal way to describe what is happening. Little’s Law connects the amount of unfinished work in a stable system with the rate at which work arrives and the time it spends there, but we don’t need the formula to begin. We only need to notice that when work reaches one step faster than that step can deal with it, the pile grows, and every customer on the other side feels the delay.

Follow the work, not the diagram

Once we’ve found something that waited, we pick one example and reconstruct what happened. The official workflow is a useful starting point, but it isn’t evidence, because real work has side conversations, copied values, private spreadsheets, and small decisions that experienced people no longer remember making (including some decisions that aren’t written down anywhere).

For the quotation, we’d want to know when the request arrived, what information arrived with it, when someone first touched it, what they had to look up, and why it stopped again. We’d then compare it with an ordinary quotation and one that went particularly badly, since one example can always be an accident.

Three often reveal a habit.

This part can feel pedantic, especially when everybody is eager to see a prototype, but it is also where the project changes shape. The manager may be making a real commercial judgment, with the reading itself taking most of the time. The judgment may instead be simple, but the request often arrives without a delivery date, or the manager may be following a pricing rule that could have been software years ago. There is even a fourth possibility: nobody can remember why every quotation still needs approval.

The same two-day delay can therefore point to four different projects. We might need AI to read messy documents and prepare evidence, a required field that stops incomplete requests from moving forward, ordinary automation for a stable pricing rule, or an honest conversation about whether an old control still protects the business from anything.

AI becomes interesting when the difficult step involves language, scattered information, or a judgment that can be reviewed, although even then we want to understand the judgment before automating it. If two specialists disagree about what a good answer looks like, a model won’t settle the question. It will merely make the disagreement harder to see.

Make the first version smaller than the idea

If the quotation really is waiting because a specialist has to search through contracts, pricing documents, and old customer correspondence, we now have a plausible AI use case. We also have a temptation to make it much larger than it needs to be.

The ambitious version reads the incoming request, decides whether the opportunity is worth pursuing, updates the CRM, writes a quotation, and sends it to the customer. It may even work on a good test case, but the first bad result leaves us to work out whether the model misunderstood the request, retrieved the wrong document, applied the wrong pricing rule, or took an action it shouldn’t have been allowed to take.

A broad demo hides several experiments inside one smooth screen.

A more useful first version could gather the relevant facts, show where each fact came from, and prepare a draft for the specialist, while leaving the decision and the send button alone. That is less impressive in a demo, but it is much easier to learn from. If the specialist still spends the same amount of time checking every source, we’ve discovered something important. If requests arrive in better shape and fewer are sent back for missing information, we’ve discovered something useful.

There is a practical reason to keep this boundary. Complex agents add more cost, latency, and ways to fail, a trade-off Anthropic also describes in its guidance on building effective agents, so more autonomy should follow evidence rather than enthusiasm. We’d rather expand a narrow tool that people trust than spend weeks debugging an assistant whose responsibilities were never clear.

The measurement should stay close to the original delay, which means we’d look for younger quotations, fewer requests returning for missing information, and a specialist who can handle more work without rushing. Accuracy still matters, of course, but a technically accurate draft that creates another layer of checking hasn’t improved the workflow.

What one real result can tell us

One of our clients, a US eyewear wholesale business, estimated that a tailored ERP and AI-assisted reporting workflow gave the team about ten hours back each week. We like that result, but it doesn’t prove that “AI reporting saves ten hours,” because the number was the client’s estimate (not a stopwatch study) and the ERP mattered alongside the AI-assisted part.

What the result does show is the value of staying close to the work. The useful question wasn’t whether the business should have an AI reporting tool; it was where the team’s time went before the new workflow existed, what information people needed, and which parts of the process software could reliably carry. The technology followed that investigation.

We don’t have a universal formula for choosing the first use case, and we’d be suspicious of one. A ten-person services firm and an eighty-person showroom don’t have the same work, the same data, or the same tolerance for mistakes, but the first half-hour can be surprisingly similar. You take something that recently got stuck and reconstruct what happened (without cleaning up the awkward parts), paying particular attention to where it waited and what finally allowed it to move.

By then, the AI question is usually easier. Sometimes the answer is a model. At other times, it is an integration, a rule, or an approval that has outlived its purpose. That isn’t a disappointing end to an AI exercise. It means we’ve found the problem before falling in love with the solution.

If you’d like another perspective, bring us the item that got stuck. That’s enough for a first conversation.