What Makes an Automation Last

Systems do not fail, they drift

Automations rarely stop working outright. The business changes around them, a supplier alters a format, thresholds set two years ago stop matching reality, and gradually people work around the system instead of through it.

The tell is a parallel spreadsheet appearing. That is the leading indicator of abandonment.

1. An owner in the business

Not who maintains the code — who owns the outcome. Someone who notices when it drifts, decides on changes and answers questions about what it should do.

Unowned automations run for years after they stopped being useful, or stop being useful without anybody deciding. Naming the owner before the build is the cheapest longevity measure available.

2. Monitoring for absence

Alert when volume falls outside the expected range, when output is zero and normally is not, when field completeness drops, when a run finishes suspiciously quickly.

Errors get noticed. Silence does not, and silence is the failure mode that costs weeks.

3. Configuration over code

• Thresholds and tolerances editable by your team
• Routing and approval chains changed without a deployment
• New categories, sites and product types added without us
• Business rules that are likely to move kept out of code

The test at design time: which of these will you plausibly want to change in two years? Those go in configuration.

4. Documentation someone will use

Not a manual. A one-page architecture sketch, the deployment process tested by someone following it, the dependency list, and the decision records explaining why it is like that.

Decision records are the highest-value documentation a project produces and the cheapest to write — a paragraph at the time, ten minutes, and it prevents the same argument recurring every four months.

The annual review

Once a year: does this match how you work now, is the output still used, what manual exceptions could now be automated, has anything changed upstream, and should this still exist.

Two hours. It is the difference between a system that compounds and one that quietly becomes a liability.

Frequently asked questions