What AI can't do for your business

Run any task through these before anyone quotes you for it. They are ordered deliberately — a no on an early question makes the later ones irrelevant.

• Does it happen the same way every time? Not roughly the same — actually the same. If the answer is “it depends who’s doing it,” you do not have a task yet, you have a habit.
• Can a machine reliably read the input? A booking form, yes. A calendar, yes. A voicemail, mostly. A photo of a handwritten note on a truck dashboard, no — and this is where most real small-business work quietly dies.
• What does being wrong cost? A mistimed reminder text costs nothing. A wrongly cancelled appointment costs a customer. Same technology, completely different decision.
• Is a person looking before it matters? A draft a human sends is a different product from a message that goes out unread, even when the words are identical.

Most disappointing automation projects pass questions one and three and fail question two — the work turned out to depend on information that only ever existed in somebody’s head.

Across the jobs above, the failures are not random. They cluster:

• Judgement under ambiguity. Not hard questions — under-specified ones. Software will produce a confident answer to a question that should have been met with “it depends,” and confidence is exactly the wrong output when the honest answer is uncertainty.
• Anything where the point is that a person did it. A warranty denial, a condolence, a real apology. The content is not the value. Automating these does not save time so much as convert goodwill into efficiency at a very poor exchange rate.
• Work where being confidently wrong beats being slow. If a delayed answer is survivable but a wrong one is not, a human bottleneck is a feature. Most compliance, safety and money-movement work sits here.

Three questions that separate someone who has built this from someone who has watched a demo:

• “What would you refuse to automate here?” If nothing comes back, either they have not looked at your business or they are not telling you what they saw. There is always something.
• “What does it do when it doesn’t know?” The correct answer is a specific, boring escalation path — it flags, it holds, it routes to a person. If the answer is that it will not happen, the system has no failure mode, which means it has one and nobody has designed it.
• “Can I see it handle a bad input?” Every demo runs the happy path. Ask for the mumbled voicemail, the customer who changes their mind mid-sentence, the address that does not exist. The gap between those two demos is the entire project.

The most common reason an automation project fails has nothing to do with what models can do. It is that the business never had a written process to encode.

What exists instead is a person who knows that the Tuesday delivery goes to the back door, that this customer always pays late but always pays, and that you never send the new tech to that address alone. None of that is written down. All of it is load- bearing. Software cannot infer any of it, and the first honest step of any real automation project is the unglamorous work of getting it out of somebody’s head and onto paper.

That step has value even if you then automate nothing. A written process survives the person leaving. It is also the thing that makes the next quote you receive meaningful rather than a guess — which is why we scope before we price, and why the scope is worth paying for on its own.