What automation costs and how return is measured

The three components of cost

Proposals usually show one number. There are three.

Build. Designing the process, writing the integration, testing it and migrating existing data. This is one-off and it is the part everyone estimates.

Recurring platform cost. Licences, per-seat charges, usage or per-execution charges, and any tier upgrade required to obtain API access. That last item is a frequent surprise, because API access is often gated above the plan a business already pays for.

Ownership. Monitoring, repair when a connector breaks, and change when a business rule changes. This is real, ongoing, and the most commonly omitted line.

What actually drives the number up

Four things, in roughly descending order of impact.

The number of systems a process crosses, because each crossing needs an agreement about what the records mean. Whether those systems have usable APIs, since a workaround for a system without one is both more expensive to build and more fragile. The number of genuine exceptions in the process, each of which is a branch that must be specified and tested. And whether the process is documented, because reverse-engineering it is discovery work before any build starts.

Notably absent from that list: industry, headcount and revenue. They are poor predictors, which is why credible pricing follows a scoping conversation.

How to measure return honestly

Decide the measure before the build, and record the current value. Retrofitted baselines are not evidence.

Useful measures are usually operational and specific: time from enquiry to first response, proportion of enquiries that receive a follow-up at all, hours spent on a named task per week, rate of records requiring manual correction. Each is directly attributable and observable within a normal reporting cycle.

Less useful: aggregate revenue movement over the same period. Revenue changes for many reasons at once, and claiming it as automation return requires an isolation you almost certainly do not have.

Questions worth asking a vendor

What exactly is included in the build price, and what triggers a change order. What the recurring cost is at expected volume, not at minimum volume. Who owns maintenance and what the response time is when an integration breaks. What happens to the work if the engagement ends — whether the process runs in systems you control.

The last question is the one most often skipped and the most expensive to get wrong.

A reasonable way to start

Scope one well-documented process, agree the measure and the baseline, build it, and review the result against that measure. The purpose of a first project is partly the outcome and partly the information: it tells you what work of this kind actually costs in your business, which no published figure can.

Suora's approach to pricing is described on the pricing page, and a consultation is the scoping conversation that produces an actual number.