Most AI automation projects fail on task selection rather than technology. The model is usually capable enough; the task was a poor candidate, and no amount of prompt engineering fixes that.
So the useful question isn’t which AI tools to adopt. It’s which of your tasks have the shape that automation rewards.
The shape of a good candidate
Four properties, and you want all four:
High volume, low variety. Something happening hundreds of times a month in roughly the same form. Automation cost is largely fixed, so it amortises over volume. A task performed twice a week is rarely worth the engineering, however tedious.
Tolerant of imperfection, or cheaply checkable. Either a mistake costs little, or a human can verify the output far faster than producing it. Drafting a reply that someone approves in five seconds is an excellent candidate. Issuing a regulatory filing with no review is not.
Currently done by a human reading and re-typing. Extracting fields from an invoice into a system, summarising a call into a CRM note, categorising an inbound request. Language models are genuinely good at this, and it’s where most of the realised value in business automation sits today.
Bounded by information you actually hold. Answering questions from your own documentation works. Answering questions requiring judgement about a customer relationship that lives in someone’s head does not.
Where it reliably pays
Document data extraction. Invoices, delivery notes, purchase orders, forms, applications. Historically this needed template-based OCR that broke whenever a supplier changed layout. Modern models handle variation far better. Pair extraction with human review on low-confidence results and you get most of the saving without the error risk.
Triage and routing. Classifying inbound email, tickets and requests, then routing them. Errors are cheap because a mis-routed item is corrected in seconds, and the volume is high. This is one of the safest first projects available.
Drafting with a human in the loop. First drafts of quotes, replies, reports and summaries. Value comes from removing the blank page, not from removing the person. Measure editing time, not acceptance rate.
Search over your own material. Letting staff ask questions of contracts, manuals, past projects and policies. This works well when scoped to a specific corpus and poorly when framed as “an assistant that knows everything.”
Summarising the long into the short. Calls into CRM notes, threads into a status, incident logs into a report. Low risk, immediately useful, easy to check.
Where it usually doesn’t
Anything requiring a guarantee. If an output must be correct every time and cannot be reviewed, automation is the wrong tool. Rules engines exist for this and remain the better answer.
Low-volume, high-complexity work. The engineering cost is the same for ten cases a year as for ten thousand. Ten cases don’t justify it.
Tasks whose inputs are inconsistent by nature. If the information arrives differently every time and there’s no reliable structure, expect ongoing correction cost that erases the saving.
Judgement calls with real consequences. Pricing decisions, credit approvals, hiring, disciplinary matters. AI can inform these; automating them creates liability and, in several jurisdictions, regulatory exposure.
Work that’s actually broken. Automating a bad process makes bad outputs faster. If the process is unclear, fix it first — you may find you don’t need automation at all.
How to run the first one
Pick one task and instrument it before you start. Measure how long it takes now, how often it’s done, and how often it goes wrong. Without a baseline you cannot demonstrate a result, and undemonstrated results don’t get funded twice.
Keep a human in the loop initially, but measure the check. If reviewing takes as long as doing, the project has failed regardless of how good the output looks.
Define what failure looks like in advance. An accuracy floor, a cost ceiling, a date. AI pilots drift indefinitely precisely because nobody agreed what “not working” means.
Start with the boring one. Teams gravitate to the impressive use case — a customer-facing assistant — because it demos well. Internal document extraction is duller, safer, and far more likely to pay back.
Measuring honestly
Track four numbers:
- Time saved per unit, verified by observation rather than estimate.
- Error rate, against the human baseline — which is never zero, and comparing AI against perfection instead of against current performance is a common analytical error.
- Review time, the cost that determines whether the saving is real.
- Total running cost — inference, engineering, maintenance, and the review labour.
If time saved minus review time doesn’t clear running cost with a sensible margin, stop. That’s a successful experiment, not a failure — you learned it cheaply.
What to consider before committing
- Where does your data go? For anything sensitive, understand the provider’s retention and training terms, and whether processing location satisfies your obligations.
- What happens when the model changes? Providers deprecate and update models. Anything built on one needs periodic re-evaluation; budget for it.
- Can you explain a decision? In regulated contexts you may need to. Design for explainability from the start rather than retrofitting it.
- What’s the fallback? If the service is unavailable for a day, what happens to the workflow?
Frequently asked questions
Should we build or buy AI automation? Buy for commodity tasks — transcription, general document extraction, meeting summaries. Build where the workflow is specific to your business and the integration matters, which is usually where the actual saving is.
How much does an automation project cost? It varies enormously with integration complexity rather than with the AI part. Connecting to a modern API is straightforward; connecting to a legacy internal system rarely is.
Do we need our own model? Almost certainly not. Very few businesses benefit from training their own; most value comes from applying existing models to your own data and workflows.
How do we stop it making things up? Ground it in retrieved source material, constrain the task, show the source alongside the answer, and keep a human check where accuracy matters. Don’t rely on instructions alone.
Internal links: #16 why AI pilots fail, #9 field service buyer’s guide, /services. External references: your data protection authority’s guidance on automated processing; your chosen provider’s published data retention and processing terms. CTA: “Not sure which task to start with? That’s exactly what a first conversation should resolve.” → /contact