CutFlow was born from running a real manufacturing business - a 130-person, 5-branch bespoke workshop producing kitchens, wardrobes, and commercial fitouts. Each branch specialised in different stages of production: one handled cutting, another edging, another assembly, and so on. On paper, this division of labour made perfect sense. In practice, coordinating production across five separate locations was the hardest operational challenge we ever faced.
The fundamental problem was deceptively simple: when Branch A finishes cutting panels for a kitchen order, Branch B needs those panels for edging. But Branch B is already working through a backlog, and Branch C also needs the CNC machine time that Branch A is about to free up. Meanwhile, the customer is calling to ask why their delivery date has slipped. Every decision at one branch had ripple effects across the other four, and nobody had a clear picture of the whole system. This article describes what we learned - the failures, the solutions, and the scheduling framework that eventually brought order to the chaos.
In this article
The 5-Branch Setup
Our operation didn't start as five branches. It started as one workshop with eight people. Over the course of a decade, organic growth pushed us to expand - first into a second unit across the road for assembly, then a dedicated finishing facility, then a separate cutting operation when we invested in a beam saw and CNC, and finally a dispatch and logistics hub. By the time we stepped back to look at what we'd built, we had 130 people spread across five locations within a 15-mile radius.
Each branch had a distinct role:
Branch A - Cutting (22 staff)
Beam saw, CNC router, panel optimisation. All sheet materials were cut here before being distributed to other branches. This was the starting point for almost every job.
Branch B - Edging & Machining (18 staff)
Edgebanders, drilling lines, and specialist machining. Panels arrived from Branch A and left ready for assembly. The bottleneck of the entire operation.
Branch C - Assembly (45 staff)
The largest team. Cabinet assembly, worktop templating, and sub-assembly for complex units. Depended on finished panels from Branch B and hardware from suppliers.
Branch D - Finishing (28 staff)
Spray booths, lacquering, wrapping, and hand finishing. Some items came here before assembly, others after. The routing depended on the specification.
Branch E - Dispatch & Logistics (17 staff)
Quality checks, packing, storage, and delivery coordination. Everything converged here before reaching the customer.
At any given time, we had 50 to 70 active jobs flowing between these branches. A single kitchen order might touch all five locations over the course of three to four weeks. The coordination challenge was enormous - and it only got worse as order volumes grew.
Why Traditional Scheduling Failed Us
We tried everything before we got it right. The progression will sound familiar to anyone who has run a multi-site operation, because it follows the same pattern almost every growing manufacturer goes through.
Phase 1: Whiteboards at Each Branch
Each branch manager had a whiteboard showing their current jobs. This worked well within each branch - the cutting team knew what they were cutting today, the assembly team knew what they were building. The problem was that no branch could see what was happening at the others. Branch A's whiteboard showed "Job 4872 - cutting complete," but Branch B had no way of knowing that unless someone phoned them. Information lived in five separate silos.
Phase 2: Shared Spreadsheets
We moved to a shared Google Sheet that all five branch managers could access. In theory, everyone would update the master schedule as jobs moved through their branch. In practice, version control was a nightmare. Two managers would edit simultaneously and overwrite each other's changes. Rows would get accidentally deleted. Someone would sort the sheet by a different column and break all the conditional formatting. Within three months, trust in the spreadsheet had eroded so badly that managers stopped using it and reverted to their whiteboards.
Phase 3: WhatsApp Became the Scheduling Tool
This is the phase nobody plans for, but nearly every multi-site manufacturer ends up here. When the official systems fail, communication moves to WhatsApp groups. We had a group for each branch, a group for all managers, a group for urgent jobs, and various one-to-one threads for specific orders. The result was that critical scheduling information was buried in a stream of messages, photos, and voice notes. Finding out whether Job 4872's panels had been edged meant scrolling through 200 messages in the Branch B group - or just calling the manager directly.
The breaking point came with a large kitchen order for a commercial client. Branch A completed cutting on a Tuesday. The panels sat on a pallet at Branch A for three full days because nobody told Branch B they were ready. Branch B's manager assumed cutting was still in progress. The customer's delivery date slipped by a week, and we lost the follow-on contract. That single failure cost us over £30,000 in lost future revenue - all because of a communication gap between two buildings eight miles apart.
The Dependency Problem
The core challenge of multi-branch scheduling is dependencies. Unlike a single-site workshop where jobs flow through stages on the same shop floor, a multi-branch operation has hard physical boundaries between stages. Work doesn't naturally flow from one step to the next - it has to be deliberately moved, communicated, and received.
The dependency chain in our operation looked like this: Branch A couldn't start cutting until materials had arrived from suppliers. Branch B couldn't start edging until Branch A's cutting was done and the panels were physically transported. Branch C couldn't begin assembly until Branch B had finished edging and all supplier-direct hardware (hinges, drawer runners, handles) had arrived separately. Branch D's finishing schedule depended on specifications that sometimes changed mid-order. And Branch E couldn't schedule dispatch until every component from every branch had converged in one place.
One delay at any point cascaded across the entire chain. A late material delivery to Branch A didn't just delay cutting - it pushed back edging, assembly, finishing, and dispatch in sequence. And because each branch was running multiple jobs simultaneously, a delay on one order could knock other orders out of their scheduled slots too.
Real Scenario: The Cascade Effect
A supplier delivered 18mm Dust Grey MFC two days late. Branch A rescheduled cutting for Job 5104, pushing it behind two other jobs. Branch B had already allocated edging time for Job 5104 on Wednesday - that slot was now empty, so they pulled forward Job 5098 instead. But Job 5098's hardware hadn't arrived at Branch C yet, so when the edged panels reached assembly, they sat on a trolley for four days waiting for hinges. Branch D had reserved finishing time based on the original schedule, but by the time the assembled units arrived, that slot had been given to another order. Total delay to the customer: 11 days. Root cause: a 2-day late material delivery.
This kind of cascade was not unusual. It happened multiple times per week. The problem wasn't that individual branches were performing badly - each one was working hard and managing their own queue competently. The problem was that nobody could see the whole picture, and there was no mechanism for propagating schedule changes across the chain in real time.
Our Scheduling Framework
After years of iteration, we developed a scheduling framework that actually worked across five branches. It wasn't a single breakthrough - it was four principles applied consistently, supported by the right tooling. These principles eventually became core features in CutFlow.
1. Central Job Queue with Branch-Specific Views
Instead of five separate scheduling systems, we created a single centralised job queue. Every order lived in one place, with a clear status showing which branch currently owned it and what stage it was at. But crucially, each branch manager could filter this central queue to see only their own work. Branch B's manager saw a clean list of jobs waiting for edging, with estimated arrival dates from Branch A. Branch C saw everything waiting for assembly, with clear indicators showing whether both edged panels and hardware were ready. One source of truth, five tailored views.
2. Automatic Status Propagation
This was the single biggest improvement. When Branch A marked a job's cutting as complete, Branch B's queue updated automatically. No phone calls, no WhatsApp messages, no waiting for someone to update a spreadsheet. The status change propagated instantly. Branch B could see that panels for Job 5104 were ready for collection, and could plan their edging schedule accordingly. This eliminated the communication gap that had caused our £30,000 loss and countless smaller delays.
3. Capacity-Aware Scheduling
Each branch had a defined weekly capacity measured in production hours. Before committing to a customer delivery date, we could check the load at every branch the job would pass through. If Branch B was already at 95% capacity for the week a job needed edging, we knew the delivery date had to account for that. This replaced the old approach of promising dates based on optimistic assumptions and then firefighting when reality didn't cooperate. The sales team could quote realistic dates because they could see actual branch capacity before making promises.
4. Buffer Time Between Branches
We learned this one the hard way. Initially, our scheduling assumed zero transit time between branches - if cutting finished on Tuesday afternoon, edging was scheduled for Wednesday morning. But physical reality doesn't work that way. Panels need to be palleted, loaded onto a van, driven to Branch B, unloaded, and checked in. That process takes at least half a day, sometimes a full day if the van is running other deliveries. We built mandatory buffer time into every branch-to-branch handoff. It felt wasteful at first - adding a day to every transition seemed like it would slow everything down. In practice, it made the schedule reliable. Jobs stopped arriving at branches before they were expected, and branch managers could plan with confidence.
Key Insight
The biggest scheduling improvement wasn't a clever algorithm - it was making status changes visible across branches in real time. When Branch A marks cutting complete, Branch B should know immediately, not when someone remembers to make a phone call. Automation of information flow matters more than optimisation of production flow.
Real-Time Visibility Changed Everything
Before implementing this framework, our branch managers spent an estimated 30 to 45 minutes per day on phone calls to other branches. "Have you finished cutting Job 5089?" "When will the edged panels for Job 5092 be ready?" "Has the hardware for Job 5101 arrived at your end?" Multiply that by five managers and you're looking at over three hours of collective management time every day spent simply asking "where are things?"
After the transition, a shared dashboard showed every job's location and status across all five branches. Any manager could open it and see, at a glance, that Job 5089 was in transit between Branch A and Branch B, that Job 5092's panels were being edged and would be ready by Thursday, and that Job 5101's hardware was still showing as "on order" from the supplier. The phone calls dropped to near zero for routine status queries. Managers only called each other when there was an actual problem to solve, not just to gather information.
The impact on delivery accuracy was dramatic. Before the framework, we tracked our on-time delivery rate at roughly 65%. That meant one in three customers received their order late. After six months with the new system, on-time delivery improved to approximately 90%. The remaining 10% of late deliveries were almost always caused by external factors - supplier delays, customer-requested changes, or specification issues - rather than internal scheduling failures.
Customer complaints about timing dropped by more than half. Our sales team became noticeably more confident quoting delivery dates because they trusted the schedule. And perhaps most importantly, the stress level across all five branches decreased measurably. When everyone can see the whole picture, the anxiety of not knowing is replaced by the ability to plan and respond. Branch managers stopped firefighting and started managing. For more detail on how production visibility features work in CutFlow, see our production features page.
Key Lessons for Multi-Site Manufacturers
After running this system for several years and building CutFlow around these principles, here are the lessons we'd pass on to any manufacturer operating across multiple sites:
One source of truth is non-negotiable
If each branch maintains its own schedule, you will have conflicts, missed handoffs, and finger-pointing. Every job must live in a single system that all branches can see and update. Duplicate systems, no matter how well-intentioned, always drift out of sync. This is the foundation everything else is built on. ACAS offers useful guidance on managing staff expectations and communication across multi-site operations, which applies directly to this coordination challenge.
Automate handoff notifications relentlessly
The biggest source of delay in multi-branch operations is the gap between one branch finishing and the next branch knowing about it. Every handoff point should trigger an automatic notification. If you rely on humans to communicate status changes, they will forget, get busy, or assume someone else did it.
Build buffer time into every branch transition
Physical transport between sites takes time. So does receiving, checking, and staging incoming work. A schedule that assumes instant handoffs will fail consistently. Add at least half a day of buffer for every branch-to-branch transition, more if sites are further apart. The schedule will be longer but far more reliable.
Check capacity at every branch before quoting dates
A job isn't just scheduled at the first branch - it needs capacity at every branch it will pass through. Before committing to a delivery date, check the load at cutting, edging, assembly, finishing, and dispatch. The branch with the least available capacity sets the true timeline, not the branch with the most.
Track where time is actually lost
In our operation, the biggest time losses weren't in production itself - they were in the gaps between branches. Jobs sitting on pallets waiting for transport. Panels at Branch B waiting because nobody knew they'd arrived. Hardware at Branch C but not checked in. Measure the time jobs spend waiting between stages, not just the time spent actively working on them. That's where the real improvements hide.
Start with visibility before optimisation
It's tempting to jump straight to advanced scheduling algorithms and capacity optimisation. Don't. The first and most impactful step is simply making the current state visible to everyone. Once all five branches can see the same real-time picture of every job, your managers will naturally start making better scheduling decisions. Optimisation comes later, after the basics are solid. If you're running a single-site operation and want to build these foundations first, our guide on production scheduling for small workshops covers the single-site fundamentals.
Multi-branch production scheduling is fundamentally a communication problem, not a computation problem. The workshops that get it right aren't the ones with the most sophisticated algorithms - they're the ones where every person, at every branch, can see exactly where every job is and what needs to happen next. As Make UK has consistently highlighted, UK manufacturers face growing pressure to digitise operations across multiple sites. We built CutFlow because we needed that visibility ourselves, and because the tools that existed at the time were either designed for single-site operations or for enterprise factories with dedicated planning departments. If your reality is somewhere in between - multiple locations, bespoke work, and a team that needs answers fast - the principles in this article are the place to start.