Five automations we would argue against building

A healthy automation portfolio retires 30–50% of its candidates before anyone writes code. A portfolio with a 0% kill rate does not have unusually good ideas; it has decorative gates. So the question worth putting to any advisor, us included, is which automations they argued against last. Here are five, with the arithmetic.

Twelve runs a year cannot keep an automation alive

A task that runs monthly and takes ninety minutes is eighteen hours a year. At Bulgaria’s 2025 hourly labour cost — EUR 12.0, the EU’s lowest, against an EU average of EUR 34.9 (Eurostat) — that is about EUR 216 of annual labour; at the EU average, about EUR 628.

Back-office automation is normally held to a payback under twelve months, so clearing that bar means building, integrating, monitoring and maintaining the thing for under EUR 216. And the real cost is not the happy path: Flaviu Cristian’s observation, cited by Temporal, is that failure handling is more than two-thirds of a production system.

The second problem is that a low-frequency automation cannot be operated. Break rate is a per-hundred-runs figure; twelve runs a year give twelve data points. Microsoft Power Automate retains run history for thirty days, so when December’s run fails, November’s is gone — and it switches flows off after ninety days without trigger activity, putting any quarterly automation inside the shutdown window by design.

Do this instead: attack the ninety minutes, not the twelve occurrences. One fixed export, one saved query or one template usually takes the task to twenty minutes for a day of work, with no permanent maintenance surface.

When exceptions outnumber rules, automation relocates cost rather than removing it

Process mining consistently shows the top five variants covering 60–80% of volume, with a tail of hundreds behind them. A flat distribution means there is no process to automate — there are habits. And if conformance fitness against the documented model lands under roughly 0.8, that documented process is fiction, and so is any specification written from it.

The break-even is one inequality. Let p be the share of cases the machine completes untouched, t the minutes saved on each, and x the extra minutes an exception now costs. Automation pays only while p / (1 − p) exceeds x / t.

The term people set to zero is x, and it is never zero. The reviewer inherits only the hard cases, plus a partial machine result they must audit before trusting or discarding it. Accounts payable is the best-documented example: touchless rates move from 20–30% to 65–80% on PO-backed invoices, but residual exceptions settle at 15–30% in year one on a real supplier mix. Vendors quote the numerator; contract on the denominator.

There is a harder finding underneath: in document-heavy back office, a large share of exceptions are upstream data defects — a wrong PO reference, missing vendor master data, a changed IBAN — which no model fixes and no confidence threshold routes away.

Do this instead: code an exception taxonomy from several hundred real cases before scoping, with those data defects split out as their own line. Often the recommendation that survives is to fix the vendor master and buy nothing.

An automation retired before payback was a write-off on the day it was scoped

If the payback target is twelve months and the ERP cutover is nine months out, the arithmetic is finished before kickoff. The sharper loss is the integration surface, which dies even where the process survives: UI selectors recorded against the old GUI go to zero, and SAP’s clean-core doctrine is explicit that anything written against unreleased tables or screen recording is debt an S/4HANA upgrade breaks — silently, with the run still reporting success.

The dangerous version is not the announced migration but the one nobody mentioned in the workshop. Two questions cost nothing: when does the ERP contract renew, and when was the last major upgrade?

Do this instead: during a freeze, build only the layer outside the core — ingestion, validation, master-data screening, exception queues, orchestration — against released APIs and side by side rather than inside the system. That layer survives cutover, and the process-mining baseline you built to decide becomes the migration’s own before-and-after measurement.

Schema validation cannot catch a field that quietly changed meaning

A data contract is an enforced agreement between producer and consumer on four things: schema, semantics, freshness and ownership. Defensive coding covers three. A type change throws. A null throws. A late file trips a freshness check.

Semantics fail silently and at full throughput. Status code 4 used to mean delivered; after an upstream release it means delivered to hub. The field is present, correctly typed, in range, and now wrong — so the automation keeps running and the first person to notice is a customer. Add at-least-once delivery without an idempotency key and the corrective re-run posts everything twice.

The test is therefore organisational. Put the four commitments on one page — schema stability with a stated deprecation window, the meaning of every status value, a freshness SLA against the decision cadence, a named owner reachable when it breaks — and ask the upstream owner to sign. If they will not, they have told you how much notice you will get.

Do this instead: ship the assertion suite before the automation — dbt tests, Great Expectations or Soda running daily against the producer’s output, alerting the producer rather than you, scoped to the five to fifteen critical data elements this use case consumes. Run it a quarter. Their response time to those alerts is the data you needed; if nobody answers, you have bought a no-build decision for the price of a test suite.

Automation proposed to avoid a conversation delivers that conversation anyway, later and worse

The tells are consistent. The sponsor cannot name the process owner whose queue changes. The request is to reconcile two teams’ spreadsheets rather than decide which is authoritative. The benefit is fifteen minutes each for forty people — and a saving under roughly 0.2 FTE per person, spread across a department, never consolidates into anything Finance will book.

The worst version is automating a rework loop. Repetition rates of 20–40% on price and payment-term fields are ordinary, and usually the largest hidden cost in the process. Automate the loop and you have made rework cheaper, therefore more frequent, and pushed the cost upstream where nobody measures.

There is a version the law drags into the open anyway. Behaviour-based task allocation and employee performance monitoring sit in Annex III of the EU AI Act, and Article 26(7) requires workers and their representatives to be informed before such a system runs in the workplace — a duty landing on HR, not IT. GDPR Article 22 bars decisions based solely on automated processing with legal or similarly significant effect. The conversation happens; it just happens later, with lawyers in it.

Do this instead: write the decision the automation stands in for as one sentence and take it to whoever can make it. If an answer comes back, the automation gets smaller and better specified. If none does, you have found the real constraint, and it was never software.

Where this stops applying

Low volume plus high consequence inverts the first argument. A statutory submission — Bulgaria’s phased SAF-T reporting to the NRA has monthly sections — is automated for control, not labour: an error costs a penalty and a re-filing, not ninety minutes. Value the control and stop counting hours.

Where exceptions are the product rather than a defect — claims triage, clinical intake, complaints — automation belongs on routing, not resolution, and the metric is routing accuracy, not touchless rate.

One boundary about us. Palamed has four deliverable engagements: a European car marketplace carrying 300,000+ listings, the Ministry of Education and Science digital dictionary at beron.mon.bg, email-marketing automation for a beauty brand where the roughly 60% cut in outreach time is the client’s own measurement, and an NLP module that reads, classifies and drafts answers to trading questions arriving by email and Instagram from the product and pricing data the team already maintains — the client counted roughly 85% less manual typing on repeat questions, and a person approves every reply before it sends. We have not run an AP function or inherited a bot estate; the above is published pattern and the standards it rests on.

And it costs us to write. A discovery ending in “buy nothing” is the smallest invoice we produce, and the hardest to produce twice. We do it because MIT NANDA’s funnel — 60% investigated, 20% piloted, 5% implemented — is largely a record of gates nobody would fail anything at.