From Diagnosis to Production: How a Business Automation Project Works With Broccolli

A business automation project does not start with a tool. It starts with a simple question: where is the team losing time, and what does that time cost?

This article walks through, phase by phase, what happens between the first conversation with Broccolli and the moment an automated workflow runs on its own in production. It covers what we deliver at each stage, what we need from your side, and what a project like this will not fix.

First: 30 minutes to see whether it makes sense

The first conversation is a free 30-minute call. It is not a sales pitch.

The aim is to look at the company's biggest operational problem and answer two questions honestly: can we solve it, and how long will it take?

Sometimes the answer is "you don't need us". A process that runs ten times a month rarely justifies automation. A problem that is organisational rather than technical doesn't either.

Phase 1: diagnosis before automation

Our rule is the same as a doctor's: diagnose before you prescribe.

During the diagnosis we map the process as it actually runs today, not as the manual describes it. Who does each step, in which system, with what data, and where work sits waiting for someone.

That map produces three lists, in this order:

1. What to eliminate. Steps nobody needs, duplicate approvals, reports nobody reads.
2. What to simplify. Confusing rules, exceptions that became the norm, data typed in twice.
3. Only then, what to automate.

Automating a badly designed process just makes the mistake happen faster. If you want to prepare this work in-house, we have explained how to map your processes before starting an automation project, at the level of detail that is actually useful.

The diagnosis also records the starting point: monthly volume, minutes per run, error rate. Without these numbers there is no way to prove, three months later, that the project paid off. The method for turning that into a figure in euros is in our piece on how much manual processes actually cost.

Phase 2: prioritisation, because not everything gets automated

The diagnosis usually uncovers more candidates than it makes sense to tackle at once. Prioritisation picks the first one.

The criterion weighs impact against risk. Impact is time and errors avoided. Risk is technical complexity, data quality and what happens if the workflow fails.

An illustrative example, with round numbers to show the calculation (not a real case or a guaranteed result):

• A distributor receives 600 supplier invoices a month.
• Each takes 6 minutes to enter into the ERP: open the PDF, copy the data, check it against the purchase order.
• That is 60 hours a month on this step alone.

Assume the automation handles 70% of invoices on its own and the remaining 30% go to a person, as they do today. Add half a minute of checking per automated invoice and the workload drops to about 21 hours a month.

The estimated saving is close to 39 hours a month. But note the assumption: the 70%. That figure is not promised, it is confirmed. That is what the next phase is for.

Phase 3: delivery in two-week sprints

We don't run six-month projects with a single handover at the end. We work in two-week sprints, and every sprint ends with something that works and that the team can see.

The first sprint is, in practice, a pilot. It runs on real data with a narrow scope: one supplier, one team, one document type. This is where the 70% assumption becomes a measured rate. We covered the logic in how to build an automation pilot that proves value before scaling.

Tooling depends on what the company already uses. In a Microsoft 365 business, Power Automate is often the natural choice. With many different systems, or data that should not leave the company's own infrastructure, self-hosted n8n usually fits better. When a step involves reading documents or interpreting free text, an AI layer comes in, always with human review for uncertain cases.

One rule we don't bend: nothing is built directly on the environment the business runs on every day. Microsoft's own environment strategy guidance for Power Platform recommends separate development and production environments, with at least one test environment in between.

Going live: what changes

A workflow that works in testing is not ready yet. Going to production means answering a different question: what happens when it fails?

And it will fail. A supplier changes their PDF layout, an API is down for an hour, a password expires. So before switching a workflow on for real, we make sure of four things:

• Error alerts. In n8n, every workflow can have an error workflow that fires whenever a run fails and notifies someone by email or Slack. A silent failure is the worst possible outcome.
• An owner on your side. Someone who receives those alerts and knows what to do with them.
• Your credentials, not ours. Accounts and access sit in the client's name. If the relationship ends, the workflows keep running.
• Short documentation. What the workflow does, where it reads from, where it writes to, and how to switch it off in an emergency.

For the first few weeks, cases the automation cannot handle confidently go to a person. Reviewing a little too much early on beats finding an error at month-end close.

Phase 4: optimisation, measured against the baseline

A business automation project doesn't end when the workflow goes live. That is when measurement starts.

The diagnosis figures are collected again: hours per month, error rate, share of cases handled without intervention. The target we set is measurable return within 90 days.

With real data, the rules get tuned. Cases that always went to review may become automatic. Others that looked simple may need a person back in the loop. Only once the first process is stable do we move to the next one on the priority list.

What this process won't fix

It is worth being clear about what a project like this does not do.

It won't compensate for poor data. If the ERP has duplicate suppliers, the automation will book invoices to the wrong ones with great efficiency.

It won't replace management decisions. If nobody has the authority to remove a redundant approval, the diagnosis will flag it, but it won't disappear.

And it has running costs. Some governance features are priced separately: in n8n, for instance, source control with separate environments is only available on the Business and Enterprise plans. That goes into the numbers from the diagnosis onwards, not as a surprise later.

Where to start

If you had to pick one process today to take through these four phases, which would it be? And do you know how many hours a month it consumes?

If the answer to the second question is "I don't know", the first step of any business automation project is already clear: measure it.