There are four ways suppliers price automation work, and three of them transfer risk to you. Knowing which one you are being offered tells you more about a supplier than their case studies do.
The four models
-
Day rate
You pay for time. The supplier carries no delivery risk, and the slower the build the more they earn. It is the easiest model to sell and the worst incentive structure in the industry.
-
Time and materials with an estimate
A day rate wearing a suit. The estimate is not binding, so overruns land on you. Ask what happens when it goes over and watch how quickly the answer becomes vague.
-
Fixed price per project
The supplier carries the delivery risk. This only works honestly if the scope is written down properly first, which is why scoping is usually a separate paid step.
-
Retainer or subscription
Sensible for running and monitoring a live system. Dangerous as a way to pay for a build, because it has no natural end and no definition of done.
Why a fixed price needs a scope inside it
A supplier cannot quote a fixed price for work they have not examined. So either they pad the number heavily to cover the unknowns, or they bound the job: one task, one fixed fee, and a proper scope as the first stage of the work. That is how our pilot is built.
Where scoping is charged separately, the fee should be credited against the build if you proceed. Either way, you should keep the document. If a supplier will not let you walk away with the plan you paid for, that tells you what the relationship will be like.
What a good quote contains
Every integration named, including the awkward ones. The payback arithmetic with your own figures in it. A delivery date. The monthly running cost broken out. What happens when it fails and who gets the alert. If any of those are missing, the number is not really a quote.
Our version is on how we quote. There are no day rates and no charge for a proposal.
Questions we get asked
Is a day rate ever appropriate?
For genuinely open-ended exploratory work with no defined outcome, sometimes. For building a system that does a specific job, almost never. You are buying a working thing, not somebody diary.
Why do suppliers charge for scoping?
Because doing it properly takes real work: watching the task, naming every integration, and writing the arithmetic down. Free scoping is either shallow or recovered elsewhere in the price.
Should the build price include the first month of running?
It often does, and that is fine, as long as month two onwards is stated separately so you can see the ongoing number clearly.
What is a fair way to handle changes?
Anything in the scope document is the supplier problem. Anything you add afterwards is a change, priced separately. That line should be written down before work starts, not negotiated after.