The cost nobody budgets for

Automation projects are usually costed as a build.

They are a build plus maintenance, indefinitely.

Screens change. Applications update. A vendor redesigns a portal. A published file gains a column. Each time, something breaks and somebody fixes it.

Companies that budget for this are satisfied. Companies that do not end up with a graveyard of broken automations nobody dares touch.

Make failure visible

The single most important thing.

An automation that fails and tells nobody is worse than none, because everyone assumes the work is being done.

Four things:

Log every run — started, finished, what it processed, what failed.

Alert a named person on failure. Not a log file. Not a shared inbox.

Alert on silence too. A scheduled job that did not run produces no error at all. Monitor for the absence.

Record what it processed, so when something is wrong you can see what it did and did not touch.

That third point is the one most commonly missed, and it produces the longest-lasting failures — because there is nothing to notice.

Ownership

Every automation needs a named owner.

Not a team. A person, who:

• Knows what it does and why
• Receives the failure alerts
• Fixes it or escalates it
• Knows which system changes might affect it

When that person leaves, ownership transfers explicitly.

The most common cause of an abandoned automation is that its author moved on and nobody inherited it.

Documentation that is actually useful

Short. One page. It answers what somebody will ask.

What it does, in two sentences.

Why it exists — what problem it solved.

What it touches — which systems, which accounts, which folders.

Known fragile points — which parts are most likely to break.

What to do when it fails — the first three things to check.

Who owns it.

That fits on one page, and it is the difference between a fixable automation and a black box.

Credentials

Four practices:

A dedicated service account, not a person’s login.

Stored in the platform’s credential store, not in the automation.

Expiry tracked. If the account is subject to a password policy, know when it will force a change.

Minimum access. An automation that only reads should not be able to delete.

Watching for changes upstream

The proactive part, and what separates well-run automation from constant firefighting.

Keep a dependency list: which automations rely on which systems.

Subscribe to release notes for those systems.

Test after a known update, rather than waiting for the failure.

Without the list, an announced change means checking everything or nothing.

Reconciliation

The most valuable habit here, and the least common.

A scheduled check that compares two systems and reports disagreements.

Rows in the source file against records created. Orders in one system against another. Counts, at minimum.

Why: failures are silent. Nothing errors — the systems just drift apart.

A weekly reconciliation catches that. Without one, you find out at month-end, or when somebody asks about data that never arrived.

Reviewing what you have

Once a year, per automation:

Is it still running? Some quietly stopped.

Is it still needed? The process may have changed.

What has it cost to maintain? Hours spent fixing it.

Is the saving still there? Compare against the original baseline.

Switching one off is a valid outcome. An automation that costs more to maintain than it saves should go. That is a good decision.

Scaling up

If it works and you build more, three things change.

You need central scheduling and logging across automations, rather than each managed separately.

You need naming conventions. Twenty automations named inconsistently become unmanageable.

You need shared components. The same login sequence, the same notification format, reused rather than rebuilt — so when it changes, you fix it once.

Without these, twenty automations is far more than four times the work of five.

The realistic picture

Expect to spend time on this. Not much per automation, but not zero, and it does not stop.

A rough guide: a few hours a month across a handful of automations, rising with the number and with how fragile they are.

Which is why keeping the fragile parts small matters. An automation that touches one screen breaks less often than one that touches twelve.

The short version

Automation is not a build. It is a build plus permanent maintenance, and the maintenance decides whether it pays.

Make failure visible, including the case where a scheduled run simply did not happen.

Give every automation a named owner and one page of documentation.

Add reconciliation, because silent drift is the failure you find late.

And review yearly. Switching off something that costs more than it saves is a good decision, not a failure.