What to Demand From an Automation Partner

Automating invoicing is not the same as automating an internal email. If the flow that issues your invoices stops on a Friday evening, you do not lose ten minutes of work. You lose cash flow, deadlines and credibility with the client.

That is why choosing an automation partner is settled in the contract rather than in the demo. The demo always goes well. What matters is the bad day, and who ends up paying for it.

None of the requirements below need a developer in the room. They are questions a manager can ask, and the answers tell you most of what you need to know.

Start by defining what is actually critical

There is a simple test. If the process stops for four hours, does anyone outside the company notice?

If the answer is yes — a client, a supplier, the tax authority, a bank — the process is critical. If it is no, it is merely important, and these requirements are overkill for it.

Do this sorting before the first meeting. A partner who treats invoicing and newsletters with the same level of care is overcharging for one and under-protecting the other. And if you are still weighing building it in-house against hiring, the comparison between in-house automation and a specialist partner comes before this conversation.

Demand ownership of whatever gets built

It sounds obvious and it is rarely written down. The contract must state that the flows, code and configurations built for your company belong to your company.

Ownership on paper is worthless without access in practice. Ask for two concrete things: flows in an open, exportable format, and an up-to-date copy in a repository your company can reach, not only the supplier.

One detail worth knowing here. In n8n, native Git integration is available only on the Business and Enterprise plans. On simpler installations, versioning has to happen through periodic exports, and somebody has to own that. Ask who.

Demand an exit plan that has been rehearsed, not promised

This is the requirement that separates serious suppliers from the rest: show me the recovery working.

"We have backups" is not enough. A concrete example, again with n8n: the official backup documentation states plainly that exporting workflows and credentials through the command line is not a complete backup of the instance. It leaves out execution history, variables, users and instance settings — including the encryption key.

Without that key, exported credentials cannot be decrypted again. You are left holding the drawings of your flows and none of the keys that make them run.

So the right requirement is not a document. It is a rehearsal: restore the process on a clean instance, in front of someone from your team, and time it. If nobody can tell you how many hours it takes, the exit plan does not exist.

Demand to know what happens when the flow fails at 3am

Every automated process fails eventually. A bank API changes, an email provider rejects a request, a file arrives in a different format. What separates a good partner from a bad one is what was built around that failure.

Ask three questions. How is the failure detected? Who gets alerted, and how quickly? And what happens to the records caught halfway — are they retried, duplicated, or lost?

n8n lets you attach an error workflow to each process, triggered when the main execution fails. It is not enabled by default. It is a choice made by whoever builds the flow, and it is a useful signal: anyone who skips it on a critical process has probably skipped the rest too.

Put a number on the silent failure

The worst case is not the noisy failure. It is the one nobody notices for a week.

Here is an estimate, with the arithmetic shown. Take a company issuing 600 invoices a month, roughly 30 per working day. If the flow fails quietly on a Monday and is only spotted on Friday, that is five days and around 150 invoices never sent.

On 30-day payment terms, every euro invoiced that week arrives five days late. Recovering those 150 invoices by hand, at three minutes each, is seven and a half hours of unplanned work. To get the real figure for your own case, the method for costing a manual process applies unchanged.

The numbers vary by company. The conclusion does not: almost all of the cost sits in the time to detection, not in the failure itself.

Demand clarity on where the data sits

If the process handles personal data — invoicing, payroll and recruitment all do — your partner is a processor under the GDPR. That means a written contract, documented instructions and prior authorisation before they bring in anyone else.

Three questions cover most of the ground. Which country does the platform run in? What data is retained in the execution history, and for how long? And who on the supplier's side still holds administrator access once the project is delivered?

That last one catches people out. Access is often left open indefinitely, out of convenience. Require it to be named, revocable and reviewed. When the platform runs on your own server, this conversation gets considerably simpler: the data never leaves your infrastructure, and the list of people who can reach it is short and verifiable.

Demand the clauses the law already asks for

Supply chain security is not a preference any more. Under the NIS2 Directive, security in the relationship between an entity and its direct suppliers and service providers is an explicit, mandatory risk-management measure. Portugal transposed it through Decree-Law 125/2025, in force since 3 April 2026.

Two practical consequences for an SME.

First: even if your company is not directly in scope, your larger clients may well be, and they will push these requirements down into their contracts. Getting there early saves time later.

Second, the deadlines. The regime requires an early warning of a significant incident within 24 hours, an update at 72 hours and a final report within a month. If your contract does not oblige the partner to tell you within hours, the 24-hour window burns while you wait for an email. Fines reach 10 million euros or 2% of global annual turnover for essential entities.

Demand documentation that outlives its author

The question is this: if the person who built this leaves tomorrow, how long does it take someone else to understand it?

The minimum documentation for a critical process fits in a few pages. What the flow does, in what order and with what data. Which systems it touches and with which credentials. What to do when it fails, step by step. And who decides, on your side, when something is unclear.

A good acceptance test: ask for documentation written so that a different supplier could pick the process up. A confident partner agrees without hesitating.

What is not worth demanding

Not every requirement helps.

Do not ask for a fixed price on a process you have never measured. You will get a safety margin baked into the quote, and you will pay for it. Mapping the process before automating it costs less than that margin.

Do not demand 100% automation. The last 10% of exceptions usually costs more than the first 90%, and rarely pays for itself. A good partner tells you where to stop.

And do not pick the tool before describing the problem. The choice of platform follows from requirements like data sovereignty, volume and existing integrations. It is not the starting point.

The question that settles the meeting

Before signing, take the most critical process on your list and ask one question: if this partner disappeared tomorrow, how many days until the process runs again?

The right answer is a number, with an explanation of how you get there. Anything else — "that won't happen", "it is all replicated", "there is no such risk" — means you do not have an automation partner yet. You have a dependency.