How to identify handovers, delays and rework

Your process looks clean on the whiteboard. Orders come in, get picked, get invoiced, get shipped. Simple. But somewhere between the sales rep closing the deal and the customer receiving the goods, three people re-enter the same data, one email falls through the cracks for two days, and the warehouse re-picks an order because the original pick list had the wrong quantity. Nobody designed that waste — it just accumulated. This article shows you exactly how to find it: the handovers nobody documented, the delays everyone has accepted as normal, and the rework nobody measures.

Why does hidden waste survive for years unnoticed?

Most companies measure outcomes — revenue, on-time delivery rate, invoice error rate. What they rarely measure is the process between the outcomes. The gap between "order received" and "invoice sent" is a black box for most organizations. Inside that box, each team has optimized their own piece of the work, and nobody owns the seams.

Handovers are the most dangerous seams. A handover is any moment when work moves from one person, team, or system to another. Every handover is a potential drop point: information gets lost, context doesn't transfer, and the next person starts with incomplete input. In a typical manufacturing company, a single sales order can pass through five or six handovers before it becomes a shipped product — sales to planning, planning to purchasing, purchasing to warehouse, warehouse to production, production to dispatch, dispatch to invoicing. Each transition is a risk.

Delays are handovers that got stuck. The purchase order sits in an inbox waiting for approval. The design file waits for client sign-off that nobody chased. The shipping label waits because the ERP hasn't been updated yet. These delays are invisible on paper because the process map says the step exists — it just doesn't say how long it actually takes.

Rework is what happens after a failure that nobody logged as a failure. The invoice goes out with the wrong price, and someone quietly corrects it. The pick list is wrong, and the warehouse team re-picks without telling anyone. Rework is the iceberg: you see the corrected output, not the double effort underneath.

How do you actually find handovers, delays, and rework?

The single most effective method is deceptively simple: trace one real transaction from start to finish, with the people who actually do the work. Not the process owner. Not the manager. The people whose hands touch it every day.

Here is how to run that trace in practice:

Step 1 — Pick a representative transaction

Choose a recent order, project, or case that is typical — not the nightmare exception, not the smooth flagship client. In manufacturing, pick a standard production order that went through the full cycle last month. In wholesale/distribution, pick an order with at least two line items that required a purchase from a supplier. In professional services, pick a project that involved more than one internal team.

Avoid choosing a transaction that the team knows you are going to scrutinize — you want normal behavior, not a rehearsed showcase.

Step 2 — Walk the transaction, not the process map

Ask each person involved to show you exactly what they did, in the system or tool they used, in the order they actually did it. Do not start from the process map — start from the transaction ID and follow it forward through time.

Ask these questions at every step:

• Where did this information come from?
• What did you have to look up, copy, or retype?
• Did anything slow you down or make you wait?
• Did you have to correct or redo anything before you could continue?
• Who do you hand this off to, and how?

Record the actual timestamps wherever possible: email headers, system logs, modification dates on files. Timestamps expose delays that no one will volunteer — not because they are hiding them, but because they have normalized them.

Step 3 — Map every handover explicitly

As you walk the transaction, draw a handover map — not a flowchart of steps, but a map of transitions. For each handover, note:

• Who hands off (person or system)
• Who receives (person or system)
• What medium (email, phone call, system trigger, shared folder, verbal)
• What information travels with the handover
• What information is missing or has to be re-looked-up by the receiver

In a typical wholesale distributor, you will find that a sales order confirmed by the account manager triggers a manual email to the purchasing department, who re-enters the supplier code and quantity into the ERP — even though both pieces of information already exist in the CRM. That is one handover, one delay, and one data entry risk, all in the same seam.

Step 4 — Measure the time gaps, not just the steps

This is where most process analyses go wrong. They list the steps and declare the process mapped. But the waste rarely lives in a step — it lives between steps.

For every handover you identified in Step 3, find the actual elapsed time between the moment one person or system finished and the next person or system started. In professional services firms, it is common to find that a completed deliverable sits for 48 hours in a shared inbox before the next team member opens it — not because anyone is lazy, but because there is no trigger, no notification, and no ownership of the queue.

Create a simple time-gap table:

Handover	From	To	Expected time	Actual time (last 5 cases)	Gap
Sales → Planning	CRM confirmed	Planning notified	2 hours	1.5 days average	1 day
Planning → Warehouse	Pick list created	Pick started	30 min	4 hours	3.5 hours

Once you have numbers, the conversation changes. Nobody argues with a column that says "average 1.5 days" when the expectation was 2 hours.

Step 5 — Find the rework by asking about corrections

Rework is the hardest waste to surface because it happens after the official process. The best question to ask is: "Before you could do your part, did you ever have to fix or complete something that should have been done upstream?"

In manufacturing, the production planner who quietly corrects the bill of materials before releasing a work order will not list that as a step — it is invisible to everyone except them. In professional services, the project manager who rewrites the scope document because the account manager wrote it incorrectly will not log those two hours anywhere. Ask specifically for corrections, fixes, and "just to make sure" double-checks.

Also look at:

• Rows in your ERP with modification timestamps significantly after creation
• Email threads with subject lines containing "RE: RE: RE: correction" or "updated version"
• Duplicate records in any system
• Fields left blank that are required later (forcing someone downstream to go back and fill them)

What are the most common patterns you will find?

Across manufacturing, wholesale, and professional services, the same patterns appear repeatedly:

The silent re-entry loop: An order gets confirmed in the CRM, and then someone manually re-enters it into the ERP or accounting system — every single order, every single day. The person doing it has stopped noticing it because it has been their job for three years.

The approval bottleneck: A single person's approval gates every purchase order, every invoice above a threshold, or every scope change. When they are out of the office, the queue grows. When they return, they approve in bulk without review. The control that was meant to reduce risk has become a delay that adds risk.

The "just check with" step: The warehouse checks with sales before picking any order over a certain value. Sales checks with the client before confirming the delivery date. The project lead checks with the director before sending any proposal. These informal verification steps are often legitimate — but they are rarely documented, often duplicated, and almost always slower than anyone admits.

The version conflict handover: In professional services especially, a document, drawing, or specification gets handed off by email. The receiver edits it, sends it back. The sender edits the original. Two versions exist. Someone has to reconcile them. Every hour spent reconciling is rework that could have been designed out.

The format translation: A supplier sends a PDF confirmation. Someone types the quantities into the ERP. The ERP exports to Excel. Someone pastes the Excel into a report. Four format translations for one piece of data — each is a delay, each is a potential error.

How do you distinguish a genuine handover from normal collaboration?

Not every handover is waste. A handover becomes a problem when it meets one or more of these criteria:

• Information has to be re-entered rather than transferred
• The receiving party has to ask clarifying questions before they can start
• There is no defined trigger — the receiver doesn't know to start until they happen to check
• The handover relies on one specific person's knowledge to execute correctly
• The delay introduced by the handover is longer than the step itself

If a handover meets none of these criteria — the information arrives complete, the trigger is automatic, any team member can receive it — it is probably fine as is.

Checklist: Are you ready to map handovers, delays, and rework?

Before you run a process trace, make sure you have these in place:

• A specific, real transaction selected (not a hypothetical flow)
• Access to the people who actually perform each step (not only managers)
• Permission to access system logs, email timestamps, and modification histories
• A neutral facilitator who is not the process owner
• A simple recording format — a spreadsheet or shared doc is enough
• Time allocated per person: 30–60 minutes of uninterrupted walkthrough
• Agreement that you are mapping the real process, not the intended one

FAQ

Do I need process mining software to do this? No. Process mining tools (like Celonis or Minit) are powerful for large data sets, but for most SMEs the most valuable insights come from a structured conversation and a time-gap table you build in a spreadsheet. Start with the manual trace — invest in tooling only once you know what questions you need answered at scale.

What if people are reluctant to show the real process because it makes them look bad? Frame the session explicitly as a system review, not a performance review. You are looking for process failures, not people failures. The person who does rework every morning is not the problem — the process that requires the rework is. Make this clear before the session and reinforce it during.

How many transactions should I trace? Start with three to five transactions of the same type. One trace will show you what can happen. Five traces will show you what usually happens — and where the variation lives. Variation is often more important than the average: a handover that sometimes takes 2 hours and sometimes takes 3 days is a more urgent problem than one that always takes 4 hours.

Should I map the as-is process before or after interviewing employees? After — always after. Starting with the official process map biases the conversation toward how the process should work. Starting with the real transaction and asking people to show you their actual work surfaces the gaps. Once you have the real picture, you can compare it to the official map — the differences are where your problems live.

At what point should I bring in a developer or automation specialist? Only after you have a clear picture of all handovers, delays, and rework in the current process. Automating an undocumented or broken process embeds the waste into the software. The map comes first — then the solution.

How do I prioritize which problems to fix first? Score each identified issue on two dimensions: frequency (how often does this happen per week or month?) and impact (how much time, cost, or error risk does it introduce per occurrence?). Fix high-frequency, high-impact problems first. A daily re-entry of order data beats a monthly workaround, even if the monthly workaround feels more dramatic.

---

Once you have a clear map of where work stalls, who carries information in their head, and where rework silently eats hours every week, you are in a much stronger position to decide what to fix and how. Some problems are solved with a clearer process agreement. Others require a system change — connecting two platforms that currently share data by hand, building a workflow that triggers the next step automatically, or adding a validation layer that catches errors before they travel downstream. If you are at the point where the map is clear but the solution is not, that is exactly where Loggix works with manufacturing, wholesale, and professional services companies: mapping what is actually happening, designing what should happen instead, and building the custom software or integrations that make the better process stick.