What a fixed-price AI quote should contain
What should a fixed-price AI quote include?
A fixed-price AI quote should name the workflows in scope, the accuracy and latency thresholds it will be measured against, the first-year running cost, who owns the code and prompts, and an explicit exclusions list. A quote missing any of these is a number, not a commitment.
Fixed-price sounds like protection for the buyer, and it can be. It can also be a number attached to a scope so vague that every awkward request becomes a change order. The difference is entirely in what the document says. This guide lists the eleven things a fixed-price AI quote should contain, what each one protects you from, and the specific wording that should make you push back before signing.
1. The workflows in scope, named individually
Not "customer service automation". Instead: order status, return initiation, exchange requests, refund status. Each named intent is a unit of work with its own integration, its own edge cases and its own evaluation set. When scope is written as a category rather than a list, both sides are guessing, and the guess is resolved later at your expense.
Ask for the list to be extracted from your own data. On a discovery sprint we cluster two months of real tickets or calls by intent, because the intents a team believes it handles and the ones that actually arrive are rarely the same list.
2. Acceptance thresholds, agreed before the build
This is the clause most quotes skip, and the one that decides whether you can ever say the project is finished. It should read like a measurement: on a held-out set of your real inputs, the system achieves at least X% correct resolutions, at most Y% escalations, and a p95 response under Z seconds.
Without thresholds, acceptance becomes an argument about impressions. With them, both sides know what "done" means on day one, and the vendor has to build an evaluation suite to prove it rather than demo their way through sign-off.
3. The evaluation set itself
Who builds it, how large it is, and who signs it off. A hundred to three hundred real cases with verified correct answers is the working range. It should be assembled from your inputs, not from a public benchmark, and you should own it at the end. It is the asset that lets you switch vendors later without starting from zero.
4. Integrations, listed with their access route
Each system named, plus how it will be reached: documented API, database read, file drop, or screen automation as a last resort. Integration is where fixed-price projects most often bleed, and almost always because a system that was assumed to have an API turned out to have a nightly CSV export and a support contract that forbids direct access.
The quote should also say who provides sandbox credentials and by when. A two-week delay in access is a two-week delay in delivery, and the contract should say whose delay it is.
5. The human-in-the-loop design
What happens when the system is not confident, and what happens when it is wrong. Which intents run autonomously, which need approval, what the reviewer sees, and how a case escalates to a person with context rather than as a cold ticket. This is product design, it takes real effort, and if the quote does not mention it you are buying something that will hand your customers to a confused agent. The pattern is described in human in the loop.
6. The rollout plan, including shadow mode
A launch date is not a rollout plan. Expect: a shadow period where the system proposes and a person decides, a named duration for it, the criteria for granting autonomy per intent, and a rollback path. Anyone who proposes going straight to full autonomy on day one is either very confident or has not done it before.
7. First-year running cost
Modelled, not hand-waved: inference at your expected volume, infrastructure, channel and provider fees, and the care plan. It should state the assumptions, because that is what makes it checkable. If the quote assumes 20,000 requests a month and you are planning a campaign that will triple that, better to find out on paper.
Our inference cost calculator uses the same model we use in quoting, and provider rates are published openly, so you can verify the inference line against the source pricing yourself.
8. Ownership, stated plainly
Code, infrastructure definitions, prompts, fine-tuned weights, the evaluation set and the documentation. All of it should be yours on payment, with any pre-existing vendor tooling licensed to you inside the deliverable. Our terms are on the terms of service page, and this is a clause worth reading closely wherever you buy.
Watch for quotes that grant you the application code but retain the prompts, or that describe the evaluation suite as the vendor's methodology. Both are ways of keeping you.
9. What is excluded
A good quote is explicit about what it does not cover. Typical exclusions worth seeing named: data cleaning beyond a stated volume, new integrations discovered mid-build, content writing, third-party licence fees, load beyond a stated ceiling, and changes to the acceptance thresholds. An exclusions list is not a vendor protecting themselves at your expense; it is the thing that makes the fixed price real.
10. The change process
How a new requirement gets priced, who approves it, and how long a change order takes to agree. Projects change. The question is whether changing costs you a week of email or an hour.
11. Support and what happens when the model changes
Model providers deprecate models on their own schedule. The quote should say what happens then: who re-runs the evaluation suite, who pays for the migration, and what the response target is. If that is not covered, a vendor's obligation quietly ends at launch and the first provider update becomes your emergency. Our care plans name response targets and cover exactly this.
A clause-by-clause checklist
| Clause | What good looks like | What to push back on |
|---|---|---|
| Scope | Named intents or workflows, extracted from your own data | A category name such as "support automation" |
| Acceptance | Numeric thresholds on a held-out set of your inputs | "To the client's satisfaction" |
| Evaluation set | 100–300 real cases, built jointly, owned by you | No mention of one at all |
| Integrations | Each system named with its access route and who supplies credentials | "Standard integrations included" |
| Escalation | Confidence thresholds, reviewer queue, warm hand-off design | Silence, or a line about fallback to email |
| Rollout | Shadow period with a duration and autonomy criteria per intent | Go-live date only |
| Running cost | Inference, infrastructure, channel fees and care, with stated volume assumptions | "Usage billed at cost" with no model |
| Ownership | Code, prompts, weights, evals and docs transfer on payment | Application code only, or prompts retained |
| Exclusions | An explicit list, including volume ceilings | None listed |
| Change control | A named process and turnaround time | "Changes will be discussed" |
| Model deprecation | Who re-runs evals and who pays, with a response target | Not addressed |
Print that table and mark each row against the quote in front of you. In our experience the ones that fail are rarely dishonest; they are written by firms that have not yet run a system through its first provider migration and genuinely do not know these rows exist. That is still your risk to carry, and the difference shows up six months in.
If you are comparing several proposals, normalise them against this list before comparing prices. A quote that is 30% cheaper because it excludes the evaluation suite, the shadow period and the running-cost model is not cheaper; it has simply moved those costs to a later invoice or to your team. We cover how to run that comparison in how to choose an AI development company.
The quick test
Read the quote and ask: could a competent engineer who has never met either of us pick this up and know what to build, and would they know when they were finished? If both answers are yes, the fixed price means something. If the document could describe four different projects, the number in it is decoration.
One more test that costs nothing: ask what the vendor would refuse to do. A partner with production experience has opinions about scope that is a bad idea, and will tell you before you pay for it. We turn down work at discovery stage regularly, which is the entire point of a paid discovery ending in an honest go or no-go.
There is one more thing worth asking for that almost nobody includes: a named engineer. Not an account manager, and not "a senior team member". The person who will architect the system, with their availability stated. Agencies that rotate staff mid-project rarely say so in advance, and the cost of that rotation is paid in context that has to be rebuilt from scratch.
Frequently asked questions
Is fixed price always better than time and materials?
▾
Not always. Fixed price suits well-defined scope with clear acceptance thresholds. Exploratory work with genuinely unknown requirements is often better on a time basis, with a small fixed-price discovery first to make the scope definable.
What if the acceptance thresholds are not met?
▾
The quote should say. Usually the vendor continues at their own cost until thresholds are met, or the project ends with a defined deliverable handover. Either is fine; silence is not.
How detailed should the exclusions list be?
▾
Detailed enough that you can picture the argument it prevents. Data quality, integration surprises, volume ceilings and threshold changes are the four that cause most disputes, so those should be named explicitly.