What an order-intake automation actually costs to run per month

Pricing pages tell you what an automation costs to build. Almost nobody publishes what one costs to run, which is the number that decides whether it survives its second year. So here is the actual monthly bill for one of ours: an order-intake automation at a wholesale distributor, processing about 1,400 orders a month that arrive as emailed PDFs, photographed paper forms and the occasional spreadsheet. Names withheld; numbers real, from the March 2026 invoice.

The itemised bill

The team this replaced spent about three hours every morning keying orders — call it 66 hours a month, roughly $1,850 at the same loaded rate, before counting the keying errors that used to ship wrong pallets. The automation pays for itself even in a slow month, but look at the shape of the bill: the two biggest lines are humans. Model calls are 15% of the total. Anyone who prices an automation for you using only API rates has quoted you a sixth of the truth.

One thing deliberately absent from the table: build-cost amortisation. The build was a fixed-scope project, paid once, and we think mixing it into the monthly view hides the decision that actually matters — whether the system is worth keeping now, at today’s volume, against today’s alternative. Sunk cost gets no line item.

Where the cost creeps: the 80/20

Run costs do not stay flat on their own, and in our experience 80% of the creep comes from one place: the review queue. Every new customer with a new form layout initially routes to human review, which is correct behaviour. The trap is that nobody promotes learned formats back out of the queue. At this client, the review share drifted from 7% to 12% over a quarter — a 70% increase in the largest cost line — before anyone noticed, because each individual review felt normal. The fix was procedural, not technical: a 30-minute monthly triage where someone asks “which formats did we review more than five times, and why are they still in the queue?”

The remaining 20% of creep is retries. A model call that fails to parse gets retried; retries hide upstream problems and double-bill you for them. Our parse-failure counter exists mostly to make this visible — when retries exceed 2% of calls, something changed and the bill will say so in three weeks if the alert does not say so today.

When it stops being worth it

We have turned down order-intake automations, and the maths above shows why. Three honest thresholds:

1. Below roughly 15–20 orders a day, the fixed floor — hosting, monitoring, the review habit — dominates, and a person with a good template is cheaper. Come back when volume doubles.
2. If most senders could use a portal, build the portal. Structured input at the source beats extraction every time; extraction is what you buy when you cannot change your customers’ behaviour. One prospect discovered that their top eight customers, 70% of volume, were happy to submit structured orders — that project became a web form, not an AI system.
3. If formats churn weekly — spot-market brokers, one-off buyers — extraction accuracy never stabilises and the review share never falls. The automation becomes an expensive inbox.

What we'd tell you to do

• Demand a per-order (or per-task) cost from any vendor, with human review time on the bill. If it is missing, the bill is fiction.
• Put the review-queue triage on a named person’s calendar. The queue is where your margin quietly leaves.
• Alert on retry rate, not just uptime. Uptime was 100% during the months the cost crept 70%.
• Re-run the build-versus-drop decision yearly with the real bill. An automation that made sense at 1,400 orders a month may not at 400 — and that is fine; switching one off is a result, not a failure.