What Happens to Your Automation After Sign-Off, and Who Is Responsible

Process automation is sold as a project, with a start, an end and a sign-off. That is the most consequential simplification in this business. A process that connects three systems is not a machine you buy once and then use. It is an agreement between systems, some of which belong to other companies, and those companies follow their own schedule.

Anyone who asks only about the project price before commissioning is buying half of it.

Why a finished process ages even when nobody touches it

Providers develop their interfaces and retire old versions. Some date their versions and guarantee each one a fixed lifetime, others announce a change when it suits their roadmap. With carriers and customs portals the deadline is occasionally tied to a regulatory date the provider cannot move either.

Alongside that sit the smaller changes. A portal alters a form field. A certificate expires. A password gets reset after a phishing scare. A supplier switches file format. None of that is a mistake, it is the normal course of things.

The more systems a process connects, the more often something happens. An order process in wholesale quickly depends on a handful of external interfaces: shop, ERP, carrier, accounting, mail delivery. That is not a measurement, it is a typical shape. If each of those connections changes something roughly once a year, an announcement lands in some mailbox several times a year.

The announcement arrives, just not with the right people

Providers almost always announce shutdowns properly. They send emails, keep a changelog, and some services even put deprecation notices into every response. What fails is the recipient.

The technical account runs on a shared address, or on the colleague who set the connection up two years ago and now works in another department. If the email does reach a person, it is often somebody for whom a sentence about a retired interface version triggers no action at all.

Then there is the missing inventory. Even when the right person reads the email, they cannot answer the next question: which of our processes actually uses that version? In most companies that list does not exist, so nothing happens. Nobody acts on suspicion.

The silent change costs more than the outage

A hard failure is unpleasant but honest. The process stops, somebody notices, at the latest the customer.

More dangerous are the changes that raise no error. If a field disappears from a response, the process starts writing empty values into the target system. If a status value gains a new variant the branching does not know, every transaction with that status takes the wrong path. If a provider lowers the default page size of a result set, the automation simply stops seeing part of the daily business. The calls still succeed, the log stays green, and the discrepancy only surfaces at month-end close.

No error alert finds these cases. You find them by reading the provider's change notes before the change takes effect.

The objection: fix it when it breaks

This objection comes up in almost every conversation, and it is not stupid. Why invest effort in a list when the outage will be noticed anyway and the switch takes half a day?

The maths works as long as the outage is cheap. Suppose a shipping process stops on a Tuesday morning and the switch takes two days because access to the new version has to be arranged and tested first. During that time two employees create shipping labels by hand in the carrier portal and copy tracking numbers back, with the errors that come with it. The actual rebuild would have taken the same time on an empty desk. What you pay for is the rest: manual work, late deliveries, complaints.

There is a second effect. Under pressure, migrations are done badly. Whoever migrates on the day of the outage takes the first mapping that fits, skips the test and builds in the next silent error.

What belongs in a handover, and what to ask for in a proposal

The effort needed to remove this problem is modest. It amounts to a list, two mailboxes and a calendar entry.

Ask for an inventory of connections: one line per connection with process, system, version, account and any known shutdown date. Building it takes a few hours for a mid-sized estate and afterwards answers in two minutes what would otherwise be a week of searching.

Ask that technical accounts sit on a distribution address with at least two people behind it. Personal mailboxes are out because of staff turnover, a generic catch-all because nobody reads it.

Ask for pinned versions instead of a pointer to whatever is current. Running on the latest version means receiving every change overnight. A pinned version moves the moment of surprise to a point you control.

And ask that failure notices go to the department that owns the process, not to a mailbox nobody opens. A notification nobody sees is not a notification.

Three ways to run it, and when each holds up

First, you run it yourself. That works when somebody in-house understands the processes, the inventory is maintained and the documentation was handed over in full. It is the cheapest route and the one that depends most on your own discipline.

Second, a fixed maintenance scope per year with an agreed response time. Sensible for processes whose failure costs money immediately, meaning anywhere goods do not ship or invoices do not get raised.

Third, work billed as needed. Defensible for processes whose standstill bothers nobody for a few days, internal reporting for example.

The deciding question is not what maintenance costs, but what one day of standstill for that process costs. If the answer exceeds the annual maintenance figure, the question is settled.

What to clarify before you sign

Do not ask only for the build price. Ask three things about the time afterwards: who receives the providers' announcements, who maintains the inventory of connections, and what happens concretely on the day a process stops. A proposal that leaves those three open is not cheaper than one that settles them. It only moves the cost to the worst possible moment.

Sophera Consulting hands over automations with documentation, an inventory of connections and access on company accounts, so you can run them yourself or hand operation over deliberately, at a fixed price and without a subscription. The entry point is free in the automation check.