The two biggest recoverable costs on a high-production floor are unplanned downtime and product giveaway. Both are already being paid for. This is the case for getting the margin back, and the loop that does it, written for the person who owns the P&L.
Read this first · Who this is for
This is a decision brief for a CEO, COO, or owner, not a maintenance guide. It is about two line items that never appear as their own line item: unplanned downtime and product giveaway. They are the two largest costs on most floors that you can recover without buying a machine, hiring a shift, or raising a price. And they are recoverable because they are not really equipment problems. They are information problems.
There are no invented numbers on this page. We do not quote an industry average for what downtime costs or how much giveaway hides in a case, because an average across other people's plants tells you nothing about the money on your floor. Every dollar figure here is one you measure yourself, with the calculators linked below, on your own rates and your own volume.
The two costs, and why the board should care
At low volume these two costs are a rounding error. At high volume they compound, because both scale with every unit and every hour you run. A stop is not one lost hour, it is one lost hour times your contribution margin per hour, every time it happens, across every line, every shift, all year. Giveaway is not a few extra grams, it is a few extra grams times millions of units, given away free to whoever buys the case.
Cost 01 · Unplanned downtime
Capacity you paid for and did not sell
Every unplanned stop is throughput you were staffed and tooled to produce, gone. It does not show up as a bill. It shows up as a line that quietly runs below what it could, and as overtime and expedite freight to catch up.
Cost 02 · Product giveaway
Margin you are shipping for free
To stay above a label weight or a spec, lines run rich: overfill, overpack, over-target. Every gram above target is product you made, paid for, and gave away. At scale it is a permanent discount you never chose to offer.
The reason this belongs in a board conversation and not just a plant meeting is that both costs are structural. They do not respond to a memo or a stretch goal, because the people on the floor cannot fix what they cannot see in time to act. That is the actual problem, and it is the same problem twice.
Why these two costs hide
Ask why a high-production plant keeps paying for downtime and giveaway it clearly wants to eliminate, and you get two root causes. They are not effort or discipline. They are data latency and machine data that never leaves the machine.
Data latency: the numbers arrive after the money is already gone
On most floors, downtime is written on a paper log and keyed in later, and giveaway surfaces in a month-end yield reconciliation. By the time either number reaches someone who can act, the shift that produced it is over and the product has shipped. You cannot correct a run you only hear about at month end. Latency sets a hard ceiling on how proactive anyone can be, and it is why the same causes recur: nobody saw them while they were still happening.
No machine data: the line already knows, and tells no one
The equipment is not silent. Fillers, checkweighers, scales and PLCs already know their counts, their target drift, their faults and their cycle times. On most floors those numbers stop at the panel. An operator reads a checkweigher screen and nudges a setpoint by feel, but nothing central sees the trend, so overfill that creeps up over a run is invisible until the yield does not add up. Many controllers can already share this data over a standard connection like OPC UA, so the common case is not a plant that cannot measure. It is a plant whose measurements never leave the machine.
Put those two together and you get the trap: the floor is running blind on the two costs that matter most, and no amount of will fixes a visibility problem. The rest of this playbook is the loop that closes both gaps at once.
What the playbook covers
The full playbook is one operating loop in four steps. Two steps make downtime visible and coded the instant it happens. Two make giveaway visible on the line while the run is still going. Here are the section headings. The step-by-step under each is on the other side of the form below, or in your inbox.
Step 01
Capture downtime at the machine in seconds
Fixes: data latency on stops
Log a stop where it happens, in seconds, so the event exists to a system the moment it occurs instead of hours later on a clipboard.
Step 02
Code the causes while they are fresh
Fixes: causeless downtime
Attach a reason to each stop as it is logged, so a real Pareto builds itself and the recurring few causes become obvious and killable.
Step 03
Pull checkweigher and scale data live
Fixes: no machine data on giveaway
Read filler, scale and checkweigher data as it is produced, so overfill and target drift are visible during the run, not after it ships.
Step 04
Close the loop the same shift
Fixes: correction that comes too late
Route the live signal to the person who can act, so the run gets corrected during the shift that produced it, not reviewed after.
Put your own numbers on it first
Before you read the how, size the what. These calculators run on your rates and your volume, no email required, so you walk into the playbook knowing roughly what is on the table on your floor.
You have the case and the four section headings. Enter your work email and the full step-by-step opens right here on this page, and a copy goes to your inbox to hand to your ops lead.
How to capture a stop at the machine in seconds, and code the cause while it is fresh
How to pull checkweigher and scale data live so giveaway is visible during the run
How to close the loop the same shift, and where this sits in a Phase 1 rollout
Work email only. We use it to send the playbook and nothing else you did not ask for. Unsubscribe anytime.
Unlocked. The full step-by-step is open below, and a copy is on its way to your inbox. If you checked the box, a Harmony engineer will reach out to size the two costs with you.
Step 01 · Downtime
Capture the stop at the machine in seconds
The whole downtime problem starts here. If logging a stop is a chore done later, from memory, on paper, then most short stops never get logged at all and the ones that do are wrong on time and vague on cause. A stop that is not captured when it happens does not exist to any system, and you cannot manage what does not exist. The fix is to move capture to the moment and the place of the stop.
Put the capture point at the machine or line, not at a desk or a shared clipboard down the aisle.
Make logging a stop a few seconds of work, so an operator does it in the moment without leaving the task.
Capture the clock automatically. Let the system timestamp the stop and the restart so duration is not a guess.
Count the short stops, the micro-stops that never make it onto a paper log but add up to more lost time than the big failures.
What this changes
The moment a stop exists to a system as it happens, downtime stops being a monthly story and becomes a live number. That is the precondition for everything else: you cannot code a cause you never captured, and you cannot close a loop on a stop nobody logged. Size the prize first with the Downtime Cost Calculator.
Step 02 · Downtime
Code the cause while it is still fresh
Captured time with no cause is a pile of lost hours you cannot act on. The value is in the why, and the why is only accurate if it is recorded at the moment, by the person who was there, before the shift ends and the memory fades. Blank downtime tells you that you have a problem. Coded downtime tells you which one to fix first.
Offer a short shared list of reason codes, few enough that the right one is one tap, not a paragraph.
Attach the cause at the moment the stop is logged, not reconstructed days later in a review.
Let the causes aggregate into a Pareto on their own, so the recurring few rise to the top without anyone building a spreadsheet.
Point the next fix at the top of that list, the small number of causes doing most of the damage, and confirm it moved.
What this changes
A real, live Pareto turns downtime from a vague complaint into a prioritized worklist. Instead of arguing about impressions of what stops the line, the team works the few causes that actually cost the most, and can see whether the fix held. Rank your own causes with the Downtime Pareto Calculator.
Step 03 · Giveaway
Pull checkweigher and scale data live
Giveaway is downtime's quieter twin. It hides because the machine that measures it, the checkweigher, the scale, the filler, keeps its numbers to itself. An operator reads the screen and adjusts by feel to stay safely above the minimum, and safe means rich. Over a long run the target drifts up and nobody central sees it, so the overfill only surfaces when the month's yield does not reconcile, long after the product shipped. The signal you need already exists on the line. It just never leaves the machine.
Read filler, scale and checkweigher data as it is produced, over a standard connection like OPC UA where the equipment supports it.
Track the actual fill against target continuously, not as an end-of-run average that buries the drift.
Make target drift visible on the line while the run is going, so creeping overfill is caught in the run that produced it.
Keep the record connected to the lot, so a weight question can be answered from data rather than a binder.
What this changes
Once fill data is live, giveaway moves from an accounting surprise to a floor signal. The line can be held just above spec on purpose instead of by a cushion of free product, and the drift that used to hide in the monthly number is visible while it can still be corrected. Put dollars on your own overfill with the Material Waste Cost Calculator, and price the out-of-spec product with the Scrap and Rework Cost Calculator.
Note: connected, lot-level records also serve recall and audit exposure. Under the FDA Food Traceability Rule, covered firms must make required traceability records available within 24 hours and, during a public health event, in an electronic sortable spreadsheet. See 21 CFR 1.1455, paragraphs (c)(1) and (c)(3)(ii).
Step 04 · Both
Close the loop the same shift
Capture, coding and live fill data are only worth what someone does with them. If the signal lands in a report read next week, you have moved the latency, not removed it. The recovery happens when the loop closes inside the shift that produced the problem. Every hour between a signal and a correction is money you agreed to keep paying.
Route the live signal to the person who can act on it now, the operator, the line lead, the supervisor, not a distribution list.
Give the daily meeting this shift's numbers, not yesterday's, so decisions are made on what is happening.
Correct the run while it is still running: adjust the setpoint, kill the recurring stop, before the next hour repeats it.
Confirm the fix held on the same live data, so a closed loop stays closed instead of quietly reopening.
What this changes
This is where downtime hours and giveaway grams turn back into margin. Not because the plant tried harder, but because the gap between a problem and its correction collapsed from a month to a shift. Both costs are recoverable for exactly one reason: they were latency and blindness, and both are now closed.
Where this sits: it is Phase 1 work
Notice what this playbook did not require. No new AI model, no rip-and-replace of the ERP, no capital line. Every step is about getting a record captured at the station, getting machine data off the panel, and getting the number to a person in time to act. That is the foundation, and it is the same sequence every plant moves through, in the same order.
Phase 1
Lay the Data Foundation · Digitization
Downtime captured at the machine, causes coded, fill data pulled off the checkweigher and unified into one live layer. This playbook lives here.
Phase 2
Production & Operations Scale
Operations turn proactive: live machine data, the AI scheduling board, and maintenance that acts before the stop, not after.
Phase 3
AI-Native Operations
Agents act on the live layer: they flag drift, draft the report, and surface the recurring cause. Humans approve.
So the honest answer to whether you should spend on AI is: not first. The margin in downtime and giveaway is recovered in Phase 1, on data you already generate, and that same foundation is what any later AI would have to stand on anyway. If you want the whole picture priced on your own inputs, the ROI Calculators & Tools library does it, and the AI Readiness Checklist tells you where your floor actually starts.
Want the two costs sized on your own floor?
A Harmony pilot starts exactly here: forward-deployed engineers on-site, capturing downtime and pulling fill data alongside your team, Phase 1 first. It is a fixed offer, $15,000 to $20,000 one time, 4 to 6 weeks, with working software in your plant by the end of the pilot. See what the live layer looks like.
