AI automation that survives contact with your business

There is a particular kind of meeting we have been in too many times. Someone demos an automation. It reads the email, classifies it, drafts a reply, files the attachment. Everyone agrees it is impressive. Six weeks later nobody is using it.

The demo was real. The automation worked. It just did not survive contact with an actual business, where the email arrives as a forwarded thread with the attachment missing and the sender asking about an order placed under a different name.

Automate the boring middle

The tasks worth automating are the ones nobody wants to describe in a meeting, because describing them is embarrassing. Copying figures from one system into another. Renaming files so they match a convention. Sending the same status chase every Tuesday afternoon.

They are unglamorous, high volume and identical every time. That last part is what makes them automatable.

Interesting problems are the opposite. They are fun to solve, they make good demos, and they happen rarely enough that the automation pays for itself sometime around the next century. If a task is genuinely interesting, it is usually because it needs judgement, which is exactly the thing you are trying to avoid encoding.

Log it before you build it

Before we build anything, we ask a team to log the task by hand for two weeks. Not estimate it. Log it, with timestamps.

One of two things happens, and both are useful.

Sometimes the real cost turns out to be a fraction of the estimate. The task everyone complains about takes eleven minutes a week. Now nobody builds anything and everyone saves money, which is a perfectly good outcome for a project.

Sometimes it turns out to be far worse than anyone thought, and now there is a precise map of where the hours actually go. That map is worth more than any tool selection, because it tells you which step to attack.

The estimate is always wrong. It is wrong in an unpredictable direction, which is why guessing is not a substitute.

The part the demo never shows

An automation is not a thing you build. It is a thing you own.

Every integration you touch will change its API, its rate limits or its auth flow eventually. Every workflow meets an input its author did not imagine. Automations do not fail loudly with an alert. They fail quietly, produce something slightly wrong, and keep going.

So before anything ships, three questions need answers. Who notices when it breaks. How do they notice. And what happens to the work in the meantime.

If the answer to the first question is nobody, you have not built an automation. You have built a liability with good intentions.

Where a language model actually earns its place

A model is very good at a narrow band of work: reading messy text and turning it into structure. Pulling an address out of a paragraph. Deciding whether a message is a complaint, an order query or spam. Summarising a call into three lines someone will actually read.

It is much less good as the load bearing wall of a process. If a wrong answer creates a wrong invoice, put a person between the model and the invoice.

The pattern that holds up is boring: the model proposes, a human confirms, the system records. You keep most of the time saving and you keep the ability to sleep.

Chatbots are an interface, not a solution

Most of the value in an automation sits in the plumbing. Clean data going in, a reliable trigger, and somewhere sensible for the output to land. Get those right and the interface barely matters. Get them wrong and no amount of clever prompting rescues it.

We have replaced more chatbots than we have built. Usually with a form and a well designed workflow behind it, which is less exciting and works considerably better.

When not to automate

Do not automate a process you are about to change. Do not automate something that happens four times a year. Do not automate around a broken process, because you will make the breakage faster and harder to see.

And do not automate a task purely because it is annoying. Annoying and expensive are different problems. The log will tell you which one you have.

If you have a process you think is worth automating, tell us what it is and roughly how often it happens. We will tell you honestly whether it is worth building, including when the answer is no.