Productized AI Services: Price the Run Before You Price the Offer

A productized service is supposed to be the easy version of consulting. Fixed price, fixed scope, same delivery every time, no more bespoke quotes. The standard advice is three moves: pick a narrow problem, name a price, write a deliverables list.

That advice was built for services whose main input is your own time. An AI service is not one of those. Every run of the thing you sold costs real money that leaves your account, the amount varies wildly with the customer, and you find out the total after the work is already done. A fixed price sitting on top of a variable cost is not a pricing decision. It is a position you are holding.

I want to be straight about where I sit before you read the rest. I run around fourteen launched products, which is productization taken to its end point: nobody gets a custom build, everybody gets the same software. I have not run an agency selling monthly AI retainers, so you will not find a setup fee or a margin percentage in this article that I invented to sound authoritative. What I can give you is the part I have actually been burned by, which is the arithmetic underneath a flat price, and the documents that decide whether a fixed-scope engagement ever ends.

The good news is that the four things that break a productized AI offer are all knowable before you sell one.

What a productized AI service actually is

The definition is not controversial. You take a service you would normally scope per client, freeze the inputs and the outputs, publish a price, and deliver it the same way every time. The client is buying a known result rather than a block of your attention.

The reason people want this is obvious once you have quoted a few custom projects. Custom work does not compound. Every proposal is new, every delivery is new, every invoice is a negotiation. A productized offer lets your second client cost you less to serve than your first one did.

The part that gets skipped is that productization only pays off if the cost of serving each additional client actually falls. That is the whole mechanism. And an AI service is the one category where it might not, because a meaningful slice of your cost per client is not your labor. It is somebody else's meter.

Why fixed-price AI offers lose money

Take a simple offer: you process a company's inbound support email, classify it, draft a reply, and hand the drafts to a human. You charge a flat monthly fee. Two clients sign up. One sends 800 messages a month. One sends 40,000.

In a labor-based service you would notice this immediately, because the second client would eat your week. In an AI service you might not notice for a full billing cycle, because nothing hurts until the invoice arrives.

Price the run before you price the offer

The order most people use is backwards. They pick a monthly price that feels right for the market, sell it, and then discover the cost. Reverse it. Work out what one unit of the work costs before you decide what a month of it is worth.

Model pricing is public and it is per token, which means you can compute this rather than guess. Anthropic's published API pricing is quoted per million tokens with separate input and output rates, and the same page works a real example: roughly ten thousand support conversations at about 3,700 tokens each, on the small fast model, comes to about thirty-seven dollars. That is the shape of number you need before you name a price, and you can produce your own version of it in an afternoon by running fifty real items through your pipeline and reading the usage figures off the responses.

Two levers on that page are worth building around rather than discovering later. Cached input is billed at a tenth of the standard input rate, which matters enormously when every run ships the same long instruction block. And asynchronous batch processing is half price on both input and output, which is free money for any work that does not have to finish in the next thirty seconds. A classification job that runs overnight has no business paying the interactive rate.

The three cost lines people forget

Token cost is the one everyone eventually finds. Three others sit next to it and get left out of the model.

The first is retries. Your pipeline does not run once per item. It runs, fails validation, and runs again. If one item in eight needs a second pass, your cost per item is not your cost per call.

The second is tool calls that carry their own meter. Anything the model reaches for outside itself may bill separately. On the pricing page above, web search is priced per thousand searches on top of the tokens it generates, and the content it pulls back becomes input tokens you also pay for. A research step that looks like one line of code is two meters running at once.

The third is the human. Every AI service that survives contact with a paying client has a person in it somewhere, checking the output before it goes anywhere irreversible. That person is a cost per unit, not a fixed overhead, and if you leave them out of the model you have not priced the service you are actually selling. I made this exact mistake framing my own image product, which is why it ships with a credit ledger rather than an unlimited plan. When the work is metered, the pricing has to be able to see the meter. I wrote up the plumbing behind that in a walkthrough of building and selling an AI image product.

Meter it even if you never bill on it

This is the recommendation I would make hardest. Instrument usage per client from day one, whether or not your price ever depends on it.

You need the number for three reasons: to know which client is unprofitable before the quarter ends, to have evidence when you raise a price, and to be able to move to usage-based billing later without rebuilding your product. Stripe's usage-based billing documentation is the reference for how this is normally modeled, and it contains a detail worth internalizing: on the older metering primitive, usage only reconciles when the invoice is cut. Real-time visibility into what a customer is consuming is something you either choose a platform for or build yourself. It is not automatic. A flat-fee service with no meter is a service where you learn about the problem thirty days late, every time.

Include a fair-use ceiling in the offer from the first version. Not to punish anyone, and not as a gotcha in the small print. Write it as a plain number in the deliverables list, with a stated price for the tier above it. Clients do not object to a limit they can see. They object to an invoice they did not expect.

The scope document is the product

In a normal productized service the deliverable is self-evident. You bought a logo, here is the logo. In an AI service the client believes they bought an outcome and you believe you delivered a pipeline, and the gap between those two beliefs is where every unhappy engagement lives.

The document that closes that gap is the scope. It is not paperwork attached to the product. For a fixed-price service it is the product boundary, and it is the highest-leverage thing you will write.

Split it into fixed and variable before you write a word

Go through your delivery and mark every element as one of two things: identical for every client, or different for every client. The fixed half is your margin. The variable half is your risk.

Then reduce the variable half deliberately. Not by refusing to customize, but by converting customization into configuration. "We tune the categories to your business" is variable and unbounded. "You pick up to eight categories from this list, or supply your own labels in the intake form" is configuration, and it costs you nothing after the first build.

The clause nobody writes

Here is the sentence missing from nearly every AI service agreement I have read: what happens when the model is wrong.

It will be. Not catastrophically, not usually, but a system that classifies or drafts or extracts will produce a bad result at some rate, and if the scope does not say who catches it and what the remedy is, then by default the answer is you, forever, for free.

Write it explicitly. Name who reviews output before it is used. State the review step as part of the deliverable rather than as an implied favor. If the client is the reviewer, say that in the deliverables list where they will read it, not in a clause at the bottom. If you are the reviewer, that is a per-unit labor cost and it belongs in the arithmetic from the previous section.

The reason this matters commercially, not just legally, is that an unstated error policy converts a fixed-price engagement into an open-ended one on the first bad output. You do not get to argue about it after the fact. The client's expectation was set by silence.

Intake is where the margin dies

Every open-ended question on your intake form is a small hole in the fixed price. "Tell us about your business" produces a paragraph somebody has to read, interpret, and turn into configuration. Ten clients in, that is a part-time job you are not charging for.

Structure the intake as fields with defined shapes: choices, numbers, uploads with a stated format, a URL. If you cannot express an input as a field, you have found a piece of the service that is not productized yet. Either productize it or price it as an add-on with its own line.

This is also, incidentally, where an automated research step earns its keep. Rather than asking a client twenty questions, you can gather most of the context yourself from public sources and confirm it with them, which is a much shorter conversation. I went through the mechanics of doing that without producing generic output in a piece on automating client proposals.

You are selling something you do not own

Underneath your offer is a stack of things that belong to other companies: a model provider, a data source, a hosting platform, some APIs. Every one of them can change its price, its terms, its capabilities, or its existence, and none of them will consult you first.

This is not hypothetical and it is not rare. I have watched a platform retire an entire pricing model that a whole category of guides was still recommending, and I have watched a dated API version get sunset on a schedule that had nothing to do with my roadmap. The integration does not break because you made a mistake. It breaks because someone else shipped.

The practical responses are unglamorous and they work.

Keep the model behind an interface you control, so swapping providers is a change in one place rather than a rewrite. Never build the core of an offer on a data source whose terms prohibit what you are doing, because that is not a technical risk, it is a business that can be turned off. Read the deprecation policy of anything you depend on before you sell an annual contract against it. And put a real clause in your agreement about upstream changes, so that a provider's price increase is a conversation rather than a loss you absorb silently.

The one thing I would not do is promise a specific vendor in the offer. Sell the outcome. Keep the stack yours to change. Clients almost never care which model wrote the draft, and the ones who do care are asking a compliance question that deserves a real answer rather than a brand name.

Delivery or access decides your next two years

There is a fork in every productized AI service and most people take it by accident.

Either you hand the client a running system they own, or you give them access to a system you run. Both are legitimate. They are completely different businesses.

Handing over the system means a one-time fee, a handoff, and a support relationship that ends or converts to a care plan. It scales in the sense that you are not on the hook forever, and it does not scale in the sense that every client's copy drifts and every fix is bespoke. If you go this way, the handoff is the deliverable, and the documentation is not optional.

Giving access means recurring revenue and one codebase, which is genuinely better economics, but you now run a service with uptime expectations, you hold the client's data, and you own every incident at two in the morning. The metered cost problem from the first section is entirely yours.

Pick deliberately, write it into the offer, and do not blur the two. The worst version is selling a handover and then supporting it like a subscription, which is what happens by default when nobody decided.

I built out the client-website version of this trade in an earlier piece on handing clients a site they can actually maintain, and the same logic applies to any AI deliverable: the question is not what you build, it is who is holding it in six months.

What you are actually allowed to promise

A productized offer is a public claim. It says, in writing, that a thing will happen for a price. That puts the marketing copy inside a regulatory frame that most builders never think about.

In September 2024 the FTC announced a sweep it called Operation AI Comply, taking action against several companies over deceptive AI claims. The cases included firms promising that AI would help consumers make money through online storefronts. The line from the announcement worth pinning above your sales page is that there is no AI exemption from the laws already on the books.

Translate that into three rules for your offer page.

Do not promise a business outcome you do not control. "Saves your team roughly six hours a week on ticket triage" is a claim you can support with your own measurements. "Doubles your revenue" is a claim about the client's business, and you cannot support it.

Do not describe capability you have not tested. If your pipeline handles English inbound reliably and you have not tried anything else, the offer says English.

Keep whatever evidence you used. If you publish a number, you should be able to produce the run it came from. This is the same discipline as not inventing statistics in a blog post, applied to the page where money changes hands.

None of this is legal advice and I am not a lawyer. It is the version of the rule that a solo operator can actually follow.

If you want to see the whole thing assembled rather than described, the session I built around this is the Agentic Offer Studio, which walks through an application that finds qualified clients, crawls their sites for real context, and generates tailored offers, proposals and build plans from what it finds. The full replay is available instantly, along with the app itself, so you can take the offer-generation half and point it at your own niche rather than rebuilding it.

Price the structure, not the number

I am not going to hand you a number, because a number I have not billed is fiction and there are plenty of articles willing to supply one.

What I will give you is the shape that survives the cost problem.

Charge a setup fee that covers the configuration work, and set it high enough that a client who never converts to recurring has still paid for your time. Charge recurring for the running system, and attach a stated usage allowance to it, expressed in the client's units rather than in tokens. Nobody buying support automation knows what a token is. They know what a ticket is. Price the overage tier in advance so it is a menu item rather than a negotiation. And keep one line on the sheet for genuinely custom work, priced by the day, so that requests outside the scope have somewhere to go other than into your margin.

The test of a good structure is simple: when a client doubles their volume, does your revenue move? If the answer is no, you are not selling a productized service, you are selling an option on your own costs.

What breaks

Five things, in rough order of how often I see them.

The heavy client. One customer generates most of your cost and you do not find out until the invoice. Fixed by metering from day one.

Scope drift by accumulation. No single request is unreasonable, and after four months the service is custom again. Fixed by a written boundary and somewhere to put out-of-scope work.

The silent upstream change. A provider changes a price, a limit, or an endpoint, and your margin or your uptime moves without any local cause. Fixed by monitoring and by an interface you control.

Support that was never priced. You sold a handover and are running a help desk. Fixed by choosing delivery or access on purpose.

The claim you cannot back. A confident sentence on the sales page turns into an argument later. Fixed by writing only what you have measured.

Building it: five steps and a weekend

If you want the shortest useful path from capability to offer, this is the order I would go in.

1. Pick one job you have already done manually more than three times. Not a category, a specific job with a specific output. The repetition is the evidence that it is worth productizing.

2. Run fifty real items through your pipeline and record the cost and the failure rate. This is the afternoon that decides whether the offer works. Read the usage numbers off the responses rather than estimating, and count how many items needed a second pass.

3. Write the scope document before the sales page. Fixed elements, variable elements, the intake fields, who reviews output, and what happens when a result is wrong. If you cannot write the error clause, you do not understand the service yet.

4. Decide delivery or access, and write the answer into the offer. Then price it with a setup fee, a recurring fee, a stated allowance in the client's units, and a published overage tier.

5. Sell it once by hand before you automate any of the delivery. The first client teaches you which half of your scope document was wishful thinking, and that lesson is much cheaper before you have built the pipeline around it.

The commercial version of an old distinction applies here: a prompt is a capability, and a system is something you can sell, because a system has boundaries.

Want the whole build rather than the theory

Everything above is the reasoning. If you would rather work from a finished implementation, the Reinventing AI Accelerator is where I put the working versions: live training sessions every week, plus the library of AI apps, agents and tools from previous sessions with the project files included, so you can take a build and point it at your own market instead of starting from an empty folder.

One small ask if you take nothing else from this: run the fifty items and write down the cost per unit before you publish a price. It is the cheapest hour in the whole process and it is the one nearly everybody skips.

FAQ

What is a productized AI service?

It is an AI-powered service sold at a fixed price with a fixed scope and a repeatable delivery, rather than quoted per client. The client buys a defined outcome and a defined set of deliverables. The difference from a traditional productized service is that a meaningful part of your cost per client is metered by a third party rather than paid in your own hours, which changes how you have to price it.

How do you price a productized AI service when the API costs vary?

Measure before you price. Run a real sample of the work through your actual pipeline, record the token cost, the retry rate, and any per-call tools that bill separately, and derive a cost per unit in the client's own units. Then set a fixed price with a stated usage allowance and a published overage tier, so a heavy client moves you into a higher band instead of quietly eating the margin. Instrument usage per client from the first day even if your price never depends on it.

Should I charge a setup fee or a monthly retainer?

Usually both, for different work. The setup fee covers configuration, intake, and the parts of onboarding that only happen once, and it should stand on its own if the client never continues. The recurring fee covers running the system and the ongoing cost of serving them. Charging only recurring means you finance the onboarding out of future revenue that may not arrive.

What should be in the scope document for an AI service?

At minimum: the specific inputs you accept and their format, the specific outputs you produce, the usage allowance and what happens above it, who reviews output before it is used, what the remedy is when a result is wrong, what is explicitly excluded, and how out-of-scope requests get priced. The error clause is the one most people omit and the one that decides whether a fixed-price engagement ever ends.

Can I build a productized AI service on someone else's platform?

Yes, and nearly everyone does, but treat the dependency as a commercial risk rather than a technical detail. Read the terms for whether your use is actually permitted, keep the provider behind an interface you can swap, check the deprecation policy before you sell an annual contract, and put a clause in your agreement covering upstream price and capability changes. The failure mode is not that the platform breaks. It is that it changes on its own schedule and your offer is already sold.