The due date that broke on a station nobody was watching
The job was on schedule for three weeks. Then it wasn't. The part had moved through saw and mill without incident, but when the supervisor went looking for it on the promised ship date, it was sitting at deburr — not being worked, just sitting, behind four other jobs that had arrived first. Nobody had flagged it because nobody was tracking how many jobs were queued at deburr versus how many were actually being touched. The traveler showed operations completed and operations remaining. It didn't show that six jobs were stacked in front of this one at a station with one person running it.
This is the failure mode that spreadsheets and paper travelers can't catch, because they track a job's position in its own sequence but not a job's position in the line at a station. Work center queue tracking closes that gap. It answers a narrower, more useful question than "where is the job": how many jobs are sitting at each station right now, how many of those are actually in progress versus waiting, and how long has the oldest one been waiting. This article walks through how to build that view, whether the tool is a whiteboard or software, and what it changes about how a shop catches a bottleneck before it costs a due date.
Waiting versus in-progress: the distinction that matters
Most WIP conversations collapse everything at a station into one bucket — "there's a pile of stuff at deburr." That bucket hides the actual signal. A queue of five jobs where four are waiting and one is running is a very different situation from a queue of five jobs where the operator is actively cycling through them at a normal pace. The first is a bottleneck forming. The second might just be normal staging.
Work center queue tracking separates the two states explicitly:
- Waiting — the job has arrived at the station (or is ready to, per its routing) but no operator has clocked in against it yet.
- In-progress — an operator is actively clocked in on that operation, whether in setup or run.
Distinguishing these two states is what turns a pile of parts into a diagnosis. A job that's been in the waiting state for six hours at a station that normally turns jobs in ninety minutes is a specific, actionable fact. A job that's been in-progress for six hours because the operation genuinely takes that long is a different fact entirely — and conflating the two is how a shop misses the bottleneck until it's already blown the date.
How the tracking actually works
The mechanics are simpler than they sound, and they map directly onto the same data a shop should already be collecting for job costing: routing, clock events, and operation status.
- The routing defines the sequence of work centers a job passes through. Each operation on the router names a work center — saw, mill, deburr, inspection, whatever applies — and a standard time.
- Arrival at a station is logged, not assumed. A job doesn't just "move" from mill to deburr in the abstract; a specific event marks it as arrived and ready at deburr, even before anyone starts running it.
- A clock-in event flips the state from waiting to in-progress. This is the same clock event used for labor tracking and actual-vs-quoted comparison — it isn't a separate system, it's a second read on data already being captured.
- Downtime reason codes explain why a job sits. Waiting isn't always a bottleneck; sometimes it's a legitimate hold for material, tooling, or a quality signoff. Tagging the wait with a reason (setup, run, waiting, rework) turns a queue count into a queue explanation.
- The queue view rolls all of this up by station, not by job — which is the pivot most shops are missing. Job-centric tracking answers "where is job 4471." Work-center-centric tracking answers "what's stacking up at deburr this week," which is the earlier warning.
That last point is worth dwelling on. A work in progress dashboard built job-by-job is good for answering a customer's phone call. A dashboard built work-center-by-work-center is good for catching a problem before the customer calls. Both views matter; most shops running on paper only have the first.
Reading the board: catching a bottleneck before it blows a date
Once waiting and in-progress are tracked separately per station, a few patterns become visible that were invisible before:
- Queue depth creeping up at one station over several days is the earliest sign of a capacity mismatch — more work arriving at that station than it can clear, day over day. This is the pattern behind most job shop bottleneck identification: the bottleneck rarely announces itself with a single blown date. It shows up first as a slowly growing pile that everyone gets used to seeing.
- Age of the oldest waiting job matters more than the count. Five jobs that arrived an hour ago is normal staging. Two jobs that have been waiting three days is the one worth walking over to.
- A station that's frequently in the waiting state while others run may be understaffed relative to the routing load moving through it — a scheduling and staffing conversation, not a software problem, but one that's invisible without the data.
None of this requires predicting the future or running a finite-capacity model — that's a different discipline than what's being described here. It requires an accurate, current snapshot of what's queued where, refreshed as clock events happen, so a supervisor doing a floor walk can glance at the board and know which station to check first.
Building this without an ERP
A shop doesn't need a full manufacturing execution system to get a usable version of this. A whiteboard with a column per work center and a card per job, physically moved from a "waiting" zone to a "running" zone, works at small scale and costs nothing but discipline. The limitation is that it only reflects the floor at the moment someone looks at it, and it produces no history — no way to answer "how long has this station been backed up" after the fact.
That history is the piece that matters for where is my job conversations with a customer and for catching a slow bottleneck before it becomes a fast one. WorkTickets builds this queue view directly from the same clock-in/clock-out and downtime-reason data used for labor tracking and actual-vs-quoted comparison — the live WIP dashboard defaults to a work-center queue view rather than a job list, specifically so a supervisor sees station load first. It's part of the same discipline covered in the broader guide to execution and costing for small job shops: a shop doesn't need ERP-scale scheduling to get real visibility, it needs its existing routing and clock data organized around the right question.
Where queue tracking connects to job costing
Queue depth isn't just an operations metric — it's a cost signal. A job sitting in a waiting state at a bottleneck station is a job accumulating calendar days without accumulating labor hours, which distorts any simple "hours logged so far" view of job health. Once queue state is tracked alongside actual-vs-quoted labor, a shop can tell the difference between a job that's expensive because the work is hard and a job that's expensive because it sat behind three others waiting for a machine. That distinction is the difference between a quoting problem and a scheduling problem, and it only shows up once WIP tracking on the shop floor is granular enough to separate waiting time from run time at the station level, not just the job level.
If the current setup is a whiteboard or a stack of printed travelers with no queue history, the starting point is a simple template: a work-center board that separates waiting from in-progress and tracks how long the oldest job in each column has been sitting. The Work-Center WIP Board & Queue Tracker is built for exactly that — a downloadable starting point for a shop that wants the discipline before deciding whether to move it into software. WorkTickets exists as the next step after that: the only standalone, SaaS-native execution-and-costing layer at this price point, with a deliberately fenced scope that sits below full ERP, built around the same routing-to-clock-event data this article describes. The 14-day trial is the fastest way to see the queue view running against a shop's own routings rather than a template.
