Should You Pay Your AI by the Job, Not the Seat?

Your AI vendor would prefer you forget the software exists. That's the quiet logic of a per-seat license: you pay the same whether one person logs in daily or nobody touches it all month. The vendor's best customer is the one who buys ten seats and uses three. You're billed for access, not work, which means a tool sold to do more of your work gets cheaper, per unit of value, the less of your work it actually does.

That's backwards, and founders are starting to notice. The pitch for outcome-based pricing is that it fixes exactly this: you stop renting a login and start paying for finished work. A resolved support ticket. A qualified lead. A closed book at month-end. The market is moving in this direction, pushed by agent companies like Sierra that bill per completed job instead of per seat. On paper it's the fairer deal. Cost tracks value. No more paying for shelfware.

I'd hold the applause until you've read the meter.

The model that punishes you for winning

Per-seat pricing has a flaw, but it has a virtue too: it's predictable. Twelve seats at a fixed rate is a number you can put in a spreadsheet in January and trust in November. You over-buy a little, you waste a little, and you always know the bill.

Per-job pricing trades that predictability for alignment, and the trade isn't free. When you pay per outcome, your bill scales directly with your success. Have a great quarter, double your support volume, three times the leads coming in, and the invoice climbs right alongside. The cost is real work getting done, so it's defensible. But "defensible" and "forecastable" aren't the same thing, and the founder who didn't model it gets a number in November that nobody put in the spreadsheet in January.

Here's the part that should make you slow down: the vendor defines what a "job" is. They decide whether a customer who replies four times is one resolved ticket or four. They decide whether a lead that bounces counts. They decide what trips the meter and what doesn't, and they wrote those rules to be paid, not to be audited by you.

The trap isn't the price. It's the meter you don't read.

I learned this the unglamorous way with a usage-based bill — not even AI, an SMS provider years back — that came in at roughly triple my forecast. The headline per-message rate was exactly what they'd quoted. What I hadn't read was that a single message over a certain length silently counted as two or three, and a good chunk of ours ran long. The rate was honest. The unit was the trap. Ever since, the first thing I do with any per-unit pricing is ignore the rate and go read the definition of the unit, because that's where the surprise always lives.

The failure mode with outcome pricing is almost never the headline rate. It's the definition underneath it. A founder hears "two dollars per resolved ticket," does the napkin math against last month's volume, and signs. What they didn't price: a "resolution" that fires every time the agent sends a message, or a "qualified lead" that counts anyone who fills the form, junk included. The rate looked honest. The unit was the trap.

So the question to argue isn't which pricing model is morally fairer. Both can be fair. The question is which one you can forecast and control. Per-seat is easy to forecast and bad at aligning cost with value. Per-job aligns beautifully and is brutal to forecast unless you do the work up front. Neither wins on principle. One of them wins for your specific usage, and you can't know which without running the numbers.

Before you sign, know two things cold

Know your cost per outcome at your real volume — not the vendor's pricing-page example, which is always built on numbers that flatter the vendor. Pull your actual ticket counts, your actual lead flow, your busiest month, and your worst, and run the per-job math across that whole range. Then know exactly what counts as a "job." Get the metering definition in writing. Ask what fires the counter, what doesn't, and what happens in the messy cases — the duplicate, the reopened ticket, the lead that asks one question and vanishes.

This is the 70/30 line in practice. The agent can do the mechanical 70% — pull the usage data, build the model, chart your cost under per-seat versus per-job across twelve months of real numbers. But someone with judgment owns the 30% that decides whether the deal is any good: reading the vendor's "job" definition for where it's quietly generous to them, pressure-testing the model against the quarter where everything goes right and the invoice spikes, and knowing which clause to negotiate before signing. That last 30% is the whole decision. The spreadsheet just sets it up.

My own line is simple: if I can't forecast next quarter's bill within about 20% from my own numbers, the alignment isn't worth it, and I'll take the slightly-worse flat rate I can actually put in a budget.

Pay per job when you've modeled the unit and can live with the curve. Pay per seat when predictability is worth more than perfect alignment. Just don't sign either one until you know what the meter actually counts.