Short answer
Cost separates into four parts that behave differently: discovery, build, integration, and run. Discovery and build are usually quotable as fixed scope. Integration varies enormously depending on whether your systems have usable APIs — this is the single largest source of estimate variance. Run costs are ongoing and are the line most often left out of a business case, which is why projects appear cheaper than they are.
Why quotes vary so wildly
Two vendors can quote the same workflow an order of magnitude apart, and neither is necessarily being dishonest. They are pricing different scopes. One is pricing a configured tool; the other is pricing integration with a legacy system that has no API, plus the reconciliation work that implies.
The four cost components
- Discovery — mapping the workflow, measuring volumes, defining the boundary. Fixed and comparatively small, and skipping it does not save money, it defers cost to the build.
- Build — the system itself. The most predictable component and usually not the largest.
- Integration — connecting to what you already run. Modern cloud systems with good APIs make this routine. A twenty-year-old ERP with no API can exceed the entire build cost.
- Run — model usage, hosting, monitoring, and the tuning that keeps the thing accurate as your business changes. Recurring, and routinely forgotten.
The line nobody budgets for
Systems drift. Your product range changes, a supplier changes their invoice layout, a policy is updated, a new channel opens. Without someone tuning thresholds and rules, accuracy degrades quietly over months and confidence in the system goes with it. Budget for this from the start — it is a fraction of the build, and it is the difference between a system that earns for three years and one that is quietly switched off after eight months.
How to build a business case that survives scrutiny
Measure the current process honestly: cases per month, minutes per case, fully-loaded hourly cost. Multiply. That gives you the value at stake. Then discount it — do not assume you will automate all of it, because you will not. A first pass that handles half the volume is a good outcome.
If the business case only works at ninety per cent automation, it does not work.
Questions worth asking a vendor
- What is your estimate for integration specifically, and what did you assume about our systems to produce it?
- What are the ongoing run costs at our projected volume?
- What happens to accuracy in month six, and who maintains it?
- What share of volume do you expect to handle unattended, and what is that based on?
- Discovery — map, measure, define the boundarySmall, fixed
- Build — the system itselfPredictable
- Integration — connecting what you already runHighest variance
- Run — usage, hosting, monitoring, tuningRecurring, often omitted
| Your systems | Effect on the estimate | |
|---|---|---|
| Modern cloud, documented APIs | Routine | Low |
| Mixed estate, one awkward system | Adds a phase | Medium |
| Legacy with no usable API | Can exceed the build | High |
The test that matters. If the business case only works at ninety per cent automation, it does not work. A first pass that handles half the volume is a good outcome.
Integration is the largest source of variance between quotes, and run cost is the line most often left out of a business case — which is why projects look cheaper than they are.
Last updated 2026-08-12 · Koderead
Apply this to your own business
Eleven questions, scored in your browser, with the arithmetic shown.
Find my AI opportunities