People ask what an automation costs to run and expect the answer to be about the AI. It almost never is. The model is usually the smallest line on the invoice.

Take something ordinary. A process that reads a few hundred emails a month, pulls out the useful details, and files them somewhere. The model charges for the text it reads and the text it writes back, and at that volume the monthly bill lands somewhere between a cup of coffee and a takeaway meal. That is the part everyone worries about.

Here is what actually costs money.

The last one is where the business case usually goes wrong. A demo shows the task taking ten seconds instead of thirty minutes and everyone does the arithmetic on a full thirty minutes saved. In practice somebody still reads what came out. The half hour becomes five minutes rather than zero, which is still a very good trade, and it is not the trade that was pitched.

The monitoring line is the one people cut first and regret. An automation that fails loudly is an inconvenience. An automation that fails quietly, keeps running, and produces confident nonsense for three weeks is an expensive problem, and it costs very little to be told when it stops behaving.

What we suggest to clients: put a spend cap on the account before the first line of code, because a cap turns a runaway bug into an annoyance instead of a bill. Run the process on last month’s real work before committing to it. And count the review time honestly when you decide whether it is worth doing.

Done that way, most small automations pay for themselves inside a few months and then keep going for the price of the hosting. That is a good outcome. It is also a duller one than the version in the sales deck.

Get a real number for your case ›››

All posts ›››