How to Find AI Use Cases in Your Business: Start With the Constraint

To find AI use cases in your business, work backwards from the constraint. That is the one thing capping your growth. Ask what would break first if 30% more customers came next month. Look for the leak in the five places it most often hides. Price each one with three numbers from your own systems. Keep only those that could earn back three to four times their cost in year one. What is left is your list, already ranked.

Most firms do it the other way round. They start from what AI can do and run a workshop. They end up with a long list of ideas and no way to choose.

No business owner wakes up wanting an automation. They wake up wanting more leads, more sales and lower costs. The method below starts there.

Why most AI use case lists go nowhere

The usual advice is to look for work AI is good at. OpenAI has a guide to finding use cases. It points teams at three areas. One is low-value tasks that repeat. One is work that waits on a scarce skill. The third is work where the way forward is unclear. Then it sorts the ideas on an impact and effort grid. That is a chart of how much each idea helps against how hard it is.

That works for what it was built to do: get a whole company using AI every day. It works badly for deciding what to build. There are two reasons.

First, "impact" on a grid is a feeling. Two people can put the same idea in opposite corners. Neither can prove the other wrong.

Second, a list built from what AI does well is a list of tasks. And a task is not a problem. RAND asked 65 seasoned data scientists and engineers why AI projects fail. Here is the most common root cause they found. Leaders misread the problem the AI should solve, or explain it badly.

A buyer who writes "chatbot" on the list has picked the answer. No one has priced the question. So flip the order. Start with the constraint, then where it leaks, then the price, then the build.

Step 1: Find the primary constraint

At any given point in the business, at any given time, there's one primary constraint. A constraint is the thing that caps how much you can grow. Either you lack demand, or you lack the capacity to serve the demand you have. Capacity means the people, hours and tools to do the work. All the rest is noise with a budget attached.

Ask whoever runs the day-to-day work one question, out loud. If next month brought 30 percent more customers, what would break first?

Don't skip this. Picture a business that can't serve the buyers it has, and buys more leads. It has found a costly way to annoy people.

Then answer three questions in writing. They are the ones I ask on a first call:

1. How much do you think that's costing you per month?
2. What happens if nothing changes in the next six to twelve months?
3. How many hours a week is your team spending on this manually?

Notice how fast you reached for "a lot."

Step 2: Look in the five places the money hides

Each row below has one question that shows the leak. It also has one line of math that prices it. The first and fourth rows are demand problems. The other three are capacity problems.

These leaks look like normal work until someone counts them. One info-products business had 600,000 dormant leads in its own CRM. A CRM is the software that holds your list of buyers and leads. Every follow-up had been sent, and the list was written off. Then a reactivation layer was added on top of that CRM to reach the old leads again. It opened 170,000 conversations. It produced $1.2M in new revenue in 30 days, from data the business already owned.

Here is what counting looks like at a smaller firm. The example is invented, so no one gets embarrassed.

The owner of a 35-person distributor knows quotes go out late. On a Monday she asks her office manager a question. How long does it take to re-key a purchase order from an email into the ERP? The ERP is the system that runs orders, stock and billing.

"About twelve minutes."

"How many a week?"

"Two hundred, give or take."

Twelve times two hundred is 2,400 minutes. Forty hours. A full-time person, every week, retyping what a customer already typed once.

Step 3: Put a dollar figure on each one

Three numbers price a leak. Use the figure you can count, not the one you remember.

1. Hours burned. Hours a week x loaded hourly cost x 52. The loaded cost is pay plus benefits plus payroll taxes, divided by 2,080. That is 40 hours x 52 weeks.
2. Revenue touched x leak rate. Take the revenue that passes through the broken step each month. Multiply it by the share that leaks and could have been kept. Then multiply by 12.
3. Cost carried. What you spend each month because the problem exists, times 12. Think of contractors, overtime, rush fees, refunds, write-offs, and software seats that patch the gap.

The same math works on any of the five places. At a fitness business, 14 coaches each spent 15 hours a week writing client check-ins by hand. That is Number 1. A drafting engine in each coach's own voice took it to 10 minutes a week. The coach still approves every draft.

Here are the distributor's three numbers. Every figure is invented and rounded.

Three traps catch almost everyone on this step.

Hours are money only if they go somewhere. The 40 hours are worth $62,400 a year in just three cases. You cut overtime, you skip a hire, or you point those hours at work that earns. If forty hours become forty hours of looking busy, Number 1 is zero. Write down where the hours go.

Count each dollar once. The late quotes are partly caused by the retyping. But the salary you pay and the order you lose are not the same dollars, so both stay. If two numbers describe the same dollar, keep the larger one.

Be stingy with the share you can remove. Count what a system removes in full. Ignore what it only cuts back. Say a system ends the retyping but not the odd cases. It gets credit for the retyping.

Step 4: Keep only what pays back three to four times

A price on the leak is not yet a budget. Two more lines turn it into one.

Say a system could remove 60 percent of the distributor's $518,400. That is $311,040 a year. A build is worth doing only if it pays back three to four times its all-in cost. So the most worth spending in year one is $77,760 to $103,680. That is $311,040 divided by four, then by three. It is a ceiling for the whole first year, build and running costs together. A quote above it fails before anyone opens a demo.

Run the same two lines on every use case. Then rank them by the multiple: annual value divided by build cost plus first-year run cost. The multiple is how many times over a system pays for itself. Why is the bar three to four? And how do you test the multiple before you trust it? Both are in how to calculate AI ROI.

Do you need clean data to find AI use cases?

No. The worry is a fair one: "We can't even agree how many active customers we have. Sizing a leak is fantasy."

It isn't. Sizing needs numbers right enough to rank the leaks. No one is asking an auditor to sign them. Say you are 30 percent off on the distributor's $518,400. You still have $362,880. That is nowhere near a $25,000 leak at the bottom of the list. The order holds up, even with sloppy inputs.

Clean data matters later, at build time. Data first, structure second, skin third. To find the use case, you need less. A CRM export and ten minutes with the person who does the work will do.

When not to build anything

Here are three cases where the method gives you an answer you didn't come for.

The leak is a price, not a process. If customers won't pay what you charge, no model fixes it. Maybe you are short on capacity because you charge too little. Then the answer is to hire, productize, train or raise the price. A price rise costs nothing to build.

The number is small. Say the three numbers total $30,000 a year. At three to four times, that supports $7,500 to $10,000 of all-in spend. A good freelancer and a cleaner process will beat any system at that size.

The number is exactly the one you hoped for. Have the person who does the work check it. Then look for what the sheet has no line for. Before that Monday, the owner had been counting the shared sales inbox on Sunday nights. Sixty-one quote requests, no reply. Number 2 priced the quotes that went out late. The 61 never went out at all.