Skip to content

Build Not yet confirmed elsewhere1 publisher 3 min read Published

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

Send a correction

Illustration accompanying Dispatch kept phoning the coordinator until the automated morning list became decorative
Generated illustration

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
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [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.

    Reported Supported Source: dev.to post, "Automations die because staff work around them, not because of bugs"View cited source
  2. [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.

    Reported SupportedView cited source
  3. [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.

    Reported SupportedView cited source

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.

Add to ChatGPTAdd to Claude

Sources

1 independent publisher whose own reporting we read for this story.

  1. dev.to

    1 article · August 31, 2026

    Automations die because staff work around them, not because of bugs

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Loading related stories