Nobody Demos the Boring One

The automation that gets presented in a meeting and the automation that is still running two years later are almost never the same one.

The presented one does something visible. It reads a document and produces a summary, or holds a conversation, or generates a first draft. It demos well because you can watch it happen, and watching it happen is the point of a demo.

The one still running removes a step nobody enjoyed. A form submission becomes a record with an owner attached. A missed call generates a text within thirty seconds. A confirmed booking writes itself into two systems instead of one and a person. Nothing to watch. No moment where anyone says that's clever.

Why the dull one survives

Three reasons, and they compound.

It has fewer ways to be wrong. A summary can be subtly inaccurate in ways that take months to notice. A routing rule either put the inquiry in front of the right person or it did not, and you find out within the day. Narrow scope means legible failure, and legible failure means the thing gets fixed instead of quietly distrusted.

Nobody has to decide to use it. The impressive automation usually sits behind a choice: somebody has to open it, prompt it, review its output. That choice is made enthusiastically for a fortnight and then intermittently and then not at all. The dull one has no interface. It runs on an event, and events do not lose interest.

This is the part that gets underestimated at the point of purchase, because in a demo both kinds look equally used. The difference only shows up in month three, and by then nobody is running a comparison.

It gets more reliable as it gets more boring. Every exception you handle makes the process duller and more dependable. The version that survives has usually had all its interesting edges sanded off, which is exactly what happened to it and exactly why it lasted.

None of this is an argument against ambition. It is an observation about sequence. The ambitious version tends to be built on top of the dull one — you cannot usefully summarize a pipeline that is half-empty, or draft a follow-up for an inquiry that was never assigned to anybody. The unglamorous layer is not a lesser version of the impressive one. It is the thing the impressive one would need in order to work.

The adoption question answers itself

The most common worry before a project like this is that the team will not use it.

That worry is well founded and slightly misdirected, because it treats adoption as a behavioural question. It is a design question with a simple test:

Does this add a step to somebody's day, or remove one?

Anything that adds a step needs to be sold, trained, chased, and eventually mandated. It will be resented in proportion to how busy the person is. Anything that removes a step needs none of that. People do not have to be persuaded to stop doing something tedious.

Which is why the boring automations get adopted without anyone running an adoption programme. There is nothing to adopt. The work simply stops arriving.

The inverse explains a lot of abandoned software. A CRM that nobody opens is usually one that asked for effort and returned a report somebody else reads.

The one exception worth naming

There is a case where the impressive version is the right build, and it is worth being honest about it: when the tedious step being removed is genuinely a judgement call.

Reading a long document and pulling out the three things that matter is dull work, but it is not mechanical. Sorting inbound messages by what they are actually asking for is dull and not mechanical either. Those tasks look like the flashy category because they involve language, and they behave like the boring category because they run on an event and remove a step.

The distinction that matters is not how clever the technology is. It is whether a person has to decide to use it.

What this looks like when you choose

Given a list of candidates, the impressive ones will always sound like the better use of money. They are the ones that would change how the business feels. The dull ones sound like housekeeping.

The reliable filter is to ask what happens if each one silently stops working for a week.

If the answer is nothing much, someone would carry on as before, it was never load-bearing and the enthusiasm for it was aesthetic. If the answer is four inquiries would sit unassigned and we would probably lose two, that is the one to build, however unexciting it is to describe.

The same test works in reverse on things you already run. Anything that could stop for a week without consequence is a candidate for switching off, and switching things off is the cheapest improvement available to most operations. Nobody puts it in a proposal, for reasons the appointment-led page describes: the work that pays is rarely the work that presents.

There is a version of this work that photographs well and a version that pays. They overlap less than anyone would like, and the meeting is usually decided by the first one — which is one of the reasons most automation projects fail long before anybody writes a line of configuration.