The phone call you can't answer cleanly
A customer calls at 2:40 on a Thursday and asks where their job is. You know it's out there somewhere — probably past first-op, maybe waiting on deburr, maybe already at inspection — but "probably" isn't an answer you want to give someone who's asking because their own customer is asking them. So you put them on hold, walk the floor, find the traveler clipped to the fixture, read the last stamp, and walk back to the phone four minutes later with an answer that's now four minutes stale. Multiply that by every job on the floor and every customer who calls, and you've got a supervisor spending a meaningful chunk of the day acting as a human status API — one query at a time, one physical walk at a time.
The frustrating part is that the information usually already exists somewhere in the shop. It's on the traveler. It's in whoever clocked in last. It's in the operator's head. It just isn't organized in a form anyone can hand to a customer without translation, and it definitely isn't organized in a form a customer could look up themselves. That gap — between "we technically know" and "we can say it cleanly" — is what erodes trust on jobs that are otherwise running fine.
This article walks through how to turn internal work-in-progress visibility into a status answer you can give a customer confidently, without exposing your whole floor or promising a live portal you haven't built.
Why "we'll check and call you back" costs more than it looks like
A shop that answers job-status questions with a floor walk isn't failing at manufacturing — it's failing at translation. The routing, the traveler, and the clock-ins already capture what operation a job is on. What's missing is a layer that turns "operation 40, clocked in at 9:12" into "your part finished machining this morning, it's in deburr now, on track to ship Friday."
Customers read the gap between those two sentences as a signal about how tightly you run the shop, even when the job itself is on schedule. A vague or delayed answer suggests nobody's watching it. A precise, fast one suggests the opposite — even if the underlying job took exactly as long either way. Status communication is a trust mechanism that sits on top of a work-in-progress system, not a replacement for one, and it's worth building deliberately rather than leaving to whoever picks up the phone.
What a customer actually needs to hear
Before building any kind of status view, it helps to separate what the shop needs to run the floor from what the customer needs to hear about their job. Internally, a work-in-progress dashboard is built around a work-center queue: which jobs are sitting at which machine, in what order, and how long they've been waiting. That view is dense on purpose — it's meant for a supervisor making sequencing decisions, not for a customer.
A customer-facing status answer strips almost all of that away. In practice, it's four things:
- Part number / job number — so both sides are talking about the same job.
- Current operation, in plain language — "in final inspection," not "op 60."
- What's left before it ships — one or two remaining steps, not the full router.
- Expected ship date — the number they actually called for.
Everything else — burden rates, who ran which operation, actual-versus-quoted labor, scrap notes — stays internal. That distinction matters enough that it's worth designing on purpose rather than discovering by accident, because the same traveler and clock-in data that produces a clean customer answer also carries information a customer has no reason to see.
Building the internal answer first: the "where is my job" search
None of this works without a reliable internal answer first. If a supervisor still has to walk the floor to find out where a job sits, there's nothing to translate for the customer. The starting point is a searchable job-status lookup — by job number, part number, or customer name — that returns current work center and last-logged operation instantly, the same query pattern covered in where is my job on the shop floor.
That lookup is only as current as the clock-in data feeding it. A traveler that gets updated once a shift, on a clipboard, at the end of the day, gives you a status answer that's already stale by the time anyone asks. A traveler paired with one-tap clock-in and clock-out at each work center — logged as operators actually move jobs, not reconstructed later — gives you a status that reflects the floor as it stood a few minutes ago, not this morning. Getting that internal answer right is the actual foundation of tracking job status for customers in manufacturing; the customer-facing version is just a filtered view of it.
Turning the internal view into a customer-safe summary
Once the internal lookup is solid, the customer-facing layer is mostly a matter of subtraction, not addition. A few practical approaches, roughly in order of how much infrastructure they require:
Manual lookup, scripted answer. A supervisor or CSR runs the internal "where is my job" search, reads off the current operation and expected next step, and relays it verbally or by email using a consistent phrase pattern ("currently in [operation], expected to ship [date]"). No new tooling — just a faster, more reliable internal answer feeding the same phone call.
Scheduled status email or PDF. For customers with recurring jobs or multiple open orders, a periodic export — pulled from the same WIP tracking view — lists each open job, its current operation, and expected ship date, sent on a set cadence (daily or twice a week) rather than on demand.
Self-serve portal. The end state some shops eventually want is a customer login where status updates automatically as operations complete. That's a meaningfully larger build — authentication, per-customer data scoping, a public-facing interface — and most job shops in the 5–50 employee range aren't going to stand one up as their first move. It's worth naming as the eventual destination without pretending it's a weekend project.
The point of laying these out in order is that a shop doesn't need to jump straight to a portal to get the trust benefit. A supervisor who can answer "operation 40, deburr next, ships Friday" in fifteen seconds instead of walking the floor for four minutes has already fixed the part of the problem that actually reaches the customer.
What to leave off the customer view — and why it matters
The instinct once a shop has good internal visibility is to just expose more of it. Resist that. A customer-facing status view should never carry burden rates, labor actuals, scrap or rework notes, or anything that reveals how a job is priced or how efficiently it ran. None of that answers "where's my job" — it just creates new questions, or in a worst case, a negotiating point at the next quote. The internal work-center queue view is deliberately dense; the customer view is deliberately thin. Keeping that boundary clean is as much a part of the design as getting the status data itself.
Where this fits into the bigger execution picture
Tracking job status for customers isn't a standalone feature — it's the visible tip of the same routing, traveler, and clock-in structure that a shop needs for job costing, scrap tracking, and actual-versus-quoted comparisons. If your shop is still assembling that foundation, the execution and costing guide for small job shops walks through how routing, travelers, and clock-in data connect to everything downstream, including customer-facing status.
WorkTickets builds the internal side of this directly: a live work-center queue that answers "where is job X" by job, part, or customer in seconds, fed by one-tap clock-in and clock-out at each operation rather than end-of-shift reconstruction. That queue view is the same one available as a standalone reference in the Work-Center WIP Board & Queue Tracker if you want a lighter starting point before adopting the full workflow.
If your team is still translating floor walks into phone calls, a 14-day trial is a reasonable way to see whether a live queue view shortens that gap — routing, traveler, and clock-in setup included at every tier.
