How to Build an Automation Pilot That Proves Value Before Scaling

Most companies that stall an automation project stall at the same point: right after the pilot. The demo went well, everyone agreed it was impressive, and three months later the workflow is still running for two people while the rest of the operation does everything by hand.

An automation pilot that is worth running is not a demo. It is a measurement.

In a July 2024 press release, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing unclear business value, escalating costs and poor data quality. None of those causes is technical. All of them are decided by how the pilot is designed.

A pilot does not exist to prove the technology works

That is already settled. Pulling fields out of a PDF, writing to an ERP, notifying someone in Slack: none of this is in question.

Something else is. Whether in this process, with this data and with this team, automation saves enough time to justify what it costs to maintain.

That is the question a pilot answers. And it can only answer it if it is built to produce a number rather than an impression.

The difference shows up at the end. A demo pilot ends with "that looked good, let's see." A measured pilot ends with "it saved 25 hours a month, cost four thousand euros, pays for itself in five months, we scale."

Picking the process: high volume, low risk, named owner

Three criteria, in that order.

High volume. A process that runs 15 times a month will not produce a large enough sample in 60 days to tell a real gain from luck. Look for something that happens dozens or hundreds of times during the pilot.

Low risk. In a first pilot, a mistake must not reach a customer or the tax authority. Internal, reversible processes with a person validating the output are the right ground. Automating credit notes is not a good first pilot.

A named owner. A specific person who does the work today, who will use the workflow, and whose name is attached to the outcome. Without that, nobody reports the errors and the pilot dies quietly.

The most visible process is rarely the best candidate. Mapping your processes before you start is what separates an informed choice from whoever spoke loudest in the meeting.

Measure the before, before you touch anything

This is the step almost everyone skips, and the only one you cannot recover.

Once the workflow is running, the previous state can no longer be measured. What remains are estimates from memory — "that used to take a morning or so" — which convince nobody who has to sign off a budget.

Two weeks of baseline is enough. What to record:

• How many times the process runs, per week.
• How long each run takes, timed rather than estimated.
• How often it fails or needs fixing afterwards.
• How many people touch it, and at which point.
• How long it takes from the request arriving to it being resolved.

The last one surprises boards the most. Actual working time on an approval request can be four minutes, spread across six days of waiting. Automation rarely speeds up the four minutes by much. What it removes is the six days.

The method for turning those hours into euros is worked through in the article on what manual processes actually cost.

The calculation that convinces whoever signs

The figures below are a worked example, not a client case. What matters here is the method, not the values.

Process: posting supplier invoices.

Baseline, measured over two weeks. 340 invoices a month, six minutes each. That is 34 hours a month.

The cost of those hours. Average hourly labour costs in the EU were 34.90 euros in 2025, according to Eurostat. Use the published figure rather than inventing one. 34 hours at 34.90 euros is 1,187 euros a month, or roughly 14,200 euros a year on this process alone.

After the pilot, measured over 60 days. Invoices that match the purchase order exactly go through untouched. The rest go into a review queue. Human time drops from 34 hours a month to 9.

Saving. 25 hours at 34.90 euros is 872 euros a month.

Cost of the pilot. Four thousand euros to build, plus 50 euros a month in infrastructure and maintenance.

Return. 4,000 divided by 822 euros of net monthly saving is 4.9 months to pay back the investment.

Notice what this has and what it does not. It has a number measured before, a number measured after, and a real cost. It has no "70% efficiency gain" and no "frees staff for higher-value work." Those two sentences are what get pilots filed away.

Instrument the pilot so it measures itself

If measurement depends on someone filling in a spreadsheet, it stops happening in week three.

On a platform like n8n, the record comes as standard. Every execution is stored with its status — success, failure, running or waiting — its start time and its duration, and the list can be filtered by any of those fields. A failed execution can be retried straight from that list, either with the original data or with the workflow already corrected.

It is worth going one step further and tagging each execution with business data. One line in a Code node, along the lines of $execution.customData.set("supplier", name), means the execution stores custom data and the list can then be filtered by it. At the end of the pilot, instead of "it went well," you have how many runs there were per supplier and exactly which ones failed.

Two limitations worth knowing up front. Custom executions data exists only on Cloud Pro and Enterprise, or on self-hosted Enterprise and registered Community plans, not on the entry tier. And deleting a workflow deletes its entire execution history with it. A pilot tidied away takes the evidence with it.

Exit criteria, agreed before you start

A pilot with no end date and no decision threshold turns into accidental production: the workflow just keeps running, never approved and never rejected.

Before day one, put three things in writing.

Duration. Six to eight weeks is usually enough on a high-volume process. Any shorter and the rare cases have not shown up yet.

Threshold. The number that decides. For example: at least 70% of invoices processed without human intervention, and fewer than 2% of errors reaching the ERP.

The decision attached to each outcome. Above the threshold, you scale, with budget already pre-approved. Below it, you either fix an identified cause or switch it off. All three answers are legitimate. What is not legitimate is reaching the end without having agreed which one applies.

When the pilot says no

A pilot that fails and gets switched off is not wasted money. It is the cheapest answer you will ever get to that question.

The reasons behind a "no" are almost always the same, and none of them is the tool.

The process has too many exceptions. If 40% of cases need human judgement, automation produces a review queue that costs nearly as much as the original work.

The input data is not stable. Suppliers who change their invoice layout every quarter turn maintenance into permanent work.

The process was about to change anyway. Automating something that will be replaced in six months is building on sand. This is the most expensive of the three and the easiest to avoid: you only had to ask.

What changes when you scale

A successful pilot proves a workflow. It does not prove a programme.

When the same pattern goes from one process to ten, problems appear that did not exist at a scale of one. Who maintains the workflows when whoever built them leaves. Where the credentials live. Who gets alerted when something fails at three in the morning. And how anyone notices that a workflow stopped running a fortnight ago.

The time to answer this is during the pilot, not after it. The same metrics that supported the decision become the ones you monitor, which means choosing them carefully from day one, as covered in the piece on the digital transformation metrics worth tracking.

The question to ask this week

It is not "which process do we want to automate." It is this: which process can we measure the current cost of over the next two weeks, without asking anyone's permission?

If there is an answer, the pilot has somewhere to start. If there is not, the problem is not automation yet. It is measurement.