Model calls. Priced per unit of text in and out. Predictable, easy to estimate before you build, and in document or ticket processing it is typically cents per item — small enough that it rarely decides anything.
Infrastructure. Servers, storage, a queue, a database, monitoring. Modest and flat for most single-process systems, and it does not grow much with volume until the volume is large.
Maintenance. An API changes, a model version is retired, a document format shifts, a new edge case appears. This is a real recurring line and it is the one nobody budgets, because there is no invoice for it until something breaks.
Exception handling. Human minutes on the cases the system flags. Usually the largest running cost by a distance, and it is paid in salary rather than in a bill, so it stays invisible.
Start from volume per month, not from a monthly budget. For each item, count what happens: one or two model calls typically, a few API calls to your systems, storage of the document and its record. Multiply by volume and you have the technical line, which for most mid-sized processes lands somewhere unremarkable.
Then do the part that matters: take your straight-through rate and apply the remainder. If a fifth of items are flagged and each takes four minutes to review, a thousand items a month is roughly thirteen hours of somebody's time. Price those hours at the loaded rate and compare against the technical line. That comparison is usually the whole answer, and it explains why improving the straight-through rate is worth more than optimising model spend.
This is the same arithmetic the ROI calculator runs, with your volumes rather than ours.
Per-operation platform pricing. No-code platforms charge per step executed, so a flow with many nodes multiplies. Cheap at low volume, and it can quietly overtake the cost of a build as volume rises.
Sending too much context. Passing an entire document when three fields are needed, or a whole knowledge base when a search would find the right two paragraphs. This is the one genuine way to overspend on model calls, and it is a design fault rather than a pricing problem.
Retries nobody watches. A failing integration that retries every minute produces both a bill and no result. Alerting on failure rate is cheaper than discovering it monthly.
An exception queue that grows. If flagged items accumulate faster than anyone clears them, the running cost is not the queue — it is the delay downstream, and eventually somebody switching the system off.
Support after go-live is a monthly retainer you can cancel, and what it buys is attention: monitoring, keeping up with API and model changes, fixing what breaks, and a defined amount of change work. Systems left entirely unattended do not stay working for long, because the things around them keep moving.
It does not have to be us. Everything we build is yours — code, prompts, configuration, infrastructure — and some clients take it in-house after a few months, once the system has settled and the exception patterns are known. That is a legitimate outcome and we plan for it rather than against it.
The number to hold the running cost against is not zero. It is what the process costs today: the hours, the delay, the error rate and the rework those errors cause, plus whatever the business loses because a decision waited. Most processes have never been priced this way, which is why running costs look large in isolation and small the moment there is a baseline beside them.
Measure the baseline before you build. It takes a day, it is the only fair comparison, and after go-live it is the only way to prove anything changed. Without it, every discussion about whether the system is worth its running cost becomes an argument about impressions.
We measure the baseline during the audit and put it in the proposal, so the running cost is quoted next to the thing it replaces.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy