Why is the cheaper proposal usually not the cheaper job?

Because scope is invisible in a total. One vendor priced the exception path, the reconciliation step and a month of tuning after go-live; the other priced the happy path and will treat everything else as a change request. Both numbers are honest descriptions of what their author intends to do, and the difference between them is not efficiency but coverage. The way to see it is to compare the two proposals against a brief you wrote yourself, so what is missing from one of them is visible as an absence rather than as a saving.

What does the running cost actually include?

Model or platform usage at your real volume rather than at a demo volume, the hosting, the monitoring, and the hours somebody spends each month on the exceptions the workflow hands back. That last item is the one left out of most quotes and is often the largest. Ask for a monthly figure in writing, multiply by twelve, and add it to the build price. That single sum makes most vendor decisions obvious in one direction or the other, and it is cheap to obtain.

Why ask what a vendor would refuse to build?

Because the answer is evidence about whether they have looked at your process or only at your budget. A vendor who has done this before will name something specific - a decision that should stay with a person, a data source too unreliable to build on, a step whose volume does not justify the work - and will explain why. A vendor who says they can do all of it is describing their sales position rather than your operation, and the parts they should have refused will surface during acceptance instead, when they are expensive.

What ownership questions matter on day one?

Where the code lives and who can read it, whose accounts hold the API keys, who can revoke access, and what you receive if the relationship ends next quarter. These are cheap to agree before a contract and unpleasant to discover afterwards, when the answer is whatever the vendor's default happens to be. The test is simple: ask what you would have on the Monday after you stop paying, and expect a specific answer rather than a reassurance.

Back to blog

Operations

Choosing Between Two Automation Vendors Who Both Said Yes

Both quotes look reasonable and neither is comparable. Five questions that separate them, none of which is about price.

Anton Fenix·September 8, 2026·3 min read

OperationsProcurementComparisonROI

The problem with two reasonable numbers

Two vendors, two proposals, both credible, one cheaper. The instinct is to treat the difference as efficiency. It almost never is.

Scope is invisible in a total. One proposal priced the exception path, the reconciliation, and a month of tuning after launch. The other priced the path where everything goes right, and will meet the rest as change requests. Neither is lying. They are describing different jobs, and the totals hide which is which.

Five questions, none about price

What baseline did you measure, and how? A vendor who cannot say where the current number came from will be free to invent the comparison later, when the project needs a result. The before figure has to exist before the after does, which is the whole argument in what a process audit must produce.

What is the build plus twelve months of running? Usage at your real volume, hosting, monitoring, and the hours a person spends each month on whatever the workflow hands back. That last item is missing from most quotes and is often the biggest. One sum, and most of these decisions resolve themselves - the same arithmetic that reading a quote is built on.

What would you refuse to build for us? The useful answer is specific: a decision that should stay with a person, a data source too unreliable to sit under a workflow, a step whose volume does not repay the work. A vendor who would build all of it has looked at your budget rather than at your process.

Who owns the code and the keys? Where it lives, who can read it, whose accounts hold the credentials, and what you have on the Monday after you stop paying. Cheap to agree now, unpleasant to discover later.

What happens when an integration changes shape? Every workflow depends on somebody else's release schedule. The good answer names how a silent change would be caught, which is a question worth asking before the build rather than after the first bad month.

What the answers are actually measuring

All five cost the vendor something to answer honestly. That is the point. A price is free to state and free to be wrong about; a refusal, an ownership clause and a running figure in writing are commitments, and commitments sort vendors in a way totals cannot.

When both answer well

Then you have a real choice rather than a trap, and the remaining differences - sequence, who is in the room, how change is priced - are ones you are qualified to judge. Choose the one whose refusal list you agree with. That list is the closest thing available to a preview of how they will behave when something goes wrong, which it will.

Frequently Asked Questions

01Why is the cheaper proposal usually not the cheaper job?+
Because scope is invisible in a total. One vendor priced the exception path, the reconciliation step and a month of tuning after go-live; the other priced the happy path and will treat everything else as a change request. Both numbers are honest descriptions of what their author intends to do, and the difference between them is not efficiency but coverage. The way to see it is to compare the two proposals against a brief you wrote yourself, so what is missing from one of them is visible as an absence rather than as a saving.
02What does the running cost actually include?+
Model or platform usage at your real volume rather than at a demo volume, the hosting, the monitoring, and the hours somebody spends each month on the exceptions the workflow hands back. That last item is the one left out of most quotes and is often the largest. Ask for a monthly figure in writing, multiply by twelve, and add it to the build price. That single sum makes most vendor decisions obvious in one direction or the other, and it is cheap to obtain.
03Why ask what a vendor would refuse to build?+
Because the answer is evidence about whether they have looked at your process or only at your budget. A vendor who has done this before will name something specific - a decision that should stay with a person, a data source too unreliable to build on, a step whose volume does not justify the work - and will explain why. A vendor who says they can do all of it is describing their sales position rather than your operation, and the parts they should have refused will surface during acceptance instead, when they are expensive.
04What ownership questions matter on day one?+
Where the code lives and who can read it, whose accounts hold the API keys, who can revoke access, and what you receive if the relationship ends next quarter. These are cheap to agree before a contract and unpleasant to discover afterwards, when the answer is whatever the vendor's default happens to be. The test is simple: ask what you would have on the Monday after you stop paying, and expect a specific answer rather than a reassurance.

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