We have now scoped enough AI work to see a clear pattern in which projects deliver and which quietly stall. The difference is almost never the model. It is whether the task was specific enough to measure.
The shape of a project that works
Successful applied-AI projects in mid-sized businesses share four characteristics.
- A high-frequency task. Something happening dozens or hundreds of times a week. Automating a monthly task saves twelve occurrences a year and will never repay the build.
- A measurable baseline. You know it currently takes eleven minutes, because somebody timed it. Without this there is no way to demonstrate the project worked.
- A tolerable error mode. When it gets something wrong, a person catches it before consequences follow. Tasks where a silent error causes real damage need a different design and a much higher accuracy bar.
- An owner. A named person whose work improves. Projects sponsored by general enthusiasm rather than by someone who benefits do not survive their first difficult week.
Three that consistently return value
Document extraction
Invoices, delivery notes, applications, statements. Somebody is reading these and typing the numbers into a system. Extraction handles the common cases and flags anything ambiguous for review. The accuracy is measurable, the time saved is measurable, and the failure mode is a human checking a flagged item.
First-line support deflection
If a meaningful share of your inbound enquiries are the same twelve questions, an assistant grounded in your own approved answers handles them and escalates cleanly. The important design decision is the escalation path, not the model — an assistant that traps someone in a loop costs more goodwill than it saves in labour.
Internal knowledge retrieval
Staff spending time hunting through a shared drive, an email archive and three systems to answer one question. Retrieval over your own documents, with citations back to the source, turns that into a question. This one is popular with staff, which matters more for adoption than people expect.
What we advise against, for now
Autonomous agents making consequential decisions without review. Content generation where accuracy is not verifiable and the output carries your name. And any project justified with the phrase "we should be doing something with AI" — that sentence describes an anxiety, not a requirement, and it produces work that nobody can evaluate.
Cost is a design constraint, not an afterthought
AI features carry a per-use cost that conventional software does not, and it scales with usage rather than with headcount. That changes how you design. Model the cost per operation before building, set hard spend limits, and use the smallest model that clears your accuracy bar for the bulk of the work. A feature that is delightful at a hundred requests a day and ruinous at ten thousand was not designed — it was prototyped and shipped.
The most useful question at the start of an AI project is not "what could this do?" It is "what does this task cost us today, and how will we know if it improved?"