There is a lot of noise in this category. Most of it is written by people selling AI, which means the answer to "should you use AI for this" is always yes.
Here is a more useful frame, and it is the one I use before building anything for a client.
The rule that decides everything
Ask what happens when it is wrong.
Not if. When. Language models are not deterministic and they will produce a wrong output eventually, on some input you did not anticipate.
That question sorts every possible automation into three groups:
Group 1: wrong is invisible. A draft nobody sends, a summary a human reads, a first-pass categorisation someone reviews. If it is wrong, a person notices and corrects it. Automate freely.
Group 2: wrong is embarrassing but recoverable. An auto-reply with a factual error, a wrong tag on a record. It costs you something but it is fixable. Automate with guardrails and monitoring.
Group 3: wrong is expensive or permanent. Sending money, making a commitment on your behalf, quoting a price, deleting data, saying something that binds you legally. Do not automate the decision. Automate the preparation and let a human approve.
Most failed AI projects are group 3 problems that someone treated as group 1.
The rule holds up in practice better than any framework about "AI readiness", and you can apply it in about four seconds.
What actually works
These are the ones I build repeatedly because they hold up in production.
1. Lead qualification and routing
An enquiry arrives. Something reads it, works out what they want, how urgent it is and whether it fits what you do, then tags the record and routes it to the right pipeline stage or person.
Why it works: it is a classification problem with a small set of outcomes, and a mistake means a record is in the wrong column, which a human notices immediately. Group 1.
What it saves: the twenty minutes a day of reading and sorting, and more importantly the enquiries that get missed when you are busy.
2. Draft replies for a human to send
The system writes a reply to an incoming enquiry, pulls in the relevant context, and puts it in front of you. You read it, edit it, send it.
Why it works: the human is the safety layer, and it is genuinely faster to edit a decent draft than to write from nothing.
The trap: the moment someone gets comfortable and starts sending without reading, you have silently moved from group 1 to group 3. If that is going to happen, build it as auto-send with explicit constraints instead, so at least the constraints exist.
3. Meeting notes into actions
Transcript in, summary and a list of actions out, written into your CRM against the right contact.
Why it works: the alternative is that nobody writes the notes at all, so the comparison is not "AI notes versus perfect notes", it is "AI notes versus nothing". Errors are visible to whoever was in the meeting.
4. Content drafting from your own material
Turning a call, a case study or a set of notes into a first draft of a post or an email.
Why it works: you review before anything is published. Blank-page problems are expensive and this removes them.
Why it fails: when people publish the first draft. Generic AI-sounding content is actively worse than posting nothing, because it tells the reader you did not care enough to write it.
5. Answering questions from your own documents
A support assistant that answers from your actual documentation, pricing and policies, rather than from general knowledge.
Why it works when it works: grounded in your material, so it is much less likely to invent things.
What it needs to be safe: it must be able to say "I do not know, here is a human". An assistant with no escape hatch will make something up, and the thing it makes up will be a commitment your business did not agree to.
6. Data entry and enrichment
Pulling structured fields out of unstructured input. Emails into contact records, invoices into line items, form text into tagged fields.
Why it works: boring, high volume, and errors are correctable. This is the least exciting item on the list and often the highest return.
What does not work
Fully autonomous customer conversations for anything that involves price or commitment. The model will eventually quote a figure or agree to something. There is no prompt that reliably prevents this across all inputs, and the one time it happens can cost more than the automation saved.
Automation on top of a broken process. If your follow-up process does not work when a human does it, automating it produces the same failure faster. Fix the process first, then automate it. This is the most common reason AI projects disappoint, and it has nothing to do with AI.
Replacing judgement in your area of expertise. Clients are paying for your judgement. Automating that specific part is the one place where the saving is not a saving.
Anything where you cannot check the output. If you would not be able to tell that it was wrong, you should not be running it unattended. This is worth saying plainly because it is the failure mode nobody catches: an automation quietly producing bad output for months, with no error and no alarm, because nobody was in a position to notice.
"AI-powered" as the product. Nobody buys AI. They buy the outcome. If the AI is doing something a simple rule would do better, use the rule, it is cheaper and it does not hallucinate.
The honest cost picture
Two things people underestimate:
The API cost is usually not the issue. For a small business, running these automations typically costs single-digit to low-double-digit dollars a month. It is rarely the deciding factor.
The building and maintaining is the cost. Getting a workflow to handle real inputs rather than the clean examples takes real time, and it needs occasional attention afterwards. Edge cases arrive continuously because your business changes.
Budget for that ongoing attention. An automation that nobody has looked at in eight months is an automation nobody knows is broken.
Where to start
Not with the most exciting idea. Start here:
- List the tasks you do more than twice a week that follow a pattern. Actually write them down. Most people have four or five and have never seen them in one place.
- Cross out anything where being wrong is expensive. That is not your first project.
- From what is left, pick the one that takes the most total time per week. Not the most interesting one.
- Build that one and use it for a month before building anything else.
The reason for step four is that the first automation teaches you where your process is actually ambiguous, and that lesson makes every later one better. Building five at once means making the same mistake five times.
What I actually build
For context on where this comes from: what I put in for clients is mostly items 1, 2, 3 and 6 on the list above, wired into the CRM they already use so it shows up where they already work rather than as another dashboard nobody opens.
The AI automation service starts with an audit, because half the time the honest answer is that two of the five things on your list should be automated and the other three should just be deleted. That is a cheaper outcome for you and a better one, and it is not a conversation you can have before looking at the actual work.