On this page
- What an AI automation build actually costs
- The five dimensions that set the price
- Why three vendors quote three different numbers
- Estimate the build before anyone quotes you
- Fixed price or time and materials
- The costs that arrive after the invoice you approved
- What each phase of the build costs you in attention
- The brief that lowers your quote
- Terms your vendor and your finance team use differently
- Before you sign
What an AI automation build actually costs
The build price of an AI automation is set by three things: how many systems it has to touch, how accurate it has to be before a human stops checking every output, and whether the process is already written down anywhere. The model is rarely the expensive part. Quotes for the same request routinely differ by a factor of several, and the reason is almost never the day rate. Different vendors are pricing different scopes. Ask every one of them for the written assumption list behind their number, and pay for a scoping exercise before you buy a build.
Nobody can price AI automation as a category, in the same way nobody can price construction as a category. What is stable across projects is the cost structure, even when the totals are not. This guide covers what sets the number, why quotes diverge, and the line items that arrive after the invoice you already approved.
- 3 driversintegration count, accuracy bar, process clarity, roughly in that order of effect on price
- Unattendedthe accuracy bar that costs the most, because you have to build detection for failures nobody is watching
- Assumption listthe document that explains why two quotes differ, and the one no vendor sends unless asked
- Parallel runthe line almost every plan forgets, where you pay for the old process and the new one at the same time
The five dimensions that set the price
Price tracks surface area, not ambition. A team can build something impressive against one clean system in a fortnight and spend three months on something duller that touches four systems owned by four departments. These five dimensions explain most of the variance in scoping conversations, and each one has a probe question you can ask before a vendor is in the room.
The Price Surface
Five measurable dimensions. Score each one honestly before you ask for a quote, and you will predict the spread of the quotes you get back.
Every system in scope is an authentication story, a rate limit, a test account, a data owner who has to approve, and a set of failure modes you must handle. Two systems is more than twice the work of one, because the expensive part sits at the join: which system is the source of truth when they disagree, and what happens when the write succeeds in one and fails in the other. Count the systems, count the joins, then ask which of them has a sandbox. The one without a sandbox is your schedule risk.
The cost curve steepens sharply near the top. A system whose output a human reads before it is used needs a review queue and a decent interface. A system that runs unattended needs detection for the errors nobody is looking at: confidence signals, out of distribution checks, reconciliation against an independent source, and an alert somebody actually reads on a Sunday. Going from reviewed to unattended is often a larger piece of work than the original build, and it is usually promised as a phase two that nobody prices.
If nobody in the organisation can write the rule down, you are not buying engineering, you are buying research. Research has a different risk profile: it is timeboxed, it can end in a documented no, and it should be contracted separately with an explicit stop. The tell is when three people who do the job give you three different answers about what happens to an edge case, and all three are confident.
The number of known variants of the input. Every variant is a branch, a test case and a row in the eval set. Ask the people doing the work today for the list of things that always break, and treat that list as the scope rather than the happy path. If the list is empty, it is not because the exceptions do not exist. It is because nobody has written them down, which puts you back in the process clarity problem.
How often the underlying process changes. A process that gets restructured every quarter needs prompts in version control, an eval suite running in continuous integration, and a named person who owns the system after handover. That ownership is a real recurring cost and it belongs in the business case, not in a hope that the team will absorb it.
Why three vendors quote three different numbers
The spread is scope, not rate. Each quote shape carries silent assumptions, and the shape tells you which ones are hiding. Work out which row each proposal is in, then ask that vendor to write down the three assumptions that would most change their number if they turned out to be wrong. The quality of that answer beats the number itself.
| Quote shape | What it quietly assumes | What it leaves out | How it usually goes wrong |
|---|---|---|---|
| Fixed price from a one page brief | The happy path, one real integration, and inputs that are already clean | Error handling, the exception list, the sandbox that does not exist yet | Change requests start in week three, and the project becomes a negotiation about what was implied |
| Time and materials | Nothing, which is the honest option | A ceiling, and any incentive to finish | You need someone in house reading a weekly burn down against a plan, or it drifts quietly for a quarter |
| Platform licence plus configuration | That the platform already expresses most of your process | Everything the platform cannot express, which is exactly where your process differs from the average | The limit shows up in month two, and the custom work gets bought anyway on top of the licence |
| Fixed price after paid discovery | A scope that both sides wrote down and both sides signed | Very little, if the discovery was real work rather than three calls and a template | Discovery was theatre, so the assumptions were still guesses with a better font |
| Outcome or success fee | That the outcome can be attributed to the system | Everything about attribution, including what else changed that quarter | You spend the year arguing about the baseline instead of improving the system |
One more diagnostic. A vendor who quotes without asking about your exception list, your sandbox availability and who reviews the output has priced a demo. That is not dishonesty, it is arithmetic: without those answers there is no way to price the real thing, so the number that comes back is the number for the version that works on a good day.
Estimate the build before anyone quotes you
Do this before the first vendor call. The model below is deliberately crude, and its job is not to produce a price but to tell you the order of magnitude and which input dominates. Every number in it is yours: your day rate, your count of systems and variants, your view of how much of the work is evaluation and error handling rather than the path that works.
The five base days are scaffolding: repository, environments, secrets, logging, deployment. The calendar figure assumes two engineers at four productive days each per week, then adds your parallel run.
Now look at which term dominates. If the variant term is the biggest, your problem is scope discipline and the fix is a phase one that handles the top variants and routes the rest to a human, deliberately and visibly. If the system term dominates, your problem is access and integration, and the fix is starting the credential and sandbox conversations this week rather than after the contract. Neither of those problems is solved by finding a cheaper vendor, which is the reaction they usually produce.
Fixed price or time and materials
Fixed price is a risk transfer and you pay a premium for it. That is fine, as long as you have the one thing that makes it work: a written scope you are willing not to change. Time and materials is cheaper on paper and more expensive in practice for any buyer without someone reading the burn down weekly.
A demo of an AI workflow can be built in days, and it will look like the finished thing. The same workflow with retries and backoff, idempotency keys, a dead letter queue somebody reads, structured logs, an eval suite, access control and a written runbook is a different piece of work by a wide margin. If a quote sits close to what you think a demo costs, you are buying a demo. The cheapest test is to ask what happens on the third consecutive failure, and listen for whether the answer contains a queue and a human.
The costs that arrive after the invoice you approved
These are predictable, they are just not in the proposal, because a proposal is a document about building software and most of these are about running an organisation. Put them in your own business case before you compare quotes, otherwise the vendor who omits them looks cheapest.
- Parallel running. You pay for the old process and the new one at the same time until you trust the new one. Budget weeks rather than days, and decide up front what evidence ends the parallel run, expressed as a number on a named sample, not as a feeling.
- Access latency. Credentials, sandbox accounts and a security review often take longer than the build. The calendar runs whether or not anyone is writing code, and vendor teams sitting idle are usually still billing.
- Change requests from the business. The process will change while you are automating it. Agree a change budget in engineer days at contract time so the conversation is arithmetic instead of argument.
- The eval suite. Written once, maintained forever. Someone owns it or the system degrades silently the first time a model version changes underneath it.
- Model and infrastructure run cost. Its own arithmetic, and usually smaller than people fear and larger than the pilot suggested. The mechanics are in token cost arithmetic, and the per run version for agents is in costing an agent.
- Decommissioning what it replaced. Old records, old permissions, the shared spreadsheet three people still have open, and the retention obligation attached to all of it.
Take the three year view rather than the build view before you sign anything, because the ratio between build and run varies enormously by architecture and it is the ratio that decides whether a project is worth doing. That arithmetic is laid out in total cost of ownership for an AI system.
What each phase of the build costs you in attention
Money is not the only budget. Every phase costs your own people's time, and underestimating that is the most common reason a well priced project runs late.
Your cost is the time of the people who actually do the work today, not their manager. Two or three sessions of an hour each. If the vendor only speaks to the sponsor, the exception list will be wrong and you will pay for that in week seven.
Credentials, service accounts, a sandbox, a security questionnaire, a data processing agreement. This is your critical path and it is entirely inside your organisation. Start it before the contract is signed if you can.
The part that looks fast. A working end to end pipeline on good inputs appears surprisingly early, which is exactly why people mistake this milestone for being nearly done.
Exceptions, retries, partial failures, the record that exists in one system and not the other. This is the bulk of the engineering and none of it demos well. Expect the weekly update to look boring here. Boring is correct.
The system runs on real traffic and produces output nobody acts on, while a human does the work as usual. You compare. This is where your accuracy number stops being a promise and starts being a measurement.
Both processes live, then the old one goes off. Handover is source, prompts under version control, the eval suite, a runbook and an architecture note. If handover is a call and a folder of screenshots, you have bought a dependency rather than a system.
The brief that lowers your quote
Vendors price uncertainty. Every question you answer in advance removes a contingency line from their estimate, and a good vendor will say so. This template is deliberately blunt about the things people prefer to leave vague: whether a sandbox exists, how many exception variants there really are, and who reads the output before it is used.
# Automation brief, every field filled, which is what lets a vendor price it in days rather than weeks.
unit_of_work: "one supplier invoice posted to the ledger" # the single thing produced, end to end
volume:
per_day_today: 400
per_day_peak: 1100
seasonality: "month end triples volume for four working days"
systems:
- name: "NetSuite"
role: "write, source of truth for the posted record"
sandbox_exists: true
auth: "OAuth2 machine user, already provisioned"
rate_limit: "documented, we have the numbers"
owner: "Priya, finance systems"
- name: "SharePoint"
role: "read, where the PDFs land"
sandbox_exists: false # this is a schedule risk, say so out loud
auth: "not yet decided"
owner: "IT service desk, no named person yet"
inputs:
formats: ["native PDF", "scanned PDF", "photo of a printed invoice", "email body only"]
languages: ["English", "German"]
known_variants: 14 # count them, do not estimate them
awkward_cases_documented: "yes, see exceptions.csv, 40 real ones"
samples_available: 300 # real historical records, not synthetic
accuracy:
bar: "field level exact match on supplier, date, net, tax, total"
target: "97 percent on the 300 sample set, measured per field"
who_reviews: "queue, one clerk, all outputs for the first six weeks"
unattended_later: true # this changes the price, flag it now
cost_of_a_wrong_output: "a payment to the wrong supplier, recoverable but escalates"
constraints:
data_residency: "EU only"
personal_data: "supplier contact names, retention 7 years"
no_go: "no invoice content may leave our tenancy for model training"
success:
baseline_taken: true # if false, the first deliverable is the baseline
baseline_measure: "clerk minutes per invoice, current median 4.5"
target_measure: "clerk minutes per accepted invoice"
non_goals:
- "purchase order matching, phase two"
- "supplier onboarding"
commercials:
shape: "fixed price after a paid two week discovery"
change_budget_days: 10
decision_maker: "Group Financial Controller"
decision_date: "2026-10-15"
Two fields in there do most of the work. The count of known variants is what stops the exception surface from being discovered at your expense, and the sandbox flag is what stops a schedule from being built on an assumption. A longer walkthrough of how to write one of these, including how to establish the baseline that makes the success measure meaningful, is in writing an AI automation brief. If you would rather have the exception list and the baseline produced for you before you go to market, that is what an AI readiness audit is for.
Terms your vendor and your finance team use differently
- Unit of work
- The single thing the system produces end to end, such as one posted invoice or one resolved ticket. Every cost figure should be expressed per unit of work, because per run and per month figures hide different things and cannot be compared across vendors.
- Assumption list
- The written set of conditions a quote depends on, such as one integration, an existing sandbox, and inputs in a single language. A quote without an assumption list is a guess presented with a decimal point.
- Unattended
- The system acts on its output without a human reading it first. Unattended is not a configuration setting, it is a set of detection mechanisms you have to build and pay for: confidence signals, reconciliation against an independent source, and alerting that someone answers.
- Parallel run
- The period in which the old process and the new one both handle the same work so their outputs can be compared directly. It is the cheapest insurance in the whole project and the item most often cut when the timeline slips.
- Change budget
- A number of engineer days set aside in the contract for scope that changes during the build. Without one, every discovery becomes a commercial negotiation instead of a decision about the product.
Before you sign
Run this against the statement of work rather than the proposal. Proposals are written to be attractive and statements of work are written to be enforced, and the gap between them is where most disappointment lives.
Ask the vendor what they have refused to automate and why. Someone who has shipped these systems has a real answer with a specific process in it, usually one where the rule could not be written down or the cost of a wrong output was too high to accept. Someone who says they can automate anything has either been lucky or has not been running their own systems long enough to see them fail.
Questions readers ask next
How much does AI automation cost for a small business?
Why do quotes for the same AI automation vary so much?
Is it cheaper to build AI automation in house?
What is the most expensive part of an AI automation build?
Should I pay for a discovery phase before the build?
How do I stop the scope from growing during the build?
ChatGPTalker. "What AI Automation Actually Costs to Build." chatgptalker.com, 2026-08-26. https://chatgptalker.com/guides/what-ai-automation-costs/