The question is rarely whether a model can do the task. It is whether anyone in the company can write down how the task is currently done.
Nearly every company has tried something by now. Somebody has a prompt they paste into a chat window twice a day. Somebody else automated an email in a no-code tool and it worked for a month. Very few have a process that runs without a person watching it.
That gap is not anecdotal. It is the shape of the whole market.
Read those two numbers together and the conclusion is uncomfortable for anyone selling this work. Almost everybody has access to the technology. Almost nobody has it running in production. The bottleneck is not the model.
In our experience it is nearly always the same thing: the process being automated was never written down, so what looked like one task turns out to be a task plus forty years of judgement nobody documented.
What should a business automate first?
Start with a task that happens often, follows a rule someone can state out loud, and produces an output another person checks before anything irreversible happens. Sorting and routing incoming enquiries, drafting first-pass replies, extracting fields from invoices or purchase orders, keeping records consistent between two systems. These qualify because the rule already exists, the volume makes the saving real, and a mistake is visible and cheap to correct. Automating a rare, high-stakes decision first is the common mistake: the payoff is small and the failure is expensive.
Four questions that pick the first process
Most companies choose the first automation by picking whatever annoys the loudest person. A better filter takes twenty minutes and asks four things about a candidate task.
How often does it happen. Under a few times a week, the saving will not repay the setup, however tedious it feels to the person doing it.
Can someone state the rule out loud. This is the one that eliminates most candidates, and it should be tested by actually asking. If the answer arrives as a sequence of conditions, it is a good candidate. If the answer is that it depends and you get a feel for it, you have found expertise rather than a procedure, and expertise does not transfer to a prompt.
What happens when it is wrong. Not whether it will be wrong, it will. Whether being wrong is noticed and reversible, or silent and permanent.
Does the output have a reader. Automations that produce something nobody looks at fail quietly for months. If the result lands in front of a person as part of their normal work, it gets checked without anyone being assigned to check it.
A task that passes all four is worth building this quarter. A task that fails the second one is worth writing down first, and that exercise is valuable even if the automation never happens.
Automations break at the input, not at the model
Demos are built on clean data. Production is a photograph of an invoice taken at an angle, an email with the actual request buried under four forwarded replies, a spreadsheet where someone typed a note into the total column.
This is where the estimate goes wrong, consistently. The interesting part, connecting the model, is an afternoon. The unglamorous part, deciding what the system does with input it was not designed for, is most of the project.
There is a principle that helps and it is not technical. An automation should be allowed to say it does not know. A system that always produces an answer will produce a confident wrong one, and a confident wrong answer costs more than no answer, because someone acts on it.
- Give it an explicit route for cases it cannot handle, and send those to a person rather than guessing.
- Log what it was given and what it decided, so a wrong result can be explained rather than argued about.
- Measure how often it takes the escape route. Rising numbers mean the world changed, and that is worth knowing early.
The loud failure and the quiet one
Automations fail in two ways and only one of them gets attention.
The loud failure is a crash. Something errors, the queue stops, somebody notices within hours because work stopped arriving. This is the good kind. It is visible, it is dated, and it gets fixed.
The quiet failure is worse. The automation keeps running and starts being wrong. The categories drift, a supplier changes their invoice layout, a form gains a field. Nothing breaks. The numbers stay plausible. Six months later someone discovers a whole category has been misfiled since spring.
Guarding against that is not sophisticated. Sample the output on a schedule and have a human look at it. Ten items a week, from a real person, catches drift long before the quarterly report does. It is the least fashionable line in any automation proposal and the one we argue hardest to keep.
What one actually costs
The pricing conversation is distorted by the fact that the model calls are cheap. They are, and they are not where the money goes.
How much does it cost to automate a business process with AI?
For a single well-defined process, expect the build to run between 1,500 and 12,000 dollars depending on how many systems it has to touch and how messy the inputs are, plus a monthly running cost that is usually dominated by the tools rather than the model. Model usage for an ordinary back-office volume is often a few tens of dollars a month. The larger and more predictable costs are integration with existing systems, the handling of inputs that do not fit the pattern, and someone owning the process after launch. A quote that only prices the build is quoting half the job.
That last point is the one worth pressing in any proposal you receive. Ask who is responsible when it produces a wrong result in month four, and what happens when the supplier on the other end changes their format. If there is no answer, the price is not the price.
When automating is the wrong answer
Three cases come up often enough to name, and in all three the honest recommendation is to do nothing.
When the process is broken. Automating a bad procedure produces the same bad outcome faster and with less opportunity to notice. Fix it on paper first, and quite often the fix removes the need entirely.
When the volume is not there. A task done twice a month is not worth a system that has to be maintained for years, no matter how irritating it is for the twenty minutes it takes.
When the point of the task is the relationship. The follow-up call after a difficult delivery, the reply to a complaint that matters. Automating those saves an hour and costs something that does not appear on any spreadsheet until the customer leaves.
Will AI automation replace my team?
For the great majority of small and mid-sized companies, no, and framing it that way leads to bad choices. The tasks that automate well are the repetitive, rule-following parts of a job, not the job. What actually happens is that the same team absorbs more volume without a proportional increase in headcount, and spends its time on the cases that need judgement. Companies that begin with headcount reduction as the goal tend to automate the wrong things, because they choose by salary cost rather than by whether the task has a stateable rule.
Start smaller than feels worthwhile
The most common mistake we see is scope. A company decides to automate customer service, which is not a process, it is a department containing thirty of them.
One task, running for a month, with the numbers written down before and after, teaches more about what is possible in that specific company than any strategy document. It also produces the thing every subsequent project needs, which is one person internally who has seen this work and can say so.
