Eliminate Rework Between Teams With Simple Automations

Rework between teams is work that was already done once and gets done again because the information never travelled. Sales closes the deal, operations ask the client for the same details, finance retypes everything into the invoicing system. Nobody made a mistake. The same data was still handled three times.

According to Asana's Anatomy of Work Index, the average knowledge worker loses 209 hours a year to duplicative work. That is roughly four hours a week. It is not idle time: it is time spent doing something for the second time.

The good news is that most of this rework does not need a transformation programme to disappear. It needs three or four small automations, placed where the handoffs are.

Rework lives in the handoffs

There is very little rework inside a single team. People share context, tools and vocabulary. Rework shows up at the boundary, where the process changes team, system and owner at the same time.

At that boundary there is always a manual translation. Someone reads what the previous team wrote and writes it again somewhere else, under different field names.

Rework between teams comes in three shapes, and they are worth separating because each has a different fix:

Re-entry. The same value is typed two or three times into systems that do not talk to each other.
Re-confirmation. Nobody knows the current status, so they ask. The answers cost as much time as the questions.
Redoing. Someone worked on the wrong version of a file, or on data that changed in the meantime.

On top of that sits the cost of hopping between applications to piece it all together. A study published in Harvard Business Review in 2022, tracking 137 users across three Fortune 500 companies, counted around 1,200 application switches a day, adding up to almost four hours a week spent simply reorienting attention.

What rework costs, with the arithmetic shown

Round numbers convince nobody. A simple calculation does.

The average hourly labour cost in Portugal was €19.40 in 2025, according to Eurostat's labour cost data published in March 2026, against an EU average of €34.90.

Picture an SME with four people involved in the cycle from order to invoice. If each loses three hours a week to rework — below the four hours in the Asana index, to keep the estimate conservative — that is 12 hours a week. Across 44 working weeks, 528 hours a year. At €19.40 an hour, roughly €10,200 a year.

That is an estimate, not a fact about your company. The three hours are the figure you have to measure; the rest is arithmetic. If you want to run the numbers properly, the method is set out in the article on how much manual processes actually cost.

What the calculation shows is the order of magnitude. In a small team, rework costs more per year than most of the software the company hesitates to buy.

Where rework hides

Four signals that show up almost everywhere, and that anyone can spot in a week of observation:

The same field typed twice. The client's tax number, the order reference or the delivery address exist in two systems and are keyed into both by hand.
Messages that only ask for status. "Has it shipped?", "was this invoiced?", "where are we on this?". Each one costs two minutes for the asker and two more for whoever answers.
Files sent again. If someone asks for the same attachment a second time, the file is not where it should be.
The parallel spreadsheet. When a team keeps its own spreadsheet alongside the official system, the official system is not giving them what they need — and somebody is feeding both.

That last one is among the most expensive and the most tolerated. It is covered in more detail among the signs your company needs digital transformation.

Three simple automations that remove rework

1. One entry point per piece of data

Before: sales fills in the quote on a spreadsheet and emails it over. Operations copy the details into the management system. Finance copies them again into invoicing. Twelve to fifteen minutes per order, three chances of a typing error, and no way to tell which copy is right when they disagree.

After: the data is entered once, in a form or in the CRM. One workflow creates the client record, the order and the invoicing entry in their respective systems. Seconds. A person only steps in when a field fails validation — a tax number with a wrong check digit, for instance.

The gain is not typing faster. It is typing once.

2. Status publishes itself

Re-confirmation is not solved the way people expect. It is not solved with more status meetings: it is solved by making the change of status notify whoever needs to know.

When an order moves to "shipped", the system posts the order number, the client and the expected delivery date to the team channel. Nobody has to ask, because the answer arrived before the question.

One caveat: notify on meaningful events, not on everything. A workflow that dumps every field change into a shared channel stops being read within two weeks, and people go back to asking by email.

3. A gate against processing the same thing twice

This is the least obvious one, and the one that prevents most rework once volume grows. If two workflows can pick up the same document, sooner or later both will.

In n8n this is handled by the Remove Duplicates node, using the "Remove Items Processed in Previous Executions" operation. The workflow stores an identifier for every item it has already handled — an invoice number, say — and discards anything it has seen before. The official node documentation sets out the available criteria: new values only, values higher than any previous one, or dates later than the last.

Two practical details are worth keeping in mind. The history holds 10,000 items by default, and the scope can be set per node or per workflow — with workflow scope, several nodes share the same memory of processed items, which is exactly what you want when the same document can arrive by two routes.

It is the automated equivalent of asking "has this already been dealt with?", except the answer is reliable and takes milliseconds.

Automation produces rework too

This deserves saying before anyone gets sold on the idea. A badly built automation does not remove rework: it generates it faster than a person ever could.

Webhooks are the usual culprit. Almost every service delivers events with at-least-once guarantees: if the response is slow or fails, it sends the event again. With no defence against duplicates, one event becomes two records.

The second culprit is automatic retrying. Turning on "Retry on Fail" for a step that sends an email or creates a record means an intermittent failure can produce three emails to the same client. The practical rule is not to auto-retry steps with external side effects, and to protect the ones that must retry with a unique identifier.

The realistic goal is not making sure the workflow runs exactly once. It is making sure the effect happens exactly once, even if the workflow runs three times.

And then there is the least comfortable limit of all: automating a badly designed handoff only makes it faster. If two teams disagree about which system holds the authoritative client record, automation will propagate that disagreement at speed. First decide which system owns each piece of data. Only then connect them.

Where to start cutting rework

Pick a process that crosses two teams and happens at least once a day. Low volume does not repay the effort of automating.

For two weeks, ask the people running it to log every time they retype a value that already existed somewhere else, with a rough time. No tooling required: a shared sheet is enough. At the end, sort by frequency multiplied by minutes and automate the top line.

Start with what is repetitive, has stable rules and structured data. Leave for later whatever needs judgement or throws up an exception every other case. To choose between concrete candidates, the list of business processes every company should automate is a reasonable starting point.

The question to take into your next team meeting is not "what can we automate?". It is simpler and more uncomfortable: which piece of data does your company write down more than once — and who decided it had to be that way?