The price of an automation can't be set correctly just from the number of steps drawn in a workflow. What matters is which data flows, which systems allow access, what can go wrong and who is responsible when an operation is incomplete. A three-step flow can be harder than a twenty-step one if it changes financial data or depends on a system without an API.
What a request for quote should contain
Describe the start and end of the process, the usual volume and the activity peaks. Attach anonymised examples of inputs and outputs, the names and versions of the systems used, people's roles and the known exceptions. Say whether the process differs between companies, locations or client categories. A serious estimate also shows the assumptions that still need to be verified.
The four cost categories
- Analysis and design: rules, data, system integration and acceptance criteria.
- Implementation and testing: connections, data transformation, approvals, error handling and verification on real cases.
- Operation: hosting, licences, AI services, messaging and API limits. These costs can vary with volume.
- Maintenance: changes in connected systems, monitoring, updates and the time of the people who review exceptions.
Ask for the one-off cost to be separated from the recurring cost. Ask what volume the estimate covers, how overages are calculated and who absorbs changes to a third-party service. The implementation price is not the total cost of the solution.
Illustrative example: from email to quote
A company receives requests by email, extracts the data by hand and prepares a quote. A starter version could collect the information and create a draft for review. An extended version could consult the CRM, apply contract prices, check stock, request approvals and follow the client's reply.
The difference isn't just the number of connections. You need to clarify what happens with an unknown product, a different currency, a client with several contracts or a change after approval. The example shows how we scope the project; it does not describe a result measured at a client.
How to calculate the time recovered
Start from the number of cases and the observed manual duration. From the potentially avoided time, subtract checks, corrections, operation and handling of the remaining exceptions. Measure simple and difficult cases separately. An average result that hides many errors can lead to a wrong decision.
Freed hours don't automatically become money saved. They can allow the team to take on more requests or shorten delays. A financial saving must be tied to a cost that is actually avoided. Compare the observed benefit with all the costs and decide on expansion after the pilot.
How to compare two offers
Check whether they cover the same inputs, exceptions, responsibilities and deliverables. Ask for a demonstration of retrying a failed operation, of the log and of the required approvals. Clarify who owns the configurations, where data is stored and how you can keep operating if you change supplier.
If you don't have this information yet, the first useful deliverable is scoping the process and checking the integrations. See the automation and integrations service or how we work.