How to Tell If an AI Project Is Worth the Money
The honest answer to "is AI worth it for small business" is that the question is too big to answer. AI is not a purchase. One specific change to one specific process is a purchase, and that question has a real answer you can work out in an afternoon.
MIT Project NANDA published research in July 2025 finding that roughly 95 percent of generative AI pilots produced no measurable business return, against 30 to 40 billion dollars of enterprise investment. The researchers attributed the shortfall to how organizations adopted the tools rather than to the quality of the technology, and found that generic deployments performed worse than ones built into a specific workflow.
That finding is usually quoted as a warning. It is more useful as an instruction.
Most of those projects did not fail at the technology. They failed at the decision that came before the technology, and at the measurement that never got set up.
Here is how to make that decision well.
Ask about the change, not about AI
Before anything else, replace the question.
"Should we be using AI" has no answer, because it has no cost, no scope, and no outcome attached to it. "Should we automate the way we collect documents from a new customer" has all three.
Every project worth doing can be stated in one sentence naming a process, a frequency, and an outcome. If you cannot write that sentence, you are not ready to spend money yet, and that is a finding rather than a delay. If you are still deciding which process to look at first, that is a different question with its own page: see which business processes to automate first (https://www.prismagentsolutions.com/blog/business-processes-to-automate-with-ai).
Write down three numbers before you price anything
You can gather all three from your own operation without buying a thing.
How often does this happen? Per day, per week, or per month. Count it for real rather than estimating. Most owners are surprised in one direction or the other.
How long does it take each time? Include the parts nobody counts: finding the information, retyping it into a second system, and the interruption when someone stops other work to handle it.
What breaks when it is done late or wrong? This is the one people skip, and it is usually where the money is.
The first two numbers give you hours. Hours are the floor of the value, not the answer.
The consequence is usually worth more than the hours
Consider a task that takes two hours and happens once a week. The labor math says a hundred hours a year, which sounds like a modest win and often is not enough to justify a project on its own.
Now ask what happens when that task runs three days late. If the answer is "nothing, it catches up," the project is a nice-to-have and you should say so. If the answer is "the customer starts wondering whether they made a mistake," or "a candidate takes another offer," or "the invoice and the cash both arrive a week later," then the hours were never the point.
Work out that consequence in your own numbers rather than a benchmark. How often does the late version happen, and what does one instance cost you?
Multiply. That figure is usually several times the labor figure, and it is the honest case for or against the project.
What a good candidate looks like
Across most businesses, the projects that pay share four traits.
· High frequency. A weekly or daily task compounds. A quarterly one rarely justifies the setup.
· Clear rules. Someone can state what should happen in each case without saying "it depends."
· A defined output. A document, a message, a record, a schedule. Something that either exists at the end or does not.
· A single point of failure who is a person. If the process only works because one person remembers, you are paying for that memory whether or not you have noticed.
What a bad candidate looks like
· Rare. The setup cost never earns back.
· Judgment heavy. If the value of the task is that a skilled person weighs an unusual situation, automating it removes the value.
· Undefined. Nobody has written the process down and three people do it three ways.
· Politically loaded. If the real problem is that two departments disagree about who owns something, software will not settle that argument.
The undefined case deserves attention, because it is a common reason a project produces nothing. Automating a process nobody has written down produces a faster mess and a new system to maintain. Writing it down first is unglamorous, cheap, and frequently delivers most of the benefit on its own.
Decide the measurement before you build
This is the step that separates the projects that show a return from the ones that quietly disappear.
Before you approve anything, finish this sentence: in ninety days, this number should be different. Then write down what it is today.
Good measures are specific and already exist somewhere in your operation.
· Days from a signed agreement to visible work starting
· Percentage of new customers whose documents were complete before day one
· Hours per week one person spends retyping information between two systems
· Number of open items with no next step assigned
· Days from work completed to invoice sent
If you cannot name a number, that is not a small problem to fix later. It means nobody has agreed on what the project is for, and a project without an agreed purpose is exactly the kind that gets reported as producing no measurable return.
Take the baseline yourself, before anything is installed. Nobody will be able to reconstruct it afterward, and a project with no baseline can only be judged on feelings.
Give yourself permission to stop
Set the review date at the same time you set the measure. Ninety days is usually right for an operational change: long enough for the habit to form, short enough that a bad decision does not run for a year.
At the review there are three honest outcomes. It moved the number, so expand it. It did not move but you can see why and the fix is small, so adjust once and set a new date. It did not move and nobody can say why, so stop.
Stopping is a good outcome. The expensive version is not the project that fails. It is the project nobody ever formally ended, still charging a monthly fee two years later while everyone quietly works around it.
Why the discovery step matters more than the tool
The pattern in the MIT research is worth taking literally: generic deployments did worse than ones embedded in a specific workflow. That is an argument about sequence rather than about products.
A tool selected first has to be justified afterward, so the process gets bent to fit it. A process examined first tells you what it needs, and the tool becomes a detail. It is also why the same software produces a real return at one company and sits unused at another.
That is why our own first step is an assessment rather than a build, and why nothing is built off the shelf. For the difference between buying software and buying help deciding, see AI tools versus AI consulting (https://www.prismagentsolutions.com/blog/ai-tools-vs-ai-consulting). For all of this applied inside one industry, where automation belongs in a staffing firm (https://www.prismagentsolutions.com/blog/ai-automation-for-staffing-firms) works through a chain of handoffs end to end.
When you want a second set of eyes on which project is worth doing first, a free AI assessment starts with how your business actually works rather than with a software recommendation.
Frequently asked questions
How do I know if an AI project is worth the money before I start?
Write down how often the task happens, how long it takes, and what it costs when it is late or wrong. The third number is usually the largest. Compare the total against the setup and running cost, and require the payback period to be short enough that you would still be glad you did it if the tool needed replacing.
How long should it take before an automation pays for itself?
For an operational workflow, aim to see the measure move within ninety days and the cost recovered inside a year. Anything longer needs a reason beyond the arithmetic, such as a compliance requirement or a capacity constraint you cannot hire your way out of.
What if I cannot put a dollar value on the time saved?
Then measure the consequence instead. Late invoices delay cash by a countable number of days. Slow starts show up in customers who do not return. Choose the countable version and track it.
What is the most common reason an AI project produces nothing?
Nobody decided what number should change, so nobody can tell afterward whether it did. The second most common reason is automating a process that was never defined, which produces the same mess more quickly.
