What does AI automation cost a small business?

Quoted pricing answers a narrow question — what the licence costs — and the licence is rarely what decides whether the project pays. Three other costs do, and all of them are predictable enough to budget for, which is what separates a project that survives from one that is quietly abandoned with the subscription still running.

The first is integration. An automation is only useful if it can see what the business already knows, which means connecting to whatever holds customers, jobs, calendars and messages. Where those systems have proper interfaces this is configuration. Where they do not — an older field service package, a bespoke database, a scheduling tool with no export — it is development work, and the cost is unrelated to the licence fee. The single most useful question to ask before committing is what this needs to connect to and whether those connections exist off the shelf.

The second is maintenance, and it is the one most often omitted entirely. An automation encodes assumptions about how the business works: which fields mean what, which statuses exist, who owns which step. Every time the business changes something upstream, those assumptions can go stale, and the automation carries on running with them. That is worse than breaking, because a broken automation is noticed immediately and a stale one quietly does the wrong thing for a month. Budget for someone reviewing it on a schedule rather than for fixing it when it fails.

The third is ownership, which is a staffing cost rather than a software one and is the usual reason automations decay. Somebody has to hold the answer to what this does, why it is configured this way and what to do when it misbehaves. In a small business this is normally a fraction of one person's role, and it is normally assigned to nobody. An unowned automation survives until the first person who does not understand it decides to turn it off, and the deciding factor in whether it survives longer is whether that person exists at all.

Against those, the pricing models are worth understanding because they distribute risk differently. Per-seat pricing is predictable and penalises adding occasional users. Per-conversation or per-message pricing scales with success, so a working automation costs more, which is defensible but must be modelled at the volume you expect rather than the volume you have. Outcome-based pricing sounds attractive and requires close attention to the definition of the outcome, since the supplier is defining what counts as one. None is inherently better; what matters is that the model is stress-tested at a volume several times current.

The honest budgeting rule is to treat the licence as one line among four and to insist on the other three being estimated before signing anything. A project priced only on subscription is not under-priced by a little; it is missing the categories that most often make the difference between an automation still running in two years and a line item nobody can explain.