Our Method

Most automation projects do not fail because the technology is too weak. They fail because nobody looked closely enough at the process before automating it. A real business workflow contains exceptions, manual rework, unwritten rules, human judgement calls, ambiguous data and tools that do not talk to each other cleanly. Automate that without understanding it and you lock the existing inefficiency into code.

At transtorm.ai we therefore run every project in the same order. We audit the process as it really runs, we measure what it costs today, we decide where a human keeps the decision, we anonymise anything that has to leave, we split the work into micro-processes, we connect the systems you already own, and we then improve the system from real usage. This page describes each stage, what you receive at the end of it, and what belongs to you.

Two principles run through the whole sequence. For decisions that matter, automation does not replace human control, it structures and speeds it up. And local processing comes first, so that when an external resource is genuinely needed, only fully anonymised data is sent to it.

Stage 1. We audit the process as it really runs

Documenting the theoretical procedure is not enough. We observe the repetitive tasks, the bottlenecks, the wasted time, the human validations, the recurring exceptions, the systems involved and the way the data actually moves between them. That observation separates the steps that are easy to automate from the ones that must stay supervised and the ones that need to be reorganised before anything is automated at all.

This stage often creates value on its own. It regularly reveals duplicated work, unnecessary steps or organisational problems that can be fixed without writing a single line of code.

What you receive: a written audit deliverable containing the process map, the current annual cost of the process along with the assumptions behind that calculation, the recommended architecture, an estimate of the project price and of the running costs, and a clear recommendation. That recommendation includes the option of not automating.

What you own: the deliverable, whatever you decide afterwards. It is precise enough to be handed to another provider. The audit is billed as a fixed fee, usually between 900 and 2,500 euros, announced before any commitment and deducted from the project price if the project goes ahead.

Stage 2. We measure before we quote a price

An estimate built on numbers nobody checked is a guess with a decimal point. So the volume and time assumptions are validated first against historical data: system logs, timestamps, observed volumes. Where that data does not exist, we observe the process directly or sample real cases.

One point deserves to be said plainly. Those figures then size the price of the project, and we would objectively benefit from them looking high. That is exactly why the measurements prevail over the declarations, in both directions, and why every assumption is written down in the deliverable so you can challenge it line by line before any quote is issued.

What you receive: the before measurement, with its method and its sources, agreed by both sides. The after measurement is established the same way once the system runs, so that the gain is observed jointly rather than claimed.

Stage 3. We decide where a human keeps the decision

A serious automation has to know when to check, when to block, when to ask for a validation and when to raise an alert. This is the stage where we write down the business rules, the decision thresholds, the consistency checks, the exception cases, the authorised actions, the actions that require a confirmation and the actions that are simply forbidden.

Human validation then takes a form matched to the risk. It can be a confirmation before a sensitive action, an approval before something is sent or run, an automatic block when a case is ambiguous, an alert when a critical threshold is crossed, or simply a log entry for an important decision. A system that handles 95 files out of 100 and hands the five anomalous ones to a member of staff is usually more reliable, simpler and cheaper than a system built to handle every conceivable case alone.

What you receive: the list of control points and the acceptance criteria, written in business language. Those criteria are not decorative, because they condition part of the payment and they define what joint sign-off will test.

Stage 4. We anonymise before anything leaves

We favour local data processing wherever it is possible. When an external resource is genuinely required, the data sent to it has been fully anonymised beforehand, and no sensitive data is sent to those services.

This is not a clause added at the end of the project. It shapes how the integrations are designed in the first place, because the anonymisation has to happen inside the flow, before the call, and it has to be verifiable afterwards.

What you receive: the map of what leaves your systems, to which service, in which form. The list of subprocessors, including AI model providers, is given to you before any deployment. Our security page describes this part in detail.

Stage 5. We split the work into micro-processes

Building one large monolithic workflow is rarely a good idea. We split the process into short steps with a single clear responsibility each: read a piece of data, check a condition, transform a piece of information, call a service, generate a document, ask for a validation, trigger a notification.

That breakdown pays off in five ways. A short step is easier to test and to fix than an opaque block. When a rule changes, one building block changes without touching the rest of the flow. Some blocks get reused in other workflows, which makes the next automation faster to build. When something fails, you see immediately which step failed and which action to restart. And the system can be extended step by step instead of being rebuilt.

What you receive: an architecture made of named, individually testable steps, and the documentation that goes with it.

Stage 6. We connect the systems you already run

An automation only creates value if it fits into your real environment. We connect emails, calendars such as Google Workspace, databases, REST or SOAP APIs, business tools, web portals and older software through gateways, plus controlled web automation when a system offers no interface at all. Our banking control use case shows an automation driving an existing web application exactly as an operator would, with the authentication step still performed by an authorised person.

A useful connector is more than a technical link. It handles the real data formats, the response times, the network errors, the duplicates, the reruns and the structural differences between systems. That is where most of the engineering effort actually goes, and it is also where most of the cost of a project comes from.

What you receive: connectors that survive the edge cases, and a written description of every system the automation touches and of the credentials it uses.

Stage 7. We deploy in stages, then keep improving

An automated system has to stay observable. You must be able to answer simple questions at any moment: what happened, which decision was taken, why did the flow stop, which step failed, can it be restarted without creating a duplicate, and who should be alerted.

So we add structured logs, timestamps on each step, traceability of actions, operational alerts, controlled recovery after an error, duplicate prevention, queues with priority management, and dashboards carrying business metrics rather than technical noise. Then we work in cycles: a clear scope, a staged deployment, observation of the results, measurement of the gains and the incidents, adjustment of the rules, refinement of the validations, extension of the scope.

Iteration here is not the sign of a badly designed system. It is the sign of a system that is being run properly, because real usage always brings up special cases that no audit could have listed in advance.

What you receive: the dashboards, the logs and the alerting, plus a warranty period of generally four weeks that covers the correction of any gap against the acceptance criteria at no extra charge.

What you own at the end

The bespoke work, meaning the code and the workflows built for you, belongs to you as soon as it is paid for, and section 7 of our general terms says so whether or not the quote repeats it. 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 keeps running without us. We provide the documentation that allows another provider to take the system over. This is what we mean by reversibility, and it is worth comparing against any quote you receive elsewhere: a lower price without those clauses is not a saving, it is a transfer of risk onto you.

How the stages fit together in time

The audit takes one to three weeks and a few hours of your teams’ time. A simple workflow reaches production four to eight weeks after the quote is approved. A multi-system automation takes three to six months. An end-to-end programme is planned phase by phase during the audit. Across the whole project you should budget the equivalent of two to five days of internal time for scoping, testing and training, and that internal cost is estimated in the audit deliverable.

The full reasoning behind this sequence is set out in our article on our automation method, and the way it turns into a price is explained in part one and part two of our pricing articles.

Start with your own process

If you want to apply this method to one of your processes, the entry point is always the same: a conversation about how that process runs today.