Stop fighting your software and fix the plumbing

An automation repair specialist, who is paid to fix other people's broken workflows, describes the two jobs that arrive more than any others. One is a routine that has run cleanly for months and then, without warning, starts writing every record twice. The other is a routine that reports success on every run while writing nothing at all.

The second one is the expensive one. A connection that fails loudly gets fixed the same day, because somebody is standing in front of it, cross. A connection that lies gets fixed a quarter later, when a number in a report finally looks wrong, and by then nobody can say which fortnight the data stopped meaning anything.

Most businesses we look at are running somewhere between three and a dozen of these. Nobody owns them. They were built by whoever had a spare afternoon, in a tool sold on the promise that joining two systems is a matter of clicks. That promise is broadly true, and it is also the problem. When something is nearly free, it gets built without anyone asking what it is for. Our connectors and business intelligence work starts by taking the existing connections apart and asking that question of each one.

The outcome test

Before we build a connection, we make ourselves write one sentence: what changes for a person in this business, measured the way that person already measures their week.

A sentence that passes: nobody re-keys a supplier invoice against a purchase order, and the office manager gets back the four hours that job takes every Friday. Another: the crew's paperwork reaches invoicing on the day of the job, so the invoice goes out in the week the work was done instead of the month after.

A sentence that fails: the CRM and the ledger will be in sync. Sync is not an outcome. It is a description of two databases agreeing, which is worth nothing to anybody until you can say who stops doing what.

If the sentence cannot be written, the connection should not be built. That rule alone removes a surprising share of the plumbing in a typical estate, and every connection removed is one that can no longer fail quietly in the background.

The four ways a connection lies

The public reviews of the mainstream automation tools are remarkably consistent, and they are worth reading before you buy one, because the failures are structural rather than accidental.

It disconnects without notice. A marketing director described logging in daily as the only way to tell whether an automation had made a mistake or had simply decided not to run. A media producer described connections dropping with no clear notice. A managing director in education described the same connections dropping repeatedly. The pattern is an expired credential and no channel to tell anyone about it.

It duplicates on a retry. An operator building an order flow found that the platform's API would time out after the record had already been created. The automation, seeing a timeout, retried, and the business ended up with two of everything. The connection did exactly what it was told; it had simply never been told how to recognise its own earlier work.

It delivers part of a transaction. A builder of an invoicing flow was left with invoices half created when a module in the middle of the chain failed. Half a transaction is worse than none, because none is visible and half looks finished.

It raises an alert that is not real. An HR generalist described getting alerts about a lost connection, logging in to check, and finding everything fine. Two or three of those and people stop reading the alerts, which means the real one goes past unread.

None of this is confined to the automation tools. Owners describe bank feeds inside their accounting platform breaking on their own, and one described whole months where transactions could not be imported. That is not a fault to hold against a product; it is what a connection across an ownership boundary does when nobody has designed for it failing.

What a connection has to do before we call it finished

Four things, and they are cheap when they go in at the start and expensive when they are retrofitted after a bad quarter.

A run log with a row per run, readable by someone who is not technical, showing what came in, what went out and what was skipped. A key that makes a repeat safe, so the same record arriving twice writes once, which is the whole answer to the retry problem. A failure that is loud, going to a person by name and not to a shared inbox, and stating what did not happen rather than the error text. And a refresh time on the face of every report the connection feeds, so a reader can see for themselves whether they are looking at this morning or at a Tuesday three weeks ago.

Fewer connections, each one accountable

Fixing the plumbing usually means ending up with less of it. A dozen connections that nobody owns become three or four that someone does, each with an outcome written against it, a log, and a person whose name is on the failure notice.

That is not a smaller ambition. It is the difference between an estate that quietly rots and one that a business can build on. The systems themselves are rarely the thing worth fighting. The software you already pay for usually does its own job well enough; what fails is the space between the systems, which no vendor owns and which therefore falls to you.

We start by counting what is there, what each connection was meant to achieve, and what it costs in hours a month when it does not. That count is the beginning of how an engagement runs, and it is worth having whether or not anything gets built afterwards.