Cost · Estimate · Payback
The honest answer: the price is set not by the technology but by the state of your data and the number of systems that have to be connected. Below is what the budget is made of, what drives it up and how to calculate payback before the project begins.
This page is for those who work out the economics of a decision: executives, finance directors and technical directors who need to defend a budget with figures rather than promises.
The same phrase, “implement AI in request processing”, can mean two weeks of work on ready data or a six-month project untangling five systems. In that situation a price list comes in one of two kinds: deliberately inflated to cover the worst case, or understated to get your contact details — with the real figure turning up later. We do it differently: we show the whole cost structure so that you can assess your own case, and we name a range after short diagnostics.
The biggest cost multiplier. If the data is collected, labelled and kept in one place, work starts straight away. If it is scattered across systems, duplicated and contradictory, preparing the data will take longer than the model itself.
One connection point and one system is one scenario. Five systems with different formats, access rights and failure modes is quite another. It is the integrations, not the model, that most often set the timeline and the budget.
Working with external models is cheaper to build, but it requires data to leave your perimeter. Local deployment settles that question, but it adds infrastructure, hardware requirements and the work of choosing a model to fit the task.
The more a wrong decision costs, the more verification it needs around it: test sets, metrics, human confirmation, an audit of actions. That is exactly why an internal assistant and a system that affects a client’s money cost different amounts.
A hundred documents a day and a hundred thousand are different architectures. At large volumes come queues, caching, the economics of model calls and response-time requirements.
AI systems carry an ongoing cost: model calls or the upkeep of your own servers, quality monitoring, responding to changes in model behaviour. This goes into the calculation from the start rather than surfacing six months later.
We examine the process and the data, select scenarios with a calculated effect and give a conclusion: what AI genuinely solves, what ordinary automation solves more cheaply, and what cannot be solved at all for now. The output is a cost range for the pilot and a payback estimate. Fixed scope of work.
A working solution on a limited part of the process, with a metric fixed before the start. The point of a pilot is not to “show a demo” but to test a hypothesis on real data and get a number you can base the decision to continue on. Priced by the size of the scenario and the number of integrations.
Integration into your working environment, load, access rights, observability, support and further development. This is where the ongoing component appears: maintenance and the cost of model calls. The engagement is either project-based or a team for a fixed term, depending on whether you plan to take the system in-house.
This is the calculation we make during diagnostics, and one you can make yourself before talking to any contractor. You need four figures from your process:
The monthly saving is the volume multiplied by the cost per operation and by the share handed over, minus the running cost. The payback period is the project budget divided by that saving. If it comes out at more than a year, the project usually should not be started in that form: it is better to narrow the scenario to the part with the largest volume and calculate again.
We work through this calculation with you during diagnostics and show it in full — including the assumptions under which it stops holding.
A detailed walk-through of the method — with the typical mistakes that inflate the result several times over — is in the article “How to calculate the ROI of AI implementation”.
Because the same wording of a task means different amounts of work. “Automate request processing” can be a two-week scenario on ready data or a six-month project untangling five systems. We name a range after a short conversation and confirm it after diagnostics — before you spend the budget.
A pilot is priced from the scenario: how many process steps it covers, how many systems it touches and what level of quality checking it needs. We always try to narrow a pilot down to a single testable claim — that makes it cheaper and more useful than “trying everything at once”.
Yes, for diagnostics and for a pilot with a clearly bounded scope — that is normal practice. A budget for production rollout cannot honestly be fixed before diagnostics: any such figure would be either an inflated safety margin or a promise that would have to be broken.
For most business tasks a ready-made model with your data and rules is cheaper: training your own model is justified when the task is narrow, there is a lot of data and the work has to run inside a closed perimeter. We cost both options at the diagnostics stage and show the difference in total cost of ownership, not just in development.
It has two parts: infrastructure and model calls (priced by volume), and engineers’ work on quality control. Model behaviour changes, so a system nobody watches degrades without anyone noticing — we build that monitoring into the calculation from the start.
Then we will say so and explain how to solve the task more cheaply. It is a regular outcome, and it saves the client considerably more than the diagnostics cost.
Describe the process in two paragraphs — what happens now and what gets in the way. We will reply with an order-of-magnitude cost estimate and tell you if the task can be solved more cheaply without AI.