Business process automation, built to be handed over

Find the cost before building anything

Every business has a rough sense that something is slow. Very few can name which step, how many times a week it runs, and what it costs when it goes wrong. Without that, automation is guesswork with a budget attached.

The first piece of work is arithmetic, not engineering. Count how often a process runs, how long each pass takes, how often it needs redoing, and what a failure costs. Some processes turn out to cost more to automate than to leave alone, and knowing which ones is worth more than a fast build.

• Volume, measured rather than estimated from memory
• Time per pass, including the part everyone forgets, which is checking
• Error rate and what a single error costs downstream
• How often the process changes, because a process that changes weekly resists automation

The processes that pay back fastest

Across most businesses the same handful of workflows come up, in roughly this order of return.

• Intake and routing, so an enquiry reaches the right person without a human triaging it
• Approval chains, where the delay is almost always waiting rather than deciding
• Document handling, pulling structured data out of invoices, orders and forms
• System reconciliation, keeping two tools agreeing without anyone exporting a spreadsheet
• Recurring reporting, assembled automatically instead of rebuilt by hand every Monday
• Exception handling, where the automation flags what it could not process rather than failing quietly

Why exception handling decides whether it survives

Most automation projects do not fail on the happy path. They fail the first time something unexpected arrives and the workflow either stops without telling anyone or, worse, carries on and writes bad data into a system people trust.

A workflow built properly assumes it will be surprised. Anything it cannot handle is queued for a person, with the reason attached, and nothing is written until it is resolved. That single design decision is the difference between an automation a team trusts and one they quietly stop using.

Silent failure is worse than no automation, because it takes months to notice and the bad data spreads the whole time.

Tools, and why the choice is not the point

n8n, Make and Zapier all do this work. n8n can be self-hosted, which matters when credentials and data need to stay under the client's control. Zapier is faster for simple two-tool connections. Make sits between them.

Wobble builds on all three and recommends by fit. The reason that matters is not neutrality for its own sake: a partner locked into one tool will describe your problem in terms of what their tool does well, and you will pay for the mismatch every month afterwards.

Handover is the deliverable

Workflows are documented, credentials use least-privilege access, and every failure mode is handled explicitly. The client owns the instance and the logic and can take it in-house whenever they choose.

This is a commercial position, not a philosophical one. A business that cannot maintain its own automation has bought a dependency, and dependencies get repriced.

How the work is priced

Process automation is normally a scoped project with a defined end, and it should be. You are buying a finite set of workflows, documented and handed over, not a subscription to somebody else's attention. What follows is smaller: a support arrangement for the months when a supplier changes a form or a credential expires, decided once the build exists rather than bundled into it.

What moves the number is not the count of workflows. It is how many systems have to be connected and how well behaved they are. Two applications with proper APIs and stable fields is an afternoon of integration.

One desktop application with no API, or a spreadsheet that three people edit in three different ways, can cost more than the rest of the project put together. The second driver is whether the process is written down. If the only description of it lives in one person's head, mapping it is a phase of its own and it is real work.

Anyone quoting before walking the process end to end and listing every system it touches is quoting a sales number. The list is the estimate. Ask to see it.

• How many systems the workflow touches, and how many of them have a usable API
• Whether the process is documented, or has to be mapped from how people actually do it
• How many exceptions the process really has, since exception handling is most of the build
• Whether it runs on infrastructure you host or on a platform that bills per operation

Processes that should be left alone

A broken process automated is a broken process running faster. If the underlying steps do not make sense, fixing them on paper first is cheaper than encoding the mess and maintaining it forever.

Processes that change every week are also poor candidates. The maintenance cost outruns the saving, and the honest recommendation is to stabilise the process before automating it.

Common questions

What is business process automation?

It is automating the operational work that moves between systems and people rather than the work inside any one application. Typical examples are routing an enquiry to the right person, moving an approval forward, extracting data from an invoice, keeping two systems in agreement, and assembling a recurring report.

How do I know which process to automate first?

Measure four things for each candidate: how often it runs, how long a pass takes including the checking, how often it has to be redone, and what a failure costs downstream. Automate the one with the highest product of frequency and cost, not the one that annoys people most.

What is the difference between AI automation and normal automation?

Normal automation follows fixed rules and is the right answer whenever the decision is deterministic. AI is added only where a judgement is genuinely needed, such as reading an unstructured message or classifying a document. Most working systems are mostly rules with AI used sparingly, and any system that is mostly AI is usually overbuilt.

How long does a process automation project take?

A single well-scoped workflow is usually a matter of weeks rather than months, and the measurement that precedes it is often the longest part. A programme covering several connected processes is scoped in phases so each one is running and measured before the next begins.

Which automation platform is best?

It depends on the job and on who has to maintain it afterwards. n8n is self-hostable and handles complex branching and AI orchestration well. Zapier is simpler for straightforward connections. Make sits in between. The wrong question is which platform is best; the right one is which platform your team can still run in two years.

What happens when an automated workflow hits something unexpected?

It should queue the item for a person with the reason attached, and write nothing until it is resolved. The failure to design against is the workflow that carries on and writes bad data into a system people trust, because that takes months to notice and spreads the whole time.