Most AI projects that get proposed internally are the interesting ones. Most AI projects that pay for themselves are the boring ones. It is worth understanding why, because the gap is predictable enough to plan around.
The shape of a project that works
The automations that consistently return their build cost share four properties:
- High volume. Something happening hundreds of times a month, not five.
- Text-shaped. The input and output are language or documents โ the thing language models are actually good at.
- Cheap to be wrong. A mistake is noticed and corrected in the normal flow of work, not discovered a quarter later in an audit.
- Currently done badly. Not because people are careless, but because the task is repetitive and attention degrades. The bar you are clearing is a bored human at 4pm, not a careful one.
That last property is the one teams undersell when building a business case. Comparing an automation against an idealised human baseline makes it look marginal. Comparing it against the real one โ the actual error rate on invoice data entry, the actual time a ticket waits before someone reads it โ usually makes the case obvious.
Four that reliably work
Document extraction. Supplier invoices, delivery notes, bank statements, purchase orders. Pulling structured fields out of inconsistent PDFs is genuinely hard with rules and genuinely easy with a model. Route the output into a review queue where anything low-confidence gets a human glance, and the accuracy question resolves itself.
Support triage. Not answering tickets โ routing them. Classifying by topic, urgency and language, then assigning to the right queue and drafting a suggested reply the agent can edit. The agent stays in control, and the first-response time falls sharply because nothing sits unread.
Classification and enrichment. Tagging leads by industry, categorising expenses, normalising product descriptions from a dozen suppliers into one catalogue. Tedious, high volume, easy to spot-check.
Drafting. First drafts of proposals, job descriptions, product copy, meeting summaries. The value is not that the output ships as-is; it is that starting from a mediocre draft is much faster than starting from nothing.
Three that usually disappoint
Anything low-volume and high-consequence. Automating a decision that happens twice a month and costs real money when wrong gives you all the review burden and none of the scale benefit. Keep the human.
Automating an undefined process. If two people in the company would handle the same case differently and neither is wrong, the process is not specified. Automating it produces inconsistent output faster, and now nobody can explain why. Specify first โ that exercise often delivers most of the value on its own.
The chatbot that must know everything. Retrieval over a documentation set works well when the corpus is curated and the questions are bounded. It works poorly when it is pointed at every shared drive the company has ever had, because the model faithfully retrieves the outdated policy alongside the current one.
The four questions to ask before building
- How many times a month does this happen? Under about fifty, the build rarely pays back.
- What happens when it is wrong, and who finds out? If the answer involves an auditor, redesign so a human approves.
- Could a rule do it? If the logic is deterministic, write the rule. It is cheaper, faster and explainable.
- Where does the output land? An automation whose result is an email nobody actions has not automated anything. It should write into the system where the work actually happens.
That fourth question is the one that separates a demo from a deployment. The model is rarely the hard part. The integration โ into the ERP, the helpdesk, the CRM, with the right permissions and an audit trail โ is where the engineering time goes, and it is what turns a clever prototype into something the business quietly depends on.