Per-item pricing versus day rates for automation
Three ways to buy an automation build, what each one rewards, and the conditions per-item pricing needs to work at all.
Short answer. A day rate pays the supplier for time whether or not the system works. A fixed project fee pays for delivery whether or not it is used. A per-item fee set against the measured manual cost only earns once the system is processing real work, so the supplier carries the risk of it not working.
What each model rewards
Pricing is not a detail bolted on at the end. It decides what the supplier is rewarded for, and therefore what you get.
Day rate. The supplier is paid for effort. A build that takes longer earns more. Nothing about the fee depends on whether the system ever replaces the manual work.
Fixed project fee. Better, because overruns are the supplier's problem. But the fee is earned on delivery, not on the system being used. A build that is handed over and quietly abandoned is a completed project.
Per item, against the measured manual cost. The fee is a proportion of what the job costs to do by hand, charged per item the system processes. If it never goes live, it never earns.
Why the baseline has to be measured first
Per-item pricing only means anything if both sides agree what the manual version costs. That number has to be measured and signed off before anything is built, for two reasons.
It stops the supplier overstating the baseline to inflate the fee, and it stops the client disputing the fee later. Everything is charged against a figure both parties agreed in advance, which removes the argument entirely.
The costing method is the same one either side would use.
Charge per unit, not per cent of savings
A share of savings sounds equivalent and is not. If nobody is made redundant, payroll is unchanged, and the client reasonably asks what they are paying a share of.
A per-unit fee avoids that entirely. It is countable, it appears on an invoice, and it can be checked against the number of items processed. £2.40 per claim where the manual version measured £12 is a fact both sides can verify.
Where it does not work
Per-item pricing needs a countable unit and enough repetition. Some work has neither.
- Processes with no discrete unit to count
- Volumes too low for a proportion of the cost to be worth recovering
- One-off migrations and integrations, which have no ongoing item to price
Where the unit does not exist, the honest answer is a fixed price for the build rather than forcing the work into a model that does not fit it.
Related questions.
A day rate pays the supplier for time regardless of whether the system works or is ever used. A build that takes longer earns more, which rewards the wrong thing.
A share of savings is hard to verify. If nobody is made redundant, payroll is unchanged and the client reasonably disputes what they are paying a share of. A per-unit fee is countable and appears on an invoice.
The work needs a countable unit, such as a claim, invoice, application or booking, and enough repetition that a proportion of the cost is worth recovering over time. Without both, a fixed build price is the honest structure.
Both parties, in writing, before anything is built. That prevents the supplier overstating the baseline and prevents the fee being disputed later.
Describe the process you want to automate.
You will receive a fixed price and a build plan.
There is no charge for the initial call and no obligation. You deal directly with the engineer who builds the system.