The Job Closed On Time. Nobody Can Say Why It Lost Money
The quarter closes, and one job stands out: it shipped on schedule, the customer never complained, and it still came in soft on margin. You pull the traveler. You pull the time clock report. All you have is a start punch and a stop punch against the job number — twenty-two hours, badge in, badge out. Was that twenty-two hours of setup on a fixture that fought back? Was it run time on a program that cycled slower than quoted? Was the operator waiting forty minutes for material, or reworking a part that failed first-article? The job-level punch can't tell you, because it was never built to.
This is the quiet failure point in a lot of shops running QuickBooks, a spreadsheet, and a paper traveler: the clock-in step exists, but it's attached to the wrong unit of work. A job is not one thing that happens — it's a sequence of operations, each with its own standard, its own machine, its own way to go over. Clocking a whole job as a block gives you total labor hours and nothing else. It answers "how much did this cost" only after the fact, and it never answers "where did it go wrong."
Operation-level clock-in is the fix, and it's a smaller change than it sounds like. This article walks through what it actually captures, why the reason codes matter as much as the timestamps, and how that data becomes the actual-vs-quoted comparison your costing depends on.
Why Clocking Into "the Job" Isn't Enough
A job number is an accounting container. It's useful for invoicing, useful for tracking a customer's order, and nearly useless for diagnosing where labor went. A typical job in CNC machining, sheet metal fabrication, or welding runs through multiple distinct operations — programming or setup, first-piece inspection, run, deburr, secondary finishing, final inspection — each carried on the routing with its own quoted standard time.
When the shop floor clocks in at the job level, all of that structure collapses into one number. Ten hours against Job 4471 could be nine hours of clean run time and one hour of setup, or it could be four hours of setup because the fixture needed rework and six hours of run because the material was harder than expected. Both scenarios post the same total. Only one of them is a quoting problem, and only one of them is a scheduling problem, and you can't tell which without operation-level detail.
This is also why "just add up the punches" spreadsheets don't solve it. A spreadsheet can hold job-level totals just fine. What it can't easily hold — and what almost never survives contact with a busy floor — is a live, per-operation breakdown that ties each punch to a specific line on the routing. That's a data capture problem, not a math problem, and it has to be solved at the clock-in step or it's lost for good.
What Operation-Level Clock-In Actually Captures
Operation-level clock-in means the operator selects — or scans — not just the job, but the specific operation on that job's routing before the clock starts running. In practice this happens at a shop floor time clock kiosk mounted at the work center, or from a mobile or tablet view at the machine, and it takes the same few seconds as a job-only punch. The difference is what gets recorded on the back end: a timestamped entry tied to job, part, operation number, and work center, not just job.
That single structural change is what lets you track labor hours by job in manufacturing at the resolution that actually matches how the routing was built. Every operation on the traveler — deburr, weld-out, anodize, final inspection — becomes its own bucket of actual time, sitting right next to its own quoted standard. Roll those operation-level actuals up and you get the job total for invoicing and payroll. Keep them separate and you get a diagnostic tool. Job-level clock-in only gives you the first.
Setup vs. Run vs. Waiting vs. Rework: The Reason Codes That Matter
Operation-level clock-in solves which operation. It doesn't automatically solve why an operation ran long — that's a second layer, and it's the one most shops skip. The fix is a small set of downtime reason codes captured at the same punch: setup, run, waiting, and rework.
- Setup is time spent getting the work center ready — fixturing, tooling, program load, first-piece approval — before production run starts.
- Run is the actual production time against the piece count, the number that should track closest to the routing's quoted cycle time.
- Waiting is non-value time the operator didn't create — no material, no fixture, no prior operation complete — and it's the code that should worry an owner most, because it's pure schedule loss with no offsetting output.
- Rework is time spent correcting a part that didn't pass inspection the first time, and logging it against the operation that caused it is what turns a vague "we have a scrap problem" into a specific, addressable defect.
Without reason codes, a long punch against an operation is just a long punch — you know it ran over, not why. With them, setup vs. run time tracking becomes routine, and a pattern of setup overruns on one work center, or waiting time clustered around one supplier's material, becomes visible in weeks instead of getting buried until year-end.
From Punches to Actual-vs-Quoted
The whole point of operation-level clock-in is what it feeds downstream: a direct, operation-by-operation comparison of actual time against the quoted standard on the routing. That comparison is the mechanism behind actual-vs-quoted reporting, and it only works if the actual side of the ledger was captured at the same granularity as the quote.
Consider a simplified, illustrative example. A routing quotes 0.5 hours setup and 2.0 hours run for a deburr-and-inspect operation on a batch of brackets. If the shop only captures job-level time, the closest it can do is note that the whole job — six operations — ran two hours over its total quote, with no way to isolate which operation caused it. If the shop captures operation-level punches with reason codes, it can see directly that this operation ran 0.5 hours setup (on quote) and 3.1 hours run (1.1 hours over), and that the overage was logged under the run code, not waiting or rework — pointing straight at cycle time, not scheduling or quality. That's the difference between a costing system that tells you that you lost margin and one that tells you where.
This is also the data that makes manual time entry — for the shops or shifts where a kiosk isn't practical — worth trusting. A supervisor approving a manually entered punch against a specific operation, with a reason code attached, is approving something checkable against the routing standard. A supervisor approving a job-level total is approving a number with no way to audit it.
The Kiosk and Mobile Reality on the Floor
None of this works if it adds friction the operator resents. The operational bar for clock-in is low: select job, select operation, select reason code if applicable, punch. A kiosk at the work center or a phone/tablet view at the machine should take roughly the same few seconds a job-only punch takes today — the difference is in what's captured, not in how long it takes to capture it.
That matters because adoption on the floor is the real constraint, not the software. An operation-level system that requires operators to navigate three menus per punch will get shortcuts and skipped punches within a week. One that mirrors the existing habit — badge in, pick the job, now also pick the operation — tends to hold up because it doesn't ask for more attention than the floor already gives to clocking in.
What This Looks Like in a Working System
WorkTickets builds this in as the default unit of clock-in, not an optional add-on. The routing for each part number defines the operation sequence and the standard time per operation; the traveler — printed with a barcode or QR code, or viewed digitally on a tablet — carries that sequence onto the floor; and the kiosk or mobile clock-in punches against the specific operation on that traveler, with setup, run, waiting, and rework reason codes built into the punch itself. Supervisors approve manual entries the same way, against the same operation-level structure.
From there, the actual-vs-quoted comparison and the live WIP queue view are built directly on operation-level punches — there's no separate reconciliation step to make job-level totals retroactively meaningful. Every tier includes actual-vs-quoted labor per operation and per job; the Professional and Business tiers add burden-rate configuration and a job-level profitability summary that rolls the operation-level actuals into a full cost picture.
If your shop is still clocking whole jobs and reconstructing "what happened" from memory after the fact, the fix isn't a bigger spreadsheet — it's capturing the right unit of data at the point where the operator is already standing. A broader guide to execution and costing walks through how routing, traveler, clock-in, and costing connect end to end; the Operator Time-Card & Missed-Punch Reconciliation Workbook is a practical starting point if you want to see what clean operation-level time data should look like before you change any software.
WorkTickets runs on a 14-day trial across all four self-serve tiers — Essentials, Professional, and Business — so you can route a handful of real jobs and watch the operation-level punches turn into an actual-vs-quoted report before deciding anything. See it on your own jobs.
