Published · June 18, 2026
Where AI actually fits in a business
It does not pay off everywhere. Here is how to spot candidate tasks, rank effort against impact, and avoid weak investments.
In the last post we sorted out what people mean when they say AI. Now comes the more useful question: not whether the technology is real, but where it pays off inside your company.
The honest answer is less glamorous than many headlines. These tools help a lot in some places, a little in others, and not at all in several where people most want them to. The work is to tell those apart before you spend.
Where it tends to deliver
A clear pattern shows up across small and mid-sized companies. The best opportunities tend to be repetitive tasks, heavy on text or data, where a useful draft already creates value.
- Customer support. Drafting replies, summarizing tickets, suggesting the next step. In a study of 5,179 support agents at a software company, access to an AI assistant raised issues resolved per hour by 14% on average (Brynjolfsson, Li, and Raymond, 2025).
- Internal knowledge. Asking questions of policies, manuals, procedures, or past projects instead of hunting through folders.
- Document processing. Pulling fields from invoices, contracts, and forms, then handing the result to a person to confirm.
- Drafting and summarizing. First drafts of emails, proposals, and reports. Condensing a long thread into three lines.
- Data analysis. Asking plain-English questions of a spreadsheet, spotting patterns, generating a chart.
- Forecasting. Estimating demand, staffing, cash flow, or operational load from the history you already keep.
What they share is not magic. It is language or number work, repeated many times, where saving part of the effort already matters.
How to recognize a good candidate task
You do not need a data science team to spot a reasonable opportunity. Look for three traits.
It is repetitive. Someone does it many times a week, with similar steps. That is where small savings compound.
It works with text or data. The raw material is words, numbers, or documents that already exist, not physical work or in-person judgment.
It tolerates human review. A person can check the output before it reaches a customer, a regulator, or an important decision. This is the quiet requirement behind almost every safe use today. The tool may be fast and useful, but it should not be treated as infallible.
There is a fourth point worth watching. In the same support study, the largest gains appeared among newer and less experienced workers, who improved by 34 percent, while the most experienced workers barely moved (Brynjolfsson, Li, and Raymond, 2025).
These systems often lift the floor more than the ceiling. They distribute some of what your best people already know to people who are still learning. If a task depends heavily on uneven experience inside the team, it can be a good place to start.
Where AI disappoints
This is the part many vendors skip. It is worth saying anyway.
High-stakes decisions with no room for error. If one wrong output can cause real harm, the math changes. Law offers a public cautionary tale: lawyers have filed briefs with court cases invented by generative tools, complete with names and citations that sounded real (Scientific American, 2025). The issue was not lack of intelligence. It was trusting a confident answer without checking it. When a task cannot tolerate that kind of error, the tool can assist, but it should not have the final word.
Sparse or messy data. Models need examples or context. If your records are incomplete, scattered, or stuck in systems that do not talk to each other, there is no solid base to work from. Forecasting with two years of clean history can make sense. Forecasting from a folder of half-filled spreadsheets usually does not.
Tasks that need to be exact every time. Tax filings, safety calculations, health advice, sensitive payroll, critical contracts. A tool can help a qualified person, but it cannot carry the responsibility.
The pattern is simple: the more expensive it is to be wrong, and the harder it is to catch the error in time, the more careful you need to be.
The effort-versus-impact lens
Once you have a few candidate tasks, rank them with a simple matrix: effort against impact.
Impact is what you gain if it works: hours back, faster replies, fewer errors, less backlog.
Effort is what it takes to get there: buying a tool, configuring it, connecting it to systems, training the team, reviewing security, changing a process.
Start with high impact and low effort. A support team drowning in repetitive tickets, using an off-the-shelf assistant, often sits there. Be careful with high effort and uncertain impact. That is where many expensive disappointments live.
You do not need a sophisticated chart. A list and an honest conversation are enough. The discipline is in not underestimating effort, which is exactly what tends to happen when a demo looks too easy.
Buy before build
One practical rule for small and mid-sized companies: you almost certainly do not need to train your own model.
Adoption is broad now, with 78 percent of organizations reporting use in at least one function, up from 55 percent a year earlier (Stanford HAI AI Index, 2025). The vast majority did not build the base model. They bought a tool, configured it, and added it to a process.
Building from scratch costs a lot, requires talent that is hard to hire, and leaves you with permanent maintenance. For nearly every small or mid-sized company, the sensible move is to start with existing tools, connect them carefully to the right data, and put human review where it is needed.
Treat “build” as the exception, not the starting point.
Where to start
The picture is narrower than the hype suggests, and that helps. You do not have to “do AI” in the abstract. You have to find two or three repetitive tasks, heavy on text or data, where a partial improvement has value and can be reviewed before it creates risk.
The hard part is not choosing the technology. It is looking honestly at your operation and separating real opportunities from loose experiments. First you diagnose, then you implement.
