The question that comes before the tool
Nearly every automation request arrives named after a technology rather than a problem, and the first useful thing to do is rename it. Not "we want AI" but "three people spend two hours a day moving information between two places". Once the sentence is in that form the right answer is usually obvious, and often it is not AI.
So the opening question is narrow: what is the input, what is the output, how many times a day does it happen, and what does a person currently do in between? A process that fails any of those questions is not ready for automation regardless of how good the model is.
Where the line actually falls
This distinction is the difference between a project that pays for itself and one that becomes a maintenance burden, so it is worth being blunt about it. A language model is a general reader. It is superb at unstructured input and unnecessary - slower, costlier, less predictable - the moment the input is already structured.
| Situation | Right tool | Why |
|---|---|---|
| Two systems need to exchange records on a schedule | Integration job | Deterministic, cheap, no model needed |
| A form feeds a database | Plain code | The structure already exists |
| A PDF arrives in a different layout each time | Language model extraction | A parser would need constant maintenance |
| Messages must be understood before routing | Classification model | Intent is language, not a keyword |
| Staff keep asking the same question of a document set | Retrieval plus generation | Search alone returns pages, not answers |
| A decision needs judgement about an exception | A person | Automating this reliably produces confident errors |
What gets built most often
Document extraction turns invoices, purchase orders, delivery notes, quotations and forms into structured rows, with a confidence score on every field so low-certainty values go to a person instead of silently entering the database. This is the highest-volume category and usually the first thing worth doing.
Enquiry triage takes messages arriving across email, web forms and WhatsApp, classifies intent, routes to the right person and drafts a first reply for approval. Internal question answering lets staff ask a question of policies, manuals, contracts or past quotations and get an answer with the source passage attached, so the answer can be checked rather than trusted.
Then the quieter ones: report generation that reads from the systems already holding the numbers, reconciliation that matches payment advices to invoices, and summarisation that turns a long thread or a set of inspection notes into something a manager can act on in a minute.
Accuracy is a number, not a claim
Every automation ships with an evaluation set - real examples drawn from your own workflow with the correct answer recorded - so accuracy is measured before go-live and re-measured after every change. Without one, improvements are opinions and regressions stay invisible until somebody downstream notices.
The design assumes error. Confidence thresholds send uncertain cases to a human queue. Every automated action is logged with the input that produced it, so a wrong output can be traced rather than guessed at. Staff get a one-click way to flag a bad answer, and those flags feed back into the evaluation set. A system nobody can audit is a system nobody trusts, and an untrusted system gets worked around within a month.
Cost, limits and staying portable
Model usage is metered per token, so an automation left unbounded can produce a bill nobody forecast. The controls are unglamorous and effective: per-user and per-day caps, caching of repeated queries, truncating context to what the task needs, and using a smaller model wherever a smaller model is sufficient. Most well-scoped automations cost a small fraction of the labour they remove.
The architecture stays model-agnostic. Providers change pricing, deprecate versions and shift quality every few months, and nothing in a system you own should make switching a rewrite. Where data cannot leave your infrastructure, the same designs run against self-hosted models, with the accuracy difference stated plainly rather than glossed over.
How an engagement runs
One process first, four to six weeks, with a written scope and a fixed quote. Before it starts, the current process is timed so there is a real baseline; after it ships, the same measurement runs again. That comparison decides whether a second automation is worth commissioning, which is a more honest basis than a projected percentage in a proposal.
If the review concludes that a process needs fixing before software touches it - inconsistent data, an undefined rule, a step that exists because of one person habit - the review says so. Automating a broken process reliably produces a faster broken process.
Frequently asked questions
What is the difference between AI automation and business automation?
Business automation moves and transforms data between systems on rules you define - deterministic, cheap and reliable. AI automation handles input that has no fixed structure: documents whose layout changes, messages whose intent must be understood. Most real projects use both, and the scope says which part is which.
How accurate is document extraction?
It depends on your documents, which is why it is measured on your documents rather than quoted as a headline number. An evaluation set of real examples gives a figure before go-live, and confidence thresholds route uncertain fields to a person so the error mode is a queue rather than bad data.
What does an AI automation project cost?
One well-defined automation is typically a four to six week build at a fixed quote against a written scope. Running cost is model usage plus hosting, capped by design with per-user and per-day limits, and usually a small fraction of the labour removed. Both numbers come before you commit.
Do we need AI, or just an integration?
If both sides of the process are already structured, an integration is cheaper, faster and more reliable, and that is what I will recommend. AI earns its place when the input is unstructured language or a layout that keeps changing.
Does our data get used to train models?
Not under the major providers API terms, which differ from their consumer products in exactly this respect. Where that is still unacceptable - and for some regulated data it should be - the same systems run on self-hosted models with the accuracy trade-off stated up front.
What happens when the automation gets something wrong?
It routes to a person rather than acting. Confidence thresholds, a human queue for uncertain cases, full logging of every action with its input, and a flag button for staff. The design question is never whether errors occur but whether they are caught and traceable.
Can you automate a process we have not documented?
Yes, and documenting it is usually the first half of the work. Watching what people actually do tends to surface steps nobody wrote down and rules that turn out to be one person preference rather than policy, which is worth knowing before any code is written.
Find your first automation
Tell me what you need and you get a written scope, a fixed quote and a delivery timeline before any work starts — no obligation.
Ananth N · Madurai, Tamil Nadu · serving Madurai, Coimbatore, Chennai and clients across India · remote-first.
Discuss an automation WhatsApp Email