What we chose not to automate

A vehicle leasing operation sends the same handful of routine emails constantly. Welcome messages when a customer comes on board. Confirmations when something completes. Nobody was forgetting to send them — they were being sent reliably, by a person, over and over.

That's a good automation candidate: high frequency, no variation, low stakes if it's a few minutes late.

There is no AI in it. It's a fixed template that pulls the customer's details out of the system. It cost nothing to build beyond the time, and it costs nothing to run — no per-message charge, no monthly bill, nothing to review before it goes out.

It's worth being blunt about this, because it's where a lot of money gets wasted right now. Put a language model behind those emails and you'd have something more impressive to demo, a bill every month for the rest of the system's life, and output that needs checking because it's generated rather than fixed. For an email that says the same thing every time, that's worse in every dimension.

AI earns its cost where the work involves reading unstructured documents, drafting something genuinely different each time, or handling variation that rules can't cover. Sending the same message with a different name in it is not that.

In the platform, a deal moves from Quoted to Pending Order once the customer agrees the quote. It's a status change. Someone drags it from one column to another and it takes a second.

It's automatable in the narrow sense. The system knows a quote was sent; it could infer agreement from a reply, or from a signature, or from a date passing.

We left it manual, because the thing that actually changes the status doesn't happen inside the software. It happens on a phone call. A customer says yes. Any automated version of that is inferring a real-world event from a proxy, and every proxy is wrong sometimes — a reply that isn't agreement, a signature on the wrong document, a date that passes while the deal is still being negotiated.

The cost of getting it wrong is a pipeline that shows orders that don't exist. Once a team stops trusting the pipeline, they start keeping their own list, and now you have two systems again.

One second of human effort, in exchange for a status column that's always true. That's a good trade and it isn't close.

The test isn't whether something can be automated. Almost anything can. The questions worth asking:

• How often does it actually happen? Something that happens twice a month isn't worth building around, however annoying it is.
• Does the trigger live inside the system? If the real-world event happens on a phone call or in a car park, automating it means guessing.
• What does a wrong answer cost? Low stakes and reversible, automate freely. High stakes and hard to detect, keep a person in it.
• Would plain software do it? If the task is fixed and repetitive, ordinary code does it with no ongoing cost. Reach for AI when the work genuinely varies.
• Does it still need checking? An automation whose output has to be reviewed every time hasn't removed the work. It's moved it.

Anything built on an AI model charges per use, every month, indefinitely, and that cost sits with whoever owns the system.

That's not an argument against it. It's an argument for knowing the number before you commit, at your real volume, compared against what the step costs you today. Sometimes automation is clearly worth it. Sometimes the honest answer is that the current way is cheaper.

Both are fine answers. Only one of them usually gets said out loud.