In the first part of this article, we gave orders of magnitude, described how our audit works, and showed how we map a process and measure what it really costs every year. We also explained why complex cases deliberately stay under human validation. This second part starts from that measurement and answers the questions that logically follow: why two similar projects do not carry the same price, how we build ours, and what protects you if the result does not live up to the criteria.
Assessing Technical Complexity
Two automations that create the same value can require very different amounts of work to build. One simple workflow chains together an email, a data extraction, the generation of a document, and its dispatch. Another one runs through a line-of-business application, an external API, business rules, an AI model, a human validation, an electronic signature, and archiving. In the second case, the complexity rarely comes from the artificial intelligence itself. It comes from the integrations. You have to handle authentication, access rights, incomplete data, outages in external services, security, and recovery mechanisms.
A prototype that works in a demo often represents less than 20% of the work. The remaining 80% (error handling, incomplete data, third-party outages, security, recovery after an incident) is invisible in a demo, but it is what separates a system that impresses for ten minutes from a system you trust with your clients every day. That difference is why the same requirement can cost two or three times more depending on how demanding the standard is. Figure 1 shows where the waterline sits.
Building the Price
We do not calculate the price of a project by simply multiplying a number of days by a daily rate. That method contains a paradox: the more efficient a provider becomes, the less it should charge. Yet an automation that takes a few days to develop can create tens of thousands of euros of value a year, while a highly technical integration can require a great deal of work for modest economic value.
So we assess each project along three dimensions. Build complexity covers development, integrations, testing, and deployment. Operational risk measures how important the process is to your business and what the consequences of an error would be. Economic value adds up the time freed, the capacity created, the errors avoided, and the potential additional revenue.
In practice, we apply a simple sizing rule: the price of the project is built so that the investment pays for itself during the first or the second year of operation, based on the figures established together during the audit. If we cannot build that case, we do not recommend the project. This rule appears in the audit deliverable, so you can check it, and you can hold us to it.
Like the measurement of the annual cost presented in the first part, this rule serves an interest of ours, and we may as well say so plainly: the more your process costs, the higher the price we can defend, for the same development effort. That is what it means to index a price on the value created rather than on our days of work. The flip side protects you, because the same rule caps the price at one or two years of savings, however complex our work turns out to be.
A Concrete Example
Let us go back to the process measured in the first part: 80 runs a week, an average of 12 minutes of human work, or roughly €25,760 of human capacity tied up every year. This example is fictional and simplified. It is there to show the reasoning, not to promise a result, and depending on the complexity and the value at stake, a real project can cost considerably less or considerably more. On real projects, the achievable reduction varies a great deal from one case to the next, and we do sometimes conclude that it is too small to justify the investment. When that happens, we tell the client before they invest.
Suppose the analysis shows a possible 75% reduction in the time spent on the process. The human capacity freed then represents roughly €19,300 a year. Suppose the project requires €7,500 to set up, with the audit fee you have already paid deducted from that amount, then €250 per month for infrastructure, monitoring, and maintenance. The total cost of the first year therefore comes to €10,500. On top of that €10,500, you should add the time your teams spend on the project (scoping, testing, training), typically the equivalent of €1,000 to €1,500, and the full reduction is only reached after a running-in period of a few weeks. Even with those elements included, the break-even point still falls inside the first year. Figure 2 plots the two cumulative curves over 24 months.
These assumptions call for two clarifications. We use 75%, not the 95% from the first part: those 95% count files handled automatically, not time, because the files that still go through human validation are the slowest to handle, and the automated process keeps a share of supervision. As for the €7,500, it sits at the top of the €3,000 to €8,000 range given in the first part: the process remains a linear chain around a single line-of-business application, with no AI model to integrate, which keeps it below the threshold of multi-system automations.
On paper, that break-even point sits around six months, or six to seven months once the internal costs and the running-in period are included. But this calculation rests on one condition that we check with you before we validate the project: that the hours freed are genuinely reassigned to useful activities. Capacity that is freed and then goes unused is worth nothing, and we prefer to say so before the quote rather than after. From the second year onward, the cost is limited to running the system, roughly €3,000 a year, for a freed capacity that remains in the region of €19,300.
Conversely, if the analysis shows that a process only represents a few thousand euros a year and would require a complex €15,000 integration, we conclude that the automation is not justified, and reaching that conclusion is part of our job. Some tasks are too rare, some procedures too variable, and some integrations too expensive relative to the expected benefit. Our aim is not to find an automation at any price, but to determine whether it is a rational investment.
The Setup Price and the Running Cost Are Two Different Things
We separate two categories of cost, and we price them separately. Setup covers the audit, the design of the workflow, development, integrations, testing, deployment, documentation, and training your teams. That part is an upfront investment. Running the system then covers infrastructure, calls to APIs and AI models, storage, monitoring, maintenance, and support.
These recurring costs are identified from the outset. We would much rather a client knew exactly what their system costs to run than discover a string of technical expenses that are hard to follow, month after month.
How Do We Know a Project Is Finished?
Saying that an automation has to “work properly” is not enough. So we define observable acceptance criteria, for example:
When a complete request is received, the system identifies the client, retrieves the necessary information, generates the document, and saves it automatically in the corresponding file.
When a mandatory piece of information is missing, the file is not processed automatically and is placed in a human validation queue.
These criteria let the client and our team know exactly what the system has to do, and they make testing and sign-off far simpler.
What If It Does Not Work?
These acceptance criteria are not decorative, because they condition payment. Part of the payment, defined in the quote, only falls due after joint sign-off on the acceptance criteria in real conditions. That sign-off follows a schedule set out in the quote, and it depends on your cooperation: access to real data, availability of the people concerned, and the agreed volumes. If you raise no reasoned objection within the agreed period, generally fifteen business days after go-live in real conditions, acceptance is deemed granted. That is the fair trade-off for our commitment.
A warranty period, generally four weeks and stated in each quote, covers the correction of any gaps against these criteria at no extra charge. The before and after measurements are established together, so that both parties can verify them: the assumptions are validated during the audit, and the results are observed jointly.
If the acceptance criteria required automatic processing of 95% of files and, under the conditions set out in the quote and during the warranty period, the system only processes 60% of them, that is our problem to solve, not yours to fund.
Who Owns the System, and Can You Leave?
The bespoke work, meaning the code and the workflows built for you, belongs to you as soon as it is paid for. Two things stay outside that transfer: the third-party tools keep the licences of their own vendors, and the reusable components we owned before your project or built independently of it stay ours, licensed to you for as long as you run the system. Both are named to you before anything is built. Maintenance is not compulsory. It can be cancelled with one month’s notice, and the system runs without us. We provide documentation that allows another provider to take the system over.
On the data side, hosting is in Europe, a data processing agreement (DPA) is signed with every subprocessor, including the AI model providers, and the GDPR compliance of your specific case is examined during the audit. The list of subprocessors is given to you before any deployment.
These guarantees count double in healthcare, a sector we work with regularly. Preparing patient files, writing discharge letters, and running the front desk all involve sensitive data, and the value reasoning presented across these two articles applies there in exactly the same way, with stricter compliance requirements. Our patient check-in kiosk shows how we handle those requirements in practice.
How Long Does It Take, and How Much of Your Teams’ Time?
These durations are indicative, but they give you something to plan against. The audit runs over one to three weeks. A simple workflow is typically in production four to eight weeks after the quote is approved, while a multi-system automation takes more like three to six months. An end-to-end program is planned during the audit, phase by phase. On your side, you should expect a few hours during the audit, then the equivalent of two to five days spread across the project for scoping, testing, and training. This internal cost is estimated in the audit deliverable.
Our Approach in Short
A transtorm.ai project always follows the same logic:
- understand the process;
- measure its cost and its constraints;
- identify the steps that can be automated;
- assess the complexity and the risks;
- estimate the value created;
- define the solution and its price;
- set measurable acceptance criteria;
- deploy and measure the results.
The first three steps correspond to the first part of this article, and the following ones to this part. This method answers a more useful question than price alone: is this automation a good investment for your organization? The first step in that chain is exactly what our audit delivers.
The next step commits you to nothing. A free 30-minute conversation is usually enough to determine whether your process is a good candidate for automation, or whether it is not. Either way, you leave with an answer. Write to us at the bottom of this page, or book a slot directly in our calendar.