Senthil Info

automating business processes, honestly

Looks Automatable, Isn't

Some processes look like ideal candidates and are not. They share a property: the visible work is clerical and the actual work is judgement, so a demonstration on clean data succeeds and production does not.

Six patterns, all common in proposals. For a product-side reference related to workforce operations, Monitask also covers workforce optimization software.

The six

Judgement with a clerical wrapper. Credit approvals, expense exception handling, supplier onboarding decisions. Someone opens a screen, checks things, types a result. The typing is automatable; the checking is the job. Automate the wrapper and you have added a handoff to the same decision. For broader background and an independent point of comparison, see McKinsey Operations.

High input variance. Invoice processing across three hundred suppliers in eleven formats. Not high volume — eleven processes wearing one name, and the cost sits in the classification layer that nobody quoted.

Processes that exist because a system is bad. Re-keying between two systems, reconciliations that exist because a sync fails, manual checks added after an incident. Automating these makes them permanent and makes the eventual system replacement harder, because now there is an integration nobody wants to unpick.

Processes nobody owns. Three departments touch it, none is accountable. The project will inherit that ambiguity and stall in month three on a decision nobody can make. This is the failure that looks technical and is not.

Low-volume, high-value work. Twelve instances a month of something that takes a day each. The hourly saving looks large and the fixed build cost does not scale down.

And anything where being wrong is expensive and rare. Payments, compliance filings, safety checks. Rare failures are the hardest to detect and the most expensive to have missed, and the automation removes the human who would have noticed.

The question that separates them

If this went wrong, would anyone notice, and when?

Immediately and visibly — good candidate. Errors surface, get corrected, and the automation improves.

Eventually, at the month-end — workable, with a reconciliation step designed in.

Only when a customer or regulator finds it — this is the expensive quadrant. The saving is real and the tail risk is not priced in any vendor model.

Thirty seconds, and it is more discriminating than any feasibility assessment.

Why demos do not reveal this

A demonstration uses curated data. The clean path, the standard supplier, the well-formed input. That is not dishonest — showing the exception path would demonstrate nothing about the product.

And the demo has no month three. No system update, no new supplier format, no staff turnover in the team handling exceptions. The pilot has the same problem.

So the demo shows you the process at its most automatable, which is exactly the presentation that makes a bad candidate look like a good one.

What to do with a false candidate

Not nothing — three of the six have better answers than automation.

Judgement work: automate the data gathering, leave the decision. A screen that assembles everything the decider needs is genuinely valuable and is a smaller project.

Bad system underneath: fix or replace the system. More expensive, and it removes the process instead of preserving it.

High input variance: standardise the inputs first. A supplier portal, a required format, a template. Usually cheaper than a classification layer and it improves the manual process immediately.

Unowned processes: assign an owner. This costs nothing and it is a precondition for anything else.

The pattern underneath

All six fail for one reason: the part that was expensive was never the part that gets automated.

Which is the same finding as everywhere else in this subject, and it is why the selection step predicts the outcome better than the platform and better than anything a vendor can offer.

The short version