How do you value an AI automation?

The time it removes from a queue, multiplied by what that time costs, multiplied by how often the queue runs, minus the review it still demands. Three of those four change enormously between a small company and a large one, and so does the cost of deploying the identical system.

Why does the same AI automation cost more at an enterprise?

Because most of an enterprise deployment is access work rather than model work: a security review, a data processing question, a permissions model somebody approves, and an audit trail somebody can read a year later. At an SMB the person who owns the system is often the buyer and access takes an afternoon. A large part of enterprise pricing is the work of making the system deployable inside that company.

How does AI automation value differ by company size?

At an SMB the queue is usually a founder or one operator, so the time removed is the most expensive in the building, frequency is high and tolerance for setup is near zero. At mid-market the queue has a name and an SLA, so the automation moves a number somebody is accountable for, which makes it the easiest segment to sell into. At enterprise the queue is large and the hourly cost lower, but deployment cost and review burden rise sharply.

What most affects the value of an AI automation?

Review burden, and it is rarely quoted. An automation whose output a person still checks line by line has moved the time rather than removed it, and the value falls toward zero regardless of the demo. This is why narrow beats broad at every company size: an agent doing one thing nobody re-checks is worth more than an agent doing nine things somebody always checks.

Pricing AI Automation: SMB, Mid-Market, Enterprise

Why does the same AI automation sell for wildly different prices? Not negotiating leverage. The value of an automation is the time it removes from a queue, multiplied by what that time costs, multiplied by how often the queue runs, minus whatever review it still demands.

3 of those 4 numbers change enormously between a 12 person company and a 12,000 person one. So does the cost of deploying the identical system, and it changes in the opposite direction to what most people building these things expect.

The build is the same. The deployment is not

An agent that reads tickets, attaches account history and routes them is roughly the same agent everywhere. What differs is everything around it.

At an SMB you get access in an afternoon because the person who owns the system is in the room, and often is the buyer. At enterprise the same connection is a security review, a data processing question, a permissions model somebody has to approve, and an audit trail somebody has to be able to read a year later. The model work is a small share of an enterprise deployment. The access work is most of it.

Which means the honest version of enterprise pricing is not that the software is worth more. It is that a large part of what you are selling is the work of making it deployable inside that company, and that work is real.

SMB: the queue is a person

In a small company the queue with the longest wait is usually the founder or one operator wearing several roles. The time being removed is the most expensive time in the building and it is the constraint on everything else.

The frequency is high and the tolerance for setup is near zero. Anything that needs a 3 week implementation does not get adopted, regardless of how good it is, because nobody has 3 weeks. Value lands the same week or it does not land.

Pricing follows the shape: flat, predictable, self-serve, no procurement. The buyer is doing mental arithmetic against their own hourly rate and will decide in one sitting.

Mid-market: the queue has a name and an SLA

Somewhere around the point a company has a support team rather than a support person, the queue becomes a measurable thing with a target attached. Now the automation is not buying back a founder's evening. It is moving a number somebody is accountable for.

This is the easiest segment to sell an automation into and the one most often skipped, because it lacks the intimacy of SMB and the contract size of enterprise. The buyer knows their baseline, can run a 4 week comparison, and does not need a security review to try it.

Enterprise: you are pricing the access work

At enterprise the queue is large, the time is cheaper per hour and there is a lot of it, so the raw arithmetic still favors automation. But the deployment cost rises steeply and the review burden rises with it, because the tolerance for a wrong output that reaches a customer is much lower.

So value concentrates in places that look unglamorous from the outside. An audit trail that survives a compliance question. A permissions model that maps to roles that already exist. The ability to say precisely what the agent touched and when. None of that is model capability and all of it is what the deal turns on.

This is also where outcome pricing gets proposed and where it needs the most infrastructure behind it, because charging per resolved case means a failed case is an invoice nobody sends. I worked through what that requires in When Resolved Becomes a Price.

The number that decides all 3

Review burden, and it is the one nobody quotes. An automation whose output a person still checks line by line has not removed the time, it has moved it, and the value drops toward zero no matter how impressive the demo was.

Which is why narrow beats broad at every company size. The agent that does 1 thing nobody re-checks is worth more than the agent that does 9 things somebody always does, and it is worth more in a way that shows up in renewal rather than in the first invoice.

Everything else in this piece is arithmetic. That one is the product decision, and it is the same one that determines whether an internal automation survives contact with the team it was built for, which I went through in Automate the Handoff, Not the Task.