Tools that talk to each other,
no more re-typing.

We follow what really happens in your business over a typical week. We cost in hours what each repetitive task costs you per month. We build the flows that pay back most, starting with a single one. We put an alert on each. Then we train the person who will take it over.

What you get: A list of tasks costed in monthly hours, a first flow in production in two to three weeks, and scenarios documented in plain language that somebody other than us can take over.

What you do not have to do: Change tools, train the whole team, or describe a theoretical process. We start from what you actually do, with the tools you already have.

Quotes copied into the CRM, follow-ups done from memory, files circulating by email: those are hours, every week, and data that degrades.

We start by mapping what actually happens, not what the theoretical process assumes. Then we automate what produces a gain, leaving aside what is not worth it. Every automation put into production has an alert on failure and a named owner: without that, a broken flow stays invisible until a customer complains.

The choice of tool comes last, and it is calculated. We have set that decision out in our comparisons.

The gain does not come from the technology but from the choice of what to automate. A spectacular flow triggered three times a month gives back nothing; a boring re-typing repeated forty times a day gives back whole days. So we start by counting, not by connecting.

The choice of tool comes last, and it is calculated. We have set it out in our comparisons, in particular n8n or Make and Make or Zapier, with the billing mechanics that decide at volume.

The first mistake is to automate the process as it is described, and not as it is practised. The two almost always differ, and the gap is exactly where the gains hide.

Counting before choosing

We start by recording, over two weeks, what really happens: who enters what, in which tool, how many times, and what gets lost along the way. There is nothing sophisticated about that record, but it moves the discussion from impressions to figures.

It always produces two surprises. Tasks nobody mentions take up a great deal of time, because habit has made them invisible. And tasks everybody complains about weigh little in practice, because they are painful but rare.

The selection criterion: frequency multiplied by pain

We then rank every task on two axes, its frequency and the cost of getting it wrong. What comes out on top is almost never what was imagined at the start.

• Frequent and low risk: automate first, the gain is immediate and a breakdown is harmless.
• Frequent and sensitive: automate next, with an alert and a recovery procedure.
• Rare and sensitive: often left manual, because a human doing it ten times a year does it better than a flow nobody watches any more.
• Rare and low risk: ignore, however irritating it is.

What we decide not to automate

It is the part of the work we are asked for least and that pays back most. An automation has a design cost, a monitoring cost and a recovery cost when it breaks. Below a certain volume, it costs more than the task it replaces.

So we always hand over a list of what we recommend leaving as it is, with the reason. An automation project that automates everything is a badly framed project, and it turns against the team at the first incident.

An automation does not break down on the day it goes live, it breaks six months later, for reasons that have nothing to do with its original design.

The connected tools change without warning

A field renamed in your CRM, an interface updated by a supplier, an authentication that expires: the flow stops, and nothing signals it if nobody planned the alert.

That is why every automation we put into production carries an alert a human can see, and not merely a line in a log nobody opens. A silent automation that falls over on a Friday evening produces incomplete data all weekend, and the incident is discovered by the customer.

The edge cases nobody had foreseen

The flow works perfectly on normal cases, then meets a zero-euro quote, a customer with no email address, a name with an apostrophe, an order cancelled then reinstated.

These cases are not imagined at design time, they are discovered. So from the start we plan what happens when a piece of data does not fit the mould: the flow stops cleanly, the data is set aside, somebody is told. What must never be done is to let incomplete data pass downstream.

Dependency on whoever built it

An automation is software written by somebody. If that person leaves, what remains is a chain of steps without comment, whose intention has to be guessed.

So every scenario we deliver carries an explicit name, a description of what it does and of what happens if it fails, the list of systems it touches and the name of an owner. Ten minutes during the build, and the difference between an automation that survives a departure and one that dies with it.

The monitoring cost, the one nobody budgets for

The platforms bill by volume processed, in tiers. We do not publish amounts: they change too often to stay accurate. The mechanics, on the other hand, are stable and enough to decide on, and we set them out in our tool comparisons.

The line that decides real profitability is not that subscription, it is the human time spent monitoring. An automation that saves two hours a month and demands one of maintenance is not a gain, it is a transfer of workload. We cost it beforehand, not afterwards.

What we refuse to do

We do not automate a process nobody has written down. As long as two people on the team describe the same task differently, automating amounts to setting a disagreement in software, and the flow will be worked around at the first exception.

Nor do we connect an automation to a shared file everyone edits their own way. The data must have a single source and a stable format, otherwise the flow carries errors faster than a human was making them. Putting that source in order is sometimes the whole project, and it is often the part that pays back most.

Finally, we do not deliver an automation without its failure test. Before go-live, we deliberately break the flow to check that the alert goes out, that it reaches the right person and that the data in question is properly set aside. An alert you have never seen fire is not an alert, it is an intention.

A successful automation project is not judged on the number of scenarios in production, but on what the team does with the time given back and on its ability to carry on without us.

Time given back does not recover itself

Removing two hours of re-typing a week does not magically create two useful hours. Without an explicit intention, that time dissolves immediately into interruptions and nobody sees a gain, which weakens the next project.

So before starting we ask what that time will be spent on. Chasing pending quotes, preparing meetings, following up unpaid invoices: the answer does not need to be ambitious, it needs to be named. That is what allows you, three months later, to say whether the project paid.

One owner, not a committee

Automations break down, that is normal and predictable. What separates an organisation where they last from one where they die out is the existence of a named person who receives the alert and knows who to call.

That role requires no technical skill. It requires being named. When responsibility is shared between three people, the alert is seen by all three and handled by none, and the flows decay within months without anything signalling it.

The documentation that actually serves

Useful automation documentation fits in a few lines per scenario, and certainly not in a manual nobody will open.

• What the scenario does, in one sentence an outsider can understand.
• What triggers it, and how often it actually runs.
• The systems it touches, for writing as well as reading.
• What happens if it fails, and who is told.

That is the minimum that lets somebody else take the subject over. Without it, an automation becomes a black box the team works around rather than fixes, and the benefit disappears without the cost line disappearing.

When automation is no longer enough

Connecting tools to each other has a limit, and it is honest to name it. When a process needs an interface to be steered, a consultable history or fine-grained permissions, you are no longer doing automation, you are building a business tool.

The symptom is easy to recognise: the scenario grows, nobody rereads it, and the team asks for a tracking board to understand what happened. At that stage, extending the automation costs more than building a light application, and it becomes an application development project.

Conversely, many requests for a business tool are settled by three well-placed automations and a good CRM integration. That is the decision we hand over during framing, and it often makes the biggest budget difference in the project.

This page describes the complete approach: map the real flows, cost the gain before building, then automate what deserves it. Two situations need separate treatment, and they have their own page.

Self-hosted automation with n8n

When your data cannot pass through a service you do not control, or when the volume makes usage-based billing unreasonable. That page covers the choice between self-hosting and a platform, securing the instance and monitoring it over time, which are subjects absent from a conventional automation project.

And if the subject is the steering rather than the flows

When the question is what should be automated, in what order and for what gain, before anything is built, it is a matter of diagnosis. That is the subject of our automation audit and, at the scale of the organisation, of the process automation consulting page.

We do not sell a number of scenarios, because that figure means nothing before anyone has looked. So the start is always the same, whatever the budget.

A survey before any proposal

We spend time with the people who do the work, not only with those who describe it. The gap between the theoretical process and actual practice is exactly where the gains are, and it is invisible from an organisation chart.

That survey produces a map of what really happens, with orders of magnitude: how many times a week, how many minutes, how many errors observed. It is short, and it is what makes what follows arguable on figures rather than on impressions.

A proposal ranked by return

You then receive an ordered list, from the most profitable to the least, with the estimated gain and the cost of implementation for each line. The list always includes a section on what we recommend not automating, with the reason.

You choose where you stop. It is your decision, not ours, and it is taken in full knowledge.

Going live in small steps

The first flow goes out alone, it is watched for a month, then the others are added. That apparent slowness is deliberate: it lets us check real adoption before piling more on, and it avoids the situation where ten automations are delivered at once and nobody knows which one broke.

If your need goes beyond what flows can carry, we will say so at that point rather than at the end of the project, and the decision shifts towards a light business tool.