What should be itemised, at minimum?

Six things, and any of them missing is a question rather than a deal-breaker. The measurement or discovery stage, priced separately, because a quote produced without one is a guess about a process nobody has counted. The build itself, tied to a named process rather than to a technology. Integration per system, listed one by one, since integrations are where estimates go wrong and a single combined figure hides which one is the risk. The monthly running cost, which is the line most often absent. Handover, including what documentation exists at the end and who receives it. And support terms after go-live, with a response time attached to them. A quote with all six can be compared to another quote with all six, which is the only way the price comparison means anything at all.

What does a single-line total actually hide?

Which assumptions can move, which is the thing you most need to see. Automation costs are dominated by volume and by integration surface, and both are estimates rather than facts at quoting time. When they are itemised you can ask what happens at half the assumed volume, or what the price becomes if the fourth system turns out to need a different approach, and the answers tell you where the risk sits. When they are collapsed into one number, every later change becomes a renegotiation from a position where you have no idea which part moved. The vendor is not necessarily hiding anything; single-line quotes are often just lazy. But the effect is identical, and the request to break it out costs nothing and is refused surprisingly often.

Which running costs get left out most often?

Four, in our experience, and together they are the difference between a project that pays back in four months and one that pays back in eleven. Model and infrastructure spend per decision, which at real volume is a monthly line rather than a rounding error. The time of whoever handles escalated exceptions, which is a designed cost rather than a defect, and which requires an honest estimate of the escalation rate instead of an assumption that it is near zero. Maintenance when the surrounding world moves, because a supplier changes a form and a channel changes an interface and somebody has to notice and fix it. And the process owner's continuing time after handover, since an automation nobody owns degrades quietly while the reporting keeps looking fine. Ask for these as one monthly figure and add twelve of them to the build price before comparing anything.

What is the single best question to ask about a quote?

What am I not getting for this. A good vendor answers immediately and specifically, because they have already decided what is out of scope and why: the edge cases that stay manual, the system that will not be integrated in this phase, the report that is not included. A vendor who cannot answer has either not thought about scope or is avoiding the conversation until it becomes a change request, and both produce the same argument in month three. The follow-up worth asking is what happens when the assumptions turn out to be wrong, which is a question about how change is priced rather than about whether change will happen. It always happens. Quotes differ in whether they admit it in advance.

Back to blog

Operations

How to Read an Automation Quote Before You Sign It

The shape of a quote tells you more than the total. What is missing from the page is usually what you will be arguing about in month three.

Anton Fenix·August 24, 2026·5 min read

OperationsProcurementAutomationStrategy

Read the shape before the number

Most quote reviews start at the total and work backwards, which is the wrong order. The total is a conclusion. The structure is the evidence.

A quote is a description of scope wearing a price, and the first thing to check is whether the scope is defined by the process being automated or by a list of deliverables that could describe almost anything.

"AI integration, discovery, implementation, testing, deployment" describes every project ever quoted. "Booking intake across four channels, availability resolved against asset state, agreement generated from your approved template, dispatch scheduled" describes one.

What should be on the page

Line	Why it matters
Measurement or discovery, priced separately	A quote without one is a guess about an uncounted process
Build, tied to a named process	Not to a technology, which could mean anything
Integration, per system	Estimates go wrong here, and one combined figure hides which system is the risk
Monthly running cost	The most commonly absent line, and the one that decides payback
Handover, and what documentation exists	Decides whether you own the result or rent it
Support terms, with a response time	Otherwise "we'll be around" is the whole commitment

Any of these missing is a question rather than a deal-breaker. All six present means the quote can be compared to another quote with all six, which is the only way a price comparison means anything.

What a single-line total hides

Which assumptions can move.

Automation costs are dominated by volume and by integration surface, and at quoting time both are estimates. Itemised, you can ask what happens at half the assumed volume, or what the price becomes if the fourth system needs a different approach. The answers show you where the risk sits.

Collapsed into one number, every later change becomes a renegotiation from a position where you cannot tell which part moved.

Single-line quotes are more often lazy than dishonest. The effect on you is the same either way, and asking for a breakdown costs nothing and is refused surprisingly often.

The four costs that go missing

Model and infrastructure spend per decision, which at real volume is a monthly line rather than a rounding error.

The time of whoever handles escalated exceptions. This is a designed cost, not a defect, and it needs an honest escalation-rate estimate rather than an assumption of nearly zero.

Maintenance when the world moves. A supplier changes a form, a channel changes an interface, and somebody has to notice and fix it.

The process owner's continuing time after handover, because an automation nobody owns degrades quietly while the dashboards keep looking fine.

Ask for all four as one monthly figure, add twelve of them to the build price, and compare those totals. The four questions that break most ROI numbers then have something to work on, because payback at three to six months cannot be checked at all without a monthly cost.

Two structural things worth checking

The payment schedule. If every milestone is a date rather than a working thing, you are funding elapsed time. At least one payment should be tied to something running in production that you can look at.

The timeline against the scope. We put one to three workflows into production in two to four weeks, so a quote for a single workflow measured in months is describing different work — possibly a replacement project, possibly a discovery exercise with a build attached. Neither is wrong, but you should know which one you are buying.

The best question to ask

What am I not getting for this.

A good vendor answers immediately and specifically, because they have already decided what is out of scope: the edge cases that stay manual, the system not integrated in this phase, the report not included. Ours should tell you which parts stay with a person by design, since that boundary is deliberate rather than a limitation.

A vendor who cannot answer has either not thought about scope or is postponing the conversation until it becomes a change request. Both produce the same argument in month three.

Before any of this arrives

The quote is easier to read when you already know the answers. Count your own volume from your own systems, name the owner, and know which of your systems is authoritative for each disputed field.

That is the same preparation described in what makes a process map worth having, and it converts a quote review from an exercise in trust into an exercise in arithmetic. If the numbers in the quote disagree with yours, you have a specific conversation rather than a general unease.

And if the readiness conditions in when not to automate yet are not met, the best-written quote in the world is still a quote for the wrong project.

Frequently Asked Questions

01What should be itemised, at minimum?+
Six things, and any of them missing is a question rather than a deal-breaker. The measurement or discovery stage, priced separately, because a quote produced without one is a guess about a process nobody has counted. The build itself, tied to a named process rather than to a technology. Integration per system, listed one by one, since integrations are where estimates go wrong and a single combined figure hides which one is the risk. The monthly running cost, which is the line most often absent. Handover, including what documentation exists at the end and who receives it. And support terms after go-live, with a response time attached to them. A quote with all six can be compared to another quote with all six, which is the only way the price comparison means anything at all.
02What does a single-line total actually hide?+
Which assumptions can move, which is the thing you most need to see. Automation costs are dominated by volume and by integration surface, and both are estimates rather than facts at quoting time. When they are itemised you can ask what happens at half the assumed volume, or what the price becomes if the fourth system turns out to need a different approach, and the answers tell you where the risk sits. When they are collapsed into one number, every later change becomes a renegotiation from a position where you have no idea which part moved. The vendor is not necessarily hiding anything; single-line quotes are often just lazy. But the effect is identical, and the request to break it out costs nothing and is refused surprisingly often.
03Which running costs get left out most often?+
Four, in our experience, and together they are the difference between a project that pays back in four months and one that pays back in eleven. Model and infrastructure spend per decision, which at real volume is a monthly line rather than a rounding error. The time of whoever handles escalated exceptions, which is a designed cost rather than a defect, and which requires an honest estimate of the escalation rate instead of an assumption that it is near zero. Maintenance when the surrounding world moves, because a supplier changes a form and a channel changes an interface and somebody has to notice and fix it. And the process owner's continuing time after handover, since an automation nobody owns degrades quietly while the reporting keeps looking fine. Ask for these as one monthly figure and add twelve of them to the build price before comparing anything.
04What is the single best question to ask about a quote?+
What am I not getting for this. A good vendor answers immediately and specifically, because they have already decided what is out of scope and why: the edge cases that stay manual, the system that will not be integrated in this phase, the report that is not included. A vendor who cannot answer has either not thought about scope or is avoiding the conversation until it becomes a change request, and both produce the same argument in month three. The follow-up worth asking is what happens when the assumptions turn out to be wrong, which is a question about how change is priced rather than about whether change will happen. It always happens. Quotes differ in whether they admit it in advance.

Next step

Discovery Sprint

If that argument holds for your operation, the next step is measuring it. Thirty minutes on one process, and we say whether the arithmetic is likely to close.

Put a time in the calendar

Thirty minutes, free. The sprint is what the call is about.

Fee: $2,500
Length: 1-2 weeks

Refunded in full if we conclude you should not build.

Or start with the free 15-minute diagnostic

Keep reading