The Cases Where the Honest Answer Is No

The volume is too low

A task performed four times a month cannot repay a build, whatever the per-instance saving. The arithmetic is simple and it is worth doing before the conversation goes further.

Multiply frequency by time by hourly cost. Compare against the build plus three years of running cost. If it does not clear comfortably, do something else.

The process is about to change

Automating a process that will be restructured next quarter means paying to encode something you are about to discard. Wait, and automate the version that will persist.

Nobody can say what correct means

If your own people disagree about the right answer for the same case, the disagreement is the problem. Resolve it first — that resolution is valuable regardless of whether anything is automated.

Building on top of an unresolved definition produces a system nobody will accept.

Three more

1. No owner — nobody will watch quality and it will drift unnoticed
2. The underlying process is broken — automation makes a bad process faster
3. The real fix is upstream — a required field would prevent the problem entirely

What to do instead

• Fix the input, so the problem stops occurring
• Simplify the process, then reassess
• Turn on the feature you already pay for
• Write the rule, if the decision is rule-shaped
• Do nothing, if it genuinely is not costing much

All five are cheaper than an integration and one of them is frequently the right answer.

Frequently asked questions