Count the step you remove
An automation pays for itself only where it removes work, or where it removes a class of error you can describe. Time that moves from one person to another is not a saving. A dashboard that reports the old process is not a saving either.
Write the current path as a list of steps. Mark the steps the new system will perform, the steps a person will still perform, and the steps that disappear. Only the last group, plus the portion of review time you truly drop, belongs in the estimate.
Separate the build from the running cost
The build is a one-time project: discovery, design, development, integration, and the first tests. The running cost continues: hosting, a model or API bill if the workflow calls one, and the support you agree.
A workflow that calls a model on every document has a usage cost tied to volume. Put that number next to the hours saved. If volume doubles, both the value and the bill move. The estimate should say so.
A labeled hypothetical
The figures below are an illustration of the arithmetic. They are not a client result, not an Orvia House measurement, and not a promise that your project will look like this.
| Assumption | Figure used in the example |
|---|---|
| Orders retyped by hand | 40 a day |
| Minutes of retyping each | 6 |
| Hours a day at that rate | 4 |
| Loaded cost used for the example | 40 USD an hour |
| Gross daily cost of the retyping | 160 USD |
| Share still checked by a person | 20 percent |
| Hours removed, if the assumption holds | 3.2 a day |
What the example does not prove
The 20 percent review rate is an assumption you would have to measure. If the exceptions are half the orders, the value drops with them. If the automation posts a wrong order that a person used to catch, the cost of that error belongs in the estimate too.
Do not add a second benefit for “faster responses” unless you know what the faster response is worth. Do not annualize a busy week and call it a year.
Score a pilot against a baseline
Before the build, record two ordinary weeks: volume, minutes per item, error rate, and who does the work. After a bounded pilot, record the same four numbers with the same definitions. “Done” has to mean the same thing in both columns.
Keep the exception queue visible. A pilot that looks fast because hard cases were left out of the sample is not a result you can scale.
Related service: Agentic AI and automation