Operations · Shop floor
Why panel shops outgrow spreadsheets (and what to use instead)
· 5 min read
Almost every panel shop runs on spreadsheets at some point. They're free, flexible and everyone can use them. For a handful of jobs a month, a shared sheet and a whiteboard genuinely work.
The trouble starts when volume climbs. The same flexibility that made spreadsheets easy at five jobs makes them unreliable at thirty. A cell gets overwritten, a copy goes stale on someone's drive, and nobody notices until a panel is built to the wrong revision.
Here are the signs a shop has outgrown the spreadsheet, why more tabs and macros won't rescue it, and what a replacement actually has to do.
The signs you've outgrown the spreadsheet
It rarely fails all at once. It erodes — a little more chasing each week, a few more surprises on the floor. Any one of these on its own is a nuisance; several together mean the sheet has stopped being a tool and started being a risk.
- Nobody can answer "where is job KT-2041 right now?" without walking the floor or ringing someone.
- Two people are editing different copies of the same BOM, and a panel gets built to the wrong revision.
- Material shortages surface mid-build, when the slot is already gone, instead of before release.
- The costing story for a won job disappears, so the next quote is a guess.
- Handover packs are assembled from scratch at the end, and the delivery date slips on paperwork, not engineering.
- One person is the only one who understands the sheet, and everything stalls when they're on leave.
Why spreadsheets can't fix this
A spreadsheet doesn't know what a panel build is. It can hold a list, but it can't enforce that everyone works from the current drawing revision, show readiness across every live job at once, or keep an audit trail of who signed off what and when. A build to BS EN IEC 61439 has stages, hold points and evidence; a grid of cells has none of that structure.
You can bolt on more tabs, colour-coding and macros, but you're rebuilding a manufacturing system one fragile formula at a time. There's no controlled revision, no permission model, no record of who changed what — so a stray edit is silent, and it breaks the moment the person who built it is off.
What good looks like
The goal isn't a fancier spreadsheet. It's one source of truth that understands the panel workflow from enquiry to handover — the same flow the shop already runs: Engineering, Kitting, Build, Test, QA, Dispatch.
Good means a supervisor can open one screen and see, per job, which stage it's at, whether it's materially ready, what's been signed off and what's still open. It means the current drawing and BOM revision are the ones on the floor, not a copy from three weeks ago. And it means the handover pack builds itself as the work happens, so the last day of a job is a check, not a scramble.
What a replacement has to do
Judge any tool against the real work of a build, not a feature list. A replacement earns its place if it does the following.
- Model real build stages, so percent-complete is something you can trust rather than a Monday-meeting estimate.
- Tie one current BOM revision to each job, and surface material shortages before build release, not mid-build.
- Enforce the current drawing revision on the floor, so nobody builds to a superseded sheet.
- Capture supervisor approvals and stage sign-offs against the job, with a trail of who signed and when.
- Raise and track NCRs against the panel, and show they were closed out before dispatch.
- Assemble the FAT and handover pack — test records, inspection evidence, as-built revisions — as the build progresses.
- Give managers one portfolio view of what's at risk and what's on time across every live job.
- Keep the estimate, BOM and actuals connected, so the costing on a won job is still there for the next quote.
A worked example
Take a shop building around 30 panels a month across a dozen live jobs, run on a shared sheet and an email trail. On paper it's coping. In practice, a job comes in for six identical distribution boards. Engineering revises the BOM to swap an obsolete incomer, saves it to their own drive, and updates the master sheet — but procurement had already ordered from a copy taken the day before. The old incomer arrives, the swap doesn't.
Nobody sees the mismatch until Build opens the kit and the device won't fit the arrangement. The panel is now half-built to a superseded revision, the correct part is a two-week lead item, and the slot on the floor is burned. Meanwhile the supervisor spends the standup ringing round for status because the sheet says "in progress" against every one of the six.
The same week reaches handover on a different job. The pack is built from scratch on the last afternoon — someone hunting for torque records, inspection notes and the FAT sign-off across job bags and inboxes. The panels are finished and tested. The delivery still slips two days, on paperwork.
With a system that ties one BOM revision to the job, flags the shortage before release, and collects evidence as the work is done, none of that is heroics. The wrong-revision order never leaves procurement, the shortage is visible before Build starts, and the handover pack is already assembled. The delay that cost two weeks and a floor slot simply doesn't happen.
Adopting it without ripping up how you work
The fear with any new system is a painful migration. The right approach configures the software around your existing stages, users and approvals — not the other way around — and supports your first live projects on the floor rather than forcing a new process on day one.