Why Rejection Tracking on the Shop Floor Never Sticks

Every plant already has a rejection register. It sits on a clipboard near the QC table or lives in a shared spreadsheet, and at the end of the shift, someone fills in a number. Ask the plant head what last month's rejection rate was and they will quote it without hesitation. Ask them which machine, which shift and which defect drove it, and the conversation slows down.

That gap is the actual problem. The register exists. The number gets reported. But the number is a reconstruction, not a record, and reconstructions do not hold up when you try to act on them.

Why does rejection tracking on the shop floor stop working after a few weeks?

It stops working because the person writing the number down did not see the defect happen. A piece gets rejected on the line at 11 a.m. The operator sets it aside, or drops it in a scrap bin, and moves on. Nobody notes the machine, the batch or the reason at that moment. At 6 p.m., the shift supervisor walks past the scrap bin, counts what is in it, and writes a number in the register against "quality issue" or a defect code chosen from memory.

Within a few weeks, two things happen. First, the count drifts, because scrap bins get emptied mid-shift, pieces get reused or reworked before anyone counts them, and the end-of-shift number becomes a rough estimate dressed up as data. Second, the register stops being useful for the one thing it was meant to do: telling the owner where the money is leaking. A rejection rate with no machine, no shift and no verified defect code attached is a monthly average, not a management tool.

This is the same failure pattern behind most shop-floor logs kept manually, including downtime tracking: the person recording the event has no stake in its accuracy, and the person who does have a stake never sees it until it is too late to act.

Who should record a rejection, and when?

The person who rejects the piece should record it, at the point it happens, not the supervisor reconstructing it hours later.

This means the operator, or the QC inspector doing in-process checks, logs the rejection the moment it is set aside: which machine, which batch or job number, what shift, what defect, and how many pieces. This should take under thirty seconds and use a fixed list of defect codes, not free text. Free text ("issue with finish") gets interpreted differently by every person who reads it later. A fixed code (e.g., "surface pitting," "dimension out of tolerance," "burr") means the same thing every time, and it means the data can be grouped and trended without someone manually cleaning it up first.

Deciding the defect code list is not an IT decision. It is a quality head decision, made once, reviewed every few months as new failure modes show up, and it should have no more than fifteen to twenty codes. More than that, and operators start picking the nearest one instead of the right one, which defeats the purpose.

What should happen to the rejection data within 24 hours?

It needs to reach whoever can act on the cause before the next shift repeats the same defect, not sit in a register until the weekly or monthly review.

Here is the sequence that actually breaks a repeating defect: a rejection is logged against Machine 2, night shift, defect code "dimension out of tolerance." If that entry sits in a register until the following week's quality meeting, the same machine runs the same defect for six more shifts before anyone with the authority to adjust the die or recalibrate the machine even sees it. The cost of that gap is not the paperwork. It is six shifts of scrap, at cost, absorbed silently.

The fix is a same-day rule, not a better form. Set a threshold: if a single defect code crosses a set percentage on a machine within a shift, the shift supervisor is notified before the shift changes, not the next morning. The plant head reviews the trend by machine weekly, not monthly, because monthly review catches a pattern after it has already cost six weeks of scrap.

If the answer needs a phone call, it's not a system.

How to track rejection rate on shop floor, step by step

Track it by machine, shift and defect code, not as a single plant-wide percentage, using the formula rejected quantity divided by total quantity produced, multiplied by 100.

A single plant-wide rejection number hides exactly the information an owner needs. Take a press shop running three machines across two shifts. The plant-wide rejection rate reads 3%, which looks manageable. Broken down by machine and shift, two machines run under 1%, and one machine on the night shift runs 9%. The plant-wide average hid a single, fixable problem: one machine, one shift, likely one die, one calibration issue or one under-trained operator. First pass yield tracking, discussed in iFactory's guide to FPY, works on the same principle: yield measured at the level where the defect actually happens tells you far more than yield measured at the end of the line.

The mechanics, once ownership is decided:

1. Fix the defect code list with the quality head. Keep it under twenty codes.
2. The operator or inspector logs machine, shift, batch, defect code and quantity at the point of rejection.
3. Rejections are tallied by machine and shift, not just by day, and reviewed against a threshold before shift change.
4. The quality head reviews the trend by machine weekly. The plant head reviews the summary, by machine, monthly.
5. Recurring codes on the same machine trigger a root-cause check, not another log entry.

A checklist for yield tracking covers similar ground on the data side. The gap most plants have is not the checklist. It is step one and step two above: deciding who logs what, at the moment it happens.

Comparing the two ways rejection actually gets tracked

Aspect	End-of-Shift Register	Point-of-Failure Logging
Recorded by	Supervisor, from memory	Operator or inspector, at the machine
Recorded when	End of shift	Within minutes of the rejection
Defect description	Generic, e.g. "quality issue"	Specific, fixed defect code
Machine and shift traceability	Rare	Built into every entry
Time to correction	Days to weeks	Same shift or next shift
Trust in the number	Disputed at month-end review	Used to make real decisions

What does the rejection number actually tell the owner?

It tells you where material and rework cost is being created right now, so the decision is which machine, shift or process to fix first, not what the overall percentage was last month.

Once rejection is tracked by machine and shift, patterns show up that a plant-wide average never reveals. A defect that only appears on the night shift usually points to supervision or fatigue, not the machine. A defect that follows one machine across shifts points to calibration or tooling. A defect that spikes after a raw material batch change points upstream, to incoming inspection, not the shop floor at all. Each of these is a different decision, made by a different person: the shift supervisor, the maintenance head, or whoever approves incoming material. A single rejection percentage cannot tell you which of these three conversations to have. Rejection tracked by machine, shift and defect code can.

This is also where the temptation to buy a quality-tracking module too early causes damage. Do not automate a bad process. If defect codes are inconsistent, if nobody has decided who logs at the point of failure, and if the data still sits unreviewed for a week, digitising the register only makes the bad number easier to distribute. Software should come after the who-logs-what-when decision is made and working on paper or in a spreadsheet, not before it. That sequencing, understanding how the rejection actually gets created and acted on before building anything, is the starting point of most of the digital transformation work we do with manufacturing clients.

For more on getting shop floor visibility right before adding software, see the Manufacturing Operations hub.

What to do this week

Three decisions, made by name, not by policy document:

• The quality head fixes the defect code list, under twenty codes, this week.
• The plant head decides the threshold that triggers a same-shift alert to the supervisor, and who receives it.
• Every operator or inspector starts logging at the point of rejection, on paper if nothing else exists yet, with machine, shift, batch, defect code and quantity captured every time.

Run it for four weeks before touching a spreadsheet template or software. If the discipline of logging at the point of failure does not hold on paper, it will not hold in a system either.