Skip to content
WorkTickets.comTraveler & Job CostingWorkTickets.com home
Travelers & Routing

Building a Routing Per Part Number That You Reuse Every Job

Rovaryn Digital7 min read

The part that comes back every quarter, quoted from scratch again

A customer calls with a repeat order — the same bracket, the same 40-piece run they bought in March. The quote goes out fast because the price feels familiar. But when the job hits the floor, nobody pulls up how it actually ran last time. The setup gets re-figured by whoever's at the machine that day. The deburr step that took longer than expected in March gets forgotten until it takes longer than expected again in June. By the time the job closes, the actual hours look nothing like the quote, and there's no record of why — because nothing from the last time this part ran was ever captured as a standard to reuse.

This is the ordinary cost of not having a routing per part number. Not a dramatic failure — just quiet drift, job after job, on parts the shop has already made a dozen times. A routing built once per part number and reused every time that part repeats is how a shop stops re-deriving the same sequence from memory and starts comparing actual performance against a fixed standard. This article walks through how to build that routing, what belongs in it, and how it becomes the anchor for everything downstream — the traveler that goes to the floor and the job costing that tells you whether the part is still profitable.

What a routing actually is, and how it differs from a traveler

A routing is the reusable definition: for this part number, in this order, these are the operations. Saw, mill, deburr, inspect, ship — each with a work center, a standard setup time, and a standard run time (often per piece or per hundred pieces). It lives at the part-number level, independent of any single job.

A traveler is what gets generated from that routing for one specific job — the order-specific document, printed or digital, that carries the routing's operations along with the job number, quantity, due date, and space for the floor to log what actually happened at each step. The routing is the template; the traveler is the instance. If the distinction feels academic, it's worth reading through in more detail — see the breakdown of traveler vs. router in manufacturing for how the two terms get used (and confused) shop to shop.

The reason this distinction matters for a routing builder specifically: you build the routing once, per part number, and it should barely change between jobs. The traveler is disposable — one per job, then it's paperwork or a closed digital record. The routing is the asset you're actually protecting.

Building the routing once, per part number

The workflow is simple in principle and easy to get sloppy in practice:

  1. Pick the part number. Not the job number, not the customer PO — the part number, because that's what repeats.
  2. List the operations in sequence. Every step the part physically goes through, in order, from raw stock to shipping.
  3. Assign a work center to each operation. The specific machine, station, or department, not a generic "machining" bucket.
  4. Set a standard setup time and a standard run time per operation. These are your quoted baseline — the numbers a floor actual will later get compared against.
  5. Save it against the part number, not the job. The next time that part number comes up on a quote or a work order, the routing is already there.

Do this once per part number and the shop stops rebuilding the sequence from memory every time the part repeats. A routing builder that's organized around part number — rather than job number — is what makes step 5 possible at all. If the routing lived at the job level instead, you'd be rebuilding it every single time, which is exactly the problem this is meant to solve.

For shops standardizing this for the first time, a fixed routing sheet template or a part routing template built for a machine shop gives the columns and structure to start from rather than inventing a format operation by operation.

What goes in each operation line

A routing operation line earns its place by carrying enough detail that someone who's never touched the part before could run it correctly and someone reviewing the job afterward could tell whether it ran to standard. At minimum, each line needs:

  • Operation number and description — sequential, and specific enough to mean something on the floor ("deburr edges, break sharp corners" rather than just "finish").
  • Work center — the machine or station, so the traveler generated from this routing routes to a real queue.
  • Standard setup time — the time to get the machine or station ready, before the first good piece.
  • Standard run time — per piece or per batch, whichever matches how the shop actually quotes.
  • Tooling or fixture notes, where they change between operators.
  • Inspection or quality hold points, if the operation feeds a first-article or in-process check.

Here's a worked example, illustrative for a representative small shop, of what one operation line contributes to a job's standard cost: an operation with a 0.5-hour standard setup and a 0.1-hour standard run time per piece, on a 50-piece job, standards out to 0.5 + (0.1 × 50) = 5.5 standard hours for that operation. Multiply that by the work center's burden rate and you have the quoted cost for that step — before the job ever starts. That standard-hours figure is what an actual clock-in later gets measured against, operation by operation, not just at the job level.

Turning the routing into a traveler for the floor

Once the routing exists per part number, generating a traveler for a new job is mechanical rather than creative: pull the routing, attach the job number, quantity, due date, and customer, and the operation sequence, work centers, and standard times come along automatically. Whether that traveler prints as a paper document with a barcode or QR code, or opens as a digital traveler on a shop-floor tablet or mobile device, the underlying routing is what makes it consistent job after job — the same part number produces the same operation sequence every time, instead of a new interpretation from whoever's building the traveler that week.

This is also where downtime reason codes belong — setup, run, waiting, rework — captured against the operation as it actually happens on the floor, not reconstructed afterward from memory.

Why the routing becomes the anchor for job costing

Everything downstream depends on the routing holding a fixed standard. Without it, "actual vs. quoted" has nothing to be quoted against — there's no per-operation baseline, only a lump-sum guess from the original quote. With a routing in place, every clock-in against an operation has a standard time sitting next to it, and the gap between the two is where margin conversations start.

That gap is also where scrap and rework get traced to a cause instead of a mystery. If rework keeps showing up against the same operation on the same part number, that's a routing problem — a standard that's wrong, a tool that's worn, a step that's missing — not a random one-off. None of that traceability exists without the routing sitting underneath the job as a fixed reference point.

This is the mechanism a routing builder is actually for: not paperwork generation, but giving every job a standard to be measured against. For the fuller picture of how routing, traveler, clock-in, WIP, and actual-vs-quoted job costing fit together as one system, the execution-and-costing guide for small job shops walks through the whole sequence end to end.

Start with a template instead of a blank sheet

Most shops don't need to invent a routing format from scratch — they need a starting structure they can adapt to their own operations and work centers. The Traveler & Router Template Starter Pack is built around exactly this: reusable routing and traveler formats organized so a shop can build a routing once per part number and generate consistent travelers every time that part repeats, without reinventing the columns on job one.

Share this guideShare on LinkedInShare by email