Every automation conversation reaches the same fork. Someone asks whether the system could just do the whole thing, and the honest answer is usually yes — and that it should not.
The question is not what a system is capable of deciding. It is what it should be allowed to decide.
The test we use
Two things decide where the gate goes.
What does being wrong cost, and who pays it? Misfiling a document costs a minute. Sending the wrong message to a prospective client costs a relationship you have not started yet. Recording a payment against the wrong invoice costs an afternoon of unpicking and a conversation with a customer. The cost is rarely proportional to how often the system gets it right.
Is the judgement the work, or around the work? A salesperson's job is deciding the price. Producing the document that carries the price is not the job; it is the tax on doing the job. One of those should be automated and the other should not, and the line between them is usually obvious once someone asks.
Everything else — reading, matching, formatting, routing, looking up — is repetition, and repetition is what a system is for.
It has to be the design, not a setting
The gate has to be load-bearing from the start, because a gate added late is a gate that gets removed early.
Our own outreach system drafts every message and sends none of them. Sourcing, qualification, enrichment and drafting run unsupervised. Then everything stops and waits for a person to read it, change it, or throw it away.
That could have been a preference with a default. It is not, and it will not become one. A system that can post in your name without you reading it first will eventually post something you would not have said, and the week it happens is the week nobody trusts anything it produced before.
The payment-advice work we have scoped for an instrumentation manufacturer in Pune is built the same way. Reading the advice and matching it to open invoices is the system's job. Posting to the ledger waits for approval — not as a safety feature, but because that is where the design puts the decision.
The gate can make the system braver
There is a counter-intuitive benefit. A system that knows a person is going to look is allowed to be uncertain, and that makes it useful much earlier.
The document scanner we are building extracts values from a photograph of a receipt — crumpled, badly lit, at an angle. Sometimes it will misread one. It recommends a category and shows what it read, and a person confirms or corrects it with the receipt still in hand.
Without the review screen, every reading would have to be right, and the product would be years away. With it, the system can be roughly right and still save the work — because the cheapest moment to catch an error is immediately.
Name the categories out loud
The most valuable hour in one engagement was spent deciding what the automation would refuse to touch.
Support email was arriving across several mailboxes and becoming a tracked issue only when somebody noticed. The system now reads it, classifies it, checks it against what already exists, and raises the ticket. But a list of categories was deliberately excluded — the kinds of enquiry that need a person to read the room rather than the message.
That list was the support lead's, not ours. It made the system smaller. It also made it something people would let near their inbox, which no amount of accuracy would have achieved on its own.
What to ask
If you are being sold automation, ask what the system will refuse to decide, and who wrote that list.
If the answer is that it handles everything, you are being sold something that will be switched off the first time it is confidently wrong about something expensive. If the answer names specific decisions and the person who still owns them, you are being sold something that will still be running in a year.
GAURVENA