The Removal Van Is a Workflow Audit You Didn't Book

There is a particular kind of honesty that arrives about four days before an office move. The labelled crates are stacked by the lifts, the floor plan has been printed at least three times, and someone has just discovered that the only person who knows how the supplier invoice approval actually works is on annual leave in Cornwall.

That is not a logistics problem. It is a workflow problem wearing a high-vis jacket.

Most UK teams treat a move as a facilities project with a technology garnish: book the removals firm, argue about desk booking, test the meeting room screens, then hope the rest sorts itself out. But an office move is a forced audit. Every handoff that only worked because two people sat within shouting distance gets exposed. Every shadow process that lived in a drawer, a direct message or a Post-it note suddenly has to survive a change of address. Every 'just ask Priya' workaround becomes a visible dependency.

In 2026, with hybrid teams spread across kitchen tables and regional hubs, the move is one of the few moments when everyone is forced to ask a simple question: what actually deserves to travel with us?

The office was doing workflow work without a job title

Open-plan offices are full of invisible middleware. The finance lead who overhears a conversation and quietly fixes a purchase order. The operations manager who walks past a desk, sees the look on someone's face, and intercepts a customer problem before it becomes a complaint. The IT technician who knows that the printer on the second floor only works if you send the job twice and then stand slightly to the left.

None of that appears in a process map. It appears in a removal van as a pile of unlabelled cables and a team group chat asking where the signed delivery book has gone.

A move is useful precisely because it breaks the proximity. When people are no longer in the same building, the informal repair work becomes expensive. The question is whether you notice it before the first week in the new place, or during it.

Start with the handoffs, not the furniture

Before anyone reaches for bubble wrap, list the handoffs that cross a team boundary. Not the org chart, not the software stack, not the aspirational operating model. The actual moments where work changes hands.

A client enquiry moves from sales to delivery. A new starter's laptop request moves from HR to IT. A content draft moves from marketing to legal. A support ticket moves from first line to second line. A supplier invoice moves from accounts payable to a director's inbox for a nod that nobody has documented.

For each handoff, ask three questions:

1. Who does it now, and who thinks they do it?
2. What does the receiver actually need to act, not just to be informed?
3. What would break if the person sending it were off sick for a week?

The answers will not be tidy. That is the point. You are looking for the places where the workflow depends on physical proximity, memory or a specific human being. Those are the ones that need a decision before the removal van arrives.

Retire something on purpose

A move is a rare chance to leave things behind without hurting anyone's feelings. Most teams have at least one process that exists because it made sense when the office was in a different location, the team was twice the size, or a particular client had a particular requirement in 2019.

Use the move to name those processes and retire them deliberately. Not with a grand transformation programme. With a short list and a named decision-maker.

A useful test: if this workflow were proposed today, would we build it? If the answer is a polite pause, it probably should not get a box label. Retiring a process in the middle of a move is easier than retiring it during business as usual, because everyone already expects change. The cover story writes itself.

Decide what travels, and give it an owner

Anything that survives the move needs an owner on the other side. Not a committee. Not a shared inbox. A person whose name appears next to the workflow and who can answer the awkward question: who fixes this when it goes wrong?

The owner does not have to do every task. They have to know how the work moves, who is involved, and what happens when someone leaves. In practice, that means a short written note for each travelling workflow: purpose, trigger, steps, systems, handoffs, escalation route and review date.

Keep it brief. A page is plenty. The goal is not a beautiful process library. It is a fighting chance that the workflow survives the first month in a new building without becoming a folklore project.

The first week is the real test

The new office will feel like a test environment. The door access will be flaky, the meeting room booking system will have opinions, and someone will discover that the new coffee machine requires a training course.

That is exactly when to watch the handoffs. Which ones worked? Which ones stalled? Where did people invent a new workaround because the old one no longer made sense? Capture those observations in the first two weeks, while the move is still fresh and people are still willing to say what is not working.

Then update the notes. A move is not a one-off audit. It is a stress test with a delivery date. The teams that come out of it well are not the ones with the tidiest packing labels. They are the ones who used the disruption to decide, on purpose, what work deserves to continue.

The removal van does not care about your operating model. It only carries what you give it. The useful question is whether you know what you are putting on the van, and who is expecting it at the other end.