Dispatch kept phoning the coordinator until the automated morning list became decorative
A practitioner post on dev.to catalogues five signs that staff have quietly stopped feeding a working automation. Three of them are computable from timestamps your workflow already writes, so adoption belongs in the build plan.
The Engineer · Build desk

What happened
- A dev.to practitioner argues that most automations he has seen fail were still running on the day they were declared dead, with the server up, the workflow triggering on time and clean logs.
- In the case he describes, an owner opened the order-capture dashboard three months after rollout and found a fraction of the real order volume, with the rest still flowing through one sales coordinator's phone.
- Dispatch learned that the automated morning list was incomplete and kept calling the coordinator to confirm, which is the point at which the author considers the workflow dead despite running daily.
- The post sets out signals of quiet abandonment and puts the threshold at any two of them appearing together, which it treats as an automation on life support.
- It argues the workarounds are rational, because the dual-run period adds data entry on top of the real work while nobody reduces the load to make room for it.
Why it matters
- What it limits constraint Green health checks cannot detect this class of death, because they measure whether the executor ran and not whether humans routed work through it.
- Who has to decide decision Since most of the listed signals are derivable from entry lag, per-submitter arrival gaps and who clears stuck records, an adoption panel is a build-time scoping choice rather than a post-mortem exercise.
- What it costs cost The dual-run period is unfunded labour charged to the person whose task was automated, so the budget that skips it is really shifting cost onto the one employee who can starve the system.
- Who's exposed exposure A single operator who is the only route to fixing stuck entries leaves the organisation with the same key-person dependency it had before the project, now with a software licence attached.
An uptime check asserts that the scheduler fired and the process exited clean. It measures your executor; it says nothing about where the work is actually flowing, which is why the author of the dev.to post can say his failed automations were still running on the day they were declared dead [1].
Read the distributor case as a denominator problem. The dashboard's numerator is orders that arrived through the link or the WhatsApp flow [4]. The denominator is real orders, and after three months most of those were still landing on the sales coordinator's phone, entered later, sometimes days later, sometimes never [5][6]. Nothing inside the system can measure the denominator, because the workaround is the thing hiding it. Dispatch worked this out faster than the owner did and kept calling her to confirm, which is what turned a generated list into decoration [7]. A list nobody trusts is cheaper to produce than one they do, which quietly erodes the efficiency the project was funded to deliver.
So you instrument proxies. Of the five abandonment signals the post lists, three are computable from data the workflow already writes [15]. Batching: take the gap between the event timestamp and the entry timestamp, per submitter, and look for clumps arriving in the evening or just before a review meeting, which the author reads as backfilling rather than working [11]. The downtime excuse: join each "the system was down" complaint against the health log, because when the log says up you have found an agreed social permission rather than a fault [12]. Concentration: count the distinct people who clear stuck entries, since one operator who is the only route to a fix is the pre-project single point of dependency in new clothes [13].
The other two signals need a human. A parallel Excel file, private group, or paper register does not appear in your telemetry, and the author's test for it is to ask casually where someone would check a detail from last Tuesday, then watch where they look [10]. Exception volume growing instead of being folded into the workflow is the other [14]. The author's threshold is that any two of the five together mean the automation is on life support [19].
The political half of this carries real weight of its own. The tasks worth automating are the ones a capable person currently controls, and the post argues their workarounds are rational: they absorb a dual-run period where feeding the new system is extra work on top of the real work with no load taken off them, and they eat the customer's anger when an automated reply quotes an outdated price [17][18][8][9]. My own posture, in my context: scope release one so it removes a step from the person who owned the task, not so it adds one, and accept capturing less of the process to get that.
What would have to be true for this to transfer. The failure needs a human input step and a side channel that the counterparty already prefers, which in this account is distributors phoning a coordinator [3]. Machine-to-machine ingestion has no equivalent bypass; it fails loudly, in a queue. Also worth pricing honestly: this is one practitioner's account of a pattern in distributor-led businesses, framed as political rather than technical, and "a fraction of the real order volume" is a description, not a measurement [16][5].
What to watch
- Whether anyone publishes a measured capture share for a case like this, since "a fraction of the real order volume" is a description and not a number.
- Whether the post's signal list is completed in full, as the published text breaks off mid-sentence on exception growth.
- Whether workflow tools start shipping an adoption panel next to run history by default, rather than leaving capture share to be built per project.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence28
- Adoption
- Not scored
- Hype gap+18
- Incentives55
- Confidence42
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
A dev.to post argues that most automations the author saw fail were still running on the day they were declared dead: the server was up, the workflow triggered on time, and the logs were clean.
- [2]
The post says what killed those automations was a person who quietly stopped feeding the system and went back to the notebook, WhatsApp group, or Excel file they trusted beforehand.
- [3]
In the pattern described, orders previously came in by phone calls and WhatsApp messages to one senior sales coordinator, who kept everything in her head and in a register.
- [4]
The owner had an order-capture system built: distributors got a link or a WhatsApp flow, orders landed in a sheet, stock was checked automatically, and the dispatch team received a clean list every morning.
- [5]
Three months later the owner opened the dashboard and found a fraction of the real order volume in it, with the rest still flowing through the coordinator's phone.
- [6]
When a distributor called the coordinator directly she took the order herself and entered it into the system later, sometimes days later, sometimes never.
- [7]
Dispatch learnt the morning list was incomplete and called the coordinator anyway to confirm, which the author says made the list decorative and the automation dead while it continued to run every day.
- [8]
The post describes a period where the person must run the old way and feed the new way at once, and argues that if data entry is extra work on top of the real work with no load reduction, working around it is triage rather than sabotage.
- [9]
The post says staff carry blame for the system's mistakes: when an automated WhatsApp reply quotes an outdated price, the customer shouts at whoever picks up the phone.
- [10]
Signal one is a parallel record: a personal Excel file, private WhatsApp group or physical register holds the real data while the system holds a delayed, cleaned-up copy; the author's test is to ask casually where someone would check a detail from last Tuesday and watch where they look.
- [11]
Signal two is data arriving in batches, ten at a time, late in the evening or just before a review meeting, which the author reads as someone backfilling to keep the owner satisfied rather than working inside the system.
- [12]
Signal three is frequent use of "the system was down" as an excuse; the author says to check the logs, and if the logs say it was up you have found a permission structure the team has agreed among themselves rather than a technical issue.
- [13]
Signal four is one person becoming the priest of the system: only she knows how to fix stuck entries, everyone routes through her, and the automation pauses when she is on leave, which the author calls the old single-point dependency in a new costume.
- [14]
Signal five is exceptions growing instead of shrinking; the author notes every workflow starts with genuine special cases and that in a healthy rollout they get folded in.
- [15]
Three of the five abandonment signals in the post (batch arrival timing, the downtime excuse checked against health logs, and single-operator concentration) are computable from timestamps and logs the workflow already writes, while two (a parallel record and exception growth) require human observation.
- [16]
The author frames the failure as a political problem rather than a technical one, and says it starts on day one if the automation is introduced the way most owners do.
- [17]
The author says the person working around an automation is usually not lazy or stupid, and is often the most capable employee, with rational reasons.
- [18]
The post says the tasks worth automating are the ones someone currently controls, such as enquiry handling, order entry, follow-ups and report preparation, so the owner of that task hears that what made them valuable is now a machine.
- [19]
The author lists signals of abandonment and says any two of them together mean the automation is on life support.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toAutomations die because staff work around them, not because of bugs
1 article · August 31, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Change ManagementFollow
- Shadow ProcessesFollow
- Operational ObservabilityFollow
- Workflow AutomationFollow
- Automation AdoptionFollow