When a Five-Piece Order Quietly Loses Money
A customer needs five prototype brackets before committing to a 200-piece production order. You quote the small batch at roughly the same per-piece rate as the big one — it's the same part, same operation, why complicate it? The job runs, ships, and gets invoiced. Weeks later, the quarter closes and that bracket job shows a loss nobody can explain from the paperwork. The machine ran the exact operation it was supposed to. Nothing on the shop floor looked wrong.
What actually happened is invisible on a traveler that records only one number per operation: "operation time." That single bucket blends two things that behave completely differently as quantity changes — the time to get the machine ready, and the time to make each piece once it's ready. Blend them, and a five-piece order looks like it took forever per unit; unblend them, and the truth is that setup ate the job, not the machining itself. This article walks through why setup and run time have to be tracked as two separate numbers, and how that split changes what you quote and what you learn from a job after it ships.
What Setup Time and Run Time Actually Measure
Setup time is the cost of getting a work center ready to make a part: fixturing, tool changes, program loads, offsets, first-article checks. It happens once per job, independent of how many pieces you're making. Run time is the cost of making one piece once the machine is ready — it happens once per unit, and it scales directly with quantity.
A routing that lists these as two separate standard times per operation is doing something a single "operation time" figure can't: it's telling you how a job's total time behaves as batch size changes. Setup is fixed. Run is variable. Any costing method that treats them as one number is implicitly assuming they behave the same way — and they don't.
Why Lumping Them Together Hides the Real Problem
Here's the mechanism that makes the difference matter. If a work center logs one blended hour for an operation that included 45 minutes of setup and 15 minutes of running five pieces, a shop that divides "operation time" evenly across the pieces produced will conclude that each of those five pieces took 12 minutes. Run the same operation again for 200 pieces with the same 45-minute setup, and the blended-time method will show each piece taking closer to 3–4 minutes.
Neither number is the truth. The truth is that setup was 45 minutes regardless of quantity, and run time was somewhere around 3 minutes per piece both times. Blending the two doesn't average out the noise — it manufactures a false pattern that makes small batches look catastrophically slower than they are, and large batches look artificially fast. Quote off the blended small-batch number and you'll overprice repeat production. Quote off the blended large-batch number and you'll underprice every prototype and short run that walks in the door — which is often exactly the work a small shop can't afford to lose money on, because it's frequently how new customers test a shop before committing to volume.
Setup vs Run Time Tracking in Practice: A Worked Example
Take an illustrative routing for a single bracket operation: a standard setup of 45 minutes and a standard run time of 8 minutes per piece. This is a worked example for a representative shop, not a sourced benchmark — but the arithmetic holds regardless of the exact minutes.
- Batch of 5: 45 minutes setup + (5 × 8 minutes run) = 85 total minutes ÷ 5 pieces = 17 minutes per piece.
- Batch of 50: 45 minutes setup + (50 × 8 minutes run) = 445 total minutes ÷ 50 pieces = 8.9 minutes per piece.
- Batch of 200: 45 minutes setup + (200 × 8 minutes run) = 1,645 total minutes ÷ 200 pieces = 8.2 minutes per piece.
The per-piece cost converges toward the run-time standard as quantity grows, and setup dominates as quantity shrinks. A quote built on a single blended per-piece rate — say, the 8.9-minute figure from the 50-piece batch — will underprice the five-piece prototype run by nearly half its true time and overprice the 200-piece production run. Tracking setup vs run time separately is what lets a quote scale correctly instead of guessing at a single number and hoping batch sizes don't drift too far from whatever job the estimate was originally built on.
How the Split Separates Signal From Noise in Actual-vs-Quoted
The same logic applies after the job runs, not just before it's quoted. When a clock-in records setup and run as separate entries against separate standard times, an actual-vs-quoted comparison can tell you which half of the operation drifted. If setup overran, the cause is usually a missing fixture, a bad offset, or a program that needed rework before it would cut — a one-time, job-specific problem. If run time overran, the cause is more likely a feed-and-speed issue, harder-than-expected material, or a standard that was never realistic to begin with — a recurring problem that will show up on every future job using that operation.
Collapse the two into one number and you lose that diagnostic entirely. You'll know the job ran long. You won't know why, and you won't know whether to fix a fixture or fix a standard.
Downtime Reason Codes and the Categories Around Setup and Run
Setup and run aren't the only two states an operation moves through. Waiting time — for material, for an inspector, for a machine to free up — inflates the total time a job sits at a work center without belonging to either setup or run. Rework is its own category, and it needs to be tied back to the operation that caused the defect, not folded into whatever operation happened to be running when the scrap was caught.
WorkTickets' clock-in and clock-out flow (kiosk or mobile) captures downtime against reason codes for exactly this reason — setup, run, waiting, and rework are logged as distinct entries against the job and operation, not blended into a single time stamp. That's what makes the downtime reason codes on a traveler useful for something more than a paper trail: they're the raw material for figuring out which category of time is actually driving a job's cost.
Building the Split Into Your Quoting and Costing
Once setup and run are tracked as separate standard times on the routing and separate actuals at the work center, the rest of the costing chain follows naturally. A work center's burden rate applies to both setup and run minutes, but knowing which bucket the minutes came from tells you whether a job's cost problem is structural (a batch too small to absorb its setup) or operational (a run rate that's drifting from standard). That distinction feeds directly into per-operation job costing and into how setup and run time get estimated on the next quote for a similar part.
If your shop is still recording one blended number per operation, the fastest way to see the effect is on your own recent jobs, not a hypothetical one. Our downtime reason-code analysis workbook is built to walk through exactly this split against a handful of real jobs — set aside the ones with wide swings between quoted and actual time, split their setup and run time apart, and see which bucket was actually responsible. For shops ready to track this at the traveler level going forward, WorkTickets logs setup, run, waiting, and rework as separate clock events from the first job in a 14-day trial, with actual-vs-quoted comparisons available at every tier. For the broader picture of how this fits into a shop's execution and costing setup end to end, the execution and costing guide is the place to start.
