How to tell whether an automation was built to be reliable

An automation that fails is the smaller problem. A failure announces itself, somebody looks into it, and the matter is closed the same day. The expensive ones are the processes that keep running and produce wrong results without raising a single error. Those surface only when a customer complains, when a figure in a report does not match anyone's sense of the business, or when the month end does not reconcile.

The difference between the two ways of building is invisible in a quote and very visible in the price. Asking the right questions before you sign makes it visible too.

A schedule is not a dependency

The most common construction fault in automation is a schedule that merely asserts an order of events.

A typical picture looks like this. One process pulls revenue figures out of the ERP into a reporting table at two in the morning. A second process sends the daily report at six. The second depends on the first, but that dependency is written down nowhere. It exists only as four hours of gap that have been sufficient so far.

While the first process takes twenty minutes, this works. At month end, with several times the number of records, it takes five hours. The second process then punctually sends a report containing yesterday's position. It raises no error, because from its point of view nothing went wrong. It read what was there.

The same pattern repeats wherever several processes cooperate. The buffer is sized for the normal case and gives way in the exceptional one, which is precisely when the numbers matter.

The sound construction couples on completion rather than on the clock. The second process starts when the first has reported that it finished. If the first does not run, the second does not run, and somebody hears about it. That is a matter of hours of extra work, not weeks. It does require that somebody recognised the dependency in the first place.

Four questions that expose the difference

You do not need to read code to judge how something was built. Four questions are enough, and every one of them can be asked in a sales conversation.

What happens when a run fails? The weak answer is that it starts again at the next scheduled time. The missed window is then gone for good. The strong answer describes how the process catches up on what it missed, and how it notices that it missed anything.

What happens when the same item arrives twice? Duplicate processing is the standard failure mode after a retry. A process that issues the same invoice twice, or places the same purchase order twice, does more damage than one that does not run at all. The strong answer names the marker by which the process recognises an item it has already handled.

How does the process know its input is incomplete? A process that cheerfully continues on an empty result is the most expensive type there is. The strong answer describes a plausibility check: a report with no revenue in it is not sent, it is reported.

Who hears about a failure, and through which channel? A message to a shared mailbox that nobody opens after a fortnight is not a notification. The strong answer names a role in your company, not an inbox.

Why this is a question of price, not of technology

These four points explain why two quotes for the same process can sit far apart. The business logic is identical in both and built in a few days. The difference lies in what is built around it: restart behaviour, protection against duplicate processing, plausibility checks, readable logs, and a notification that reaches a person.

That part can double the effort. Whether it is needed depends entirely on what happens in the worst case. A process that writes an internal note may occasionally be wrong. A process that issues invoices, places orders, confirms delivery dates or reports figures to the board may not.

So state in the sales conversation what the worst imaginable error would be. That is the measure for how much protection has to be built, and only then does a price become comparable.

Existing processes can be checked in an hour

If automations are already running in your company, you do not need a supplier for a first assessment.

List every process that starts on a schedule and what each one expects as input. Wherever one process reads data that another process writes beforehand, you have found a hidden dependency. Then check how long the writing process actually takes on the busiest day of the month. If the gap to the next process is less than twice that duration, the buffer is too thin.

An hour of work gives you a list that is worth more in a supplier conversation than any specification document.

Sophera Consulting works through exactly these points before quoting a price: dependencies, restart behaviour, duplicate protection and notification paths are recorded in writing and then built for a fixed price, with no subscription and with documentation at handover. The entry point is the free Automation Check.

The recommendation

Do not judge a quote by whether the described process works when everything goes well. It does, in every quote. Judge it by whether it describes what happens on failure, on retry, and on empty input, and who is told about it.

A supplier who raises those questions unprompted is calculating. A supplier who lets them pass has priced the normal case, and you will pay for the rest later.