A Customer Asked for Genealogy: How to Answer Without Losing a Week
It usually starts as a one-line email. Your customer's supplier quality engineer writes: "Please provide full lot genealogy for PO-1234 by Friday." No attachment. No template. Just that, and a signature from someone you have never met. If your production records live on paper travelers, an ERP that knows orders but not the floor, and a few spreadsheets with strong opinions, that sentence just bought you a very long week. Here is how to read the request, how the manual answer actually gets assembled, and what a complete genealogy pack contains so you can check your own readiness before the next email arrives.
What the Customer Is Actually Asking For
"Full lot genealogy" sounds vague, but the request decomposes into four concrete questions about one purchase order:
- Which input lots went in? Every raw material lot, roll, drum, or intermediate batch consumed by every work order under the PO — resin lots, masterbatch lots, label rolls, adhesive batches.
- Who and what touched them? For each production step: which station, which machine, which operator, with start and end times. The customer wants to know whether suspect parts can be isolated to one shift or one cavity, or whether the exposure is plant-wide.
- Which output lots came out? The finished-goods lot numbers, linked parent-to-child to the inputs, including rework loops — reworked quantity must trace back to its original lot, not start a fresh lineage.
- Where did they go? Which shipment carried which output lot, on which date, to which of their receiving sites.
Timestamps are not decoration. An SQE reading your pack is checking whether the record was written when events happened or reconstructed after the fact. A genealogy with believable times survives scrutiny; one where every event lands neatly on shift boundaries gets a follow-up audit.
The Manual Assembly Path, and Where It Breaks
In a factory without a MES, the fragments of the answer live in five places. Receiving logs (paper or a simple spreadsheet) hold input lot numbers. Paper travelers ride with each work order and accumulate operator initials and times, in handwriting of varying ambition. The ERP holds work orders, quantities, and shipment records, but not what physically happened at the machine. Excel files from the planning desk hold the reconciliation somebody attempted last quarter. And memory holds the rest — which is why the first hour of every genealogy request is spent finding the one supervisor who ran that line in March.
Assembling the pack means walking the chain by hand: read each traveler, transcribe it, match lot numbers against the receiving log, join work orders to shipments in the ERP, and reconcile the three sources when they disagree — and they will disagree, because a traveler written at 14:40 and a shipping record keyed the next morning describe the same week from different planets.
For one PO with, say, twelve work orders across two lines, a realistic timeline looks like this:
| Day | Activity | What actually happens |
|---|---|---|
| Day 1 | Collect | Pull travelers from files, export ERP work order and shipment lists, find receiving logs, interview supervisors for anything unrecorded. |
| Day 2-3 | Reconcile | Match travelers to ERP quantities line by line. Chase mismatches: missing initials, a lot consumed but never received, two travelers with the same number. Every gap is a decision: leave blank and explain, or guess and hope. |
| Day 4 | Format | Type the reconciled data into the customer's template (or yours), translate initials into operator names, build the lot-to-shipment mapping table. |
| Day 5 | Check | Cross-check totals: input quantities vs work order consumption, output lots vs shipped quantities. Fix what doesn't add up. Sign, scan, send — usually later than Friday. |
Five working days, two to three people involved, and the result is a static document. Next month, a different PO from the same customer starts the whole walk again from zero. The cost is not really the week; it is that the record exists only when demanded, is never reusable, and quietly caps how many customers who ask such questions you can afford to serve. This is the same chain lot traceability for recalls depends on — the recall question and the PO-1234 question are the same data, asked at different volumes.
What a Complete Genealogy Pack Contains
Whatever the format, a pack that survives an SQE's review has these sections:
- Scope statement. The PO number, the finished lots it covers, the date range, and an explicit statement of what is included and excluded.
- Material pedigree. Input lot numbers per work order with quantities consumed, plus supplier names and their lot numbers — one step up.
- Production events. Per work order: machine, station, operator, start and end timestamps, quantity produced, and any changeovers inside the run.
- Quality records. In-process inspections, final inspection results, and any NCRs or holds attached to the covered lots, with dispositions. A pack without the NCRs looks like a pack with something to hide.
- Output-to-shipment mapping. Each output lot, the quantity shipped, shipment date, and destination.
- Exceptions and deviations. Rework events with their original-lot linkage, deviations from standard process, and any concession the customer granted.
- Method note. One paragraph on how the records were captured — terminal entries, timestamps in what timezone, who signs. Reviewers trust data more when its origin is stated plainly.
If you produce packaging, extend the pedigree to roll level — core numbers, width, roll-to-roll mapping — because a brand owner investigating a printing defect will ask for the specific roll, not the pallet. Roll-level traceability for converters covers what that record looks like.
How It Works When Genealogy Is Captured in Flow
Now run the same request against a line where the MES records events as they happen. The operator confirms the material lot at the terminal when loading a work order, so consumption links to the order at the moment it occurs. Output, scrap, operator, machine, and timestamps attach to the same work order record. Shipments close the chain. The genealogy was built during production, not after the email.
Answering PO-1234 becomes one query: select the PO, walk inputs backward and outputs forward, export. The pack in the seven sections above generates from the record in minutes, and the arithmetic checks (inputs = consumption, output = shipped) hold by construction instead of by day-5 spreadsheet reconciliation. The week collapses to under an hour, most of it spent reading your own export before sending. The underlying data model — forward and backward links per lot — is the same one described in lot traceability and recall genealogy; if you prefer the concept in Bahasa Indonesia, see traceability adalah.
Turn the Next Request Into an Asset
Here is the part factories miss. An SQE who receives a complete, timestamped genealogy pack within a day files a mental note: this supplier's records are real. That note compounds. It shortens their next audit, it buys benefit of the doubt when a borderline complaint lands, and it becomes a differentiator when their sourcing team ranks suppliers — a documented traceability capability is a reason to give you more volume, and increasingly a condition for keeping any.
The way to get there is to test yourself before the customer does. Run a drill: pick a shipped PO at random, try to produce the full pack against a clock, and score the gaps. That exercise, done honestly, is a mock recall drill, and the first one usually hurts — travelers missing, lots unreconcilable, hours gone for half a chain. Better to find that on a Tuesday you chose than in the email you didn't. Whether you fix the gaps with process discipline alone or with a system that captures events in flow, the readiness test is the same: genealogy for any PO, on demand, in hours. The overview on Voltrus MES shows the export side; the rest of this post assumes only that you want to stop paying the five-day tax.
Frequently Asked Questions
What if our records are partly paper?
Then your first honest answer to the customer is a scanned, organized version of what exists, plus a stated method note — never a silently reconstructed chain. Be upfront about which links are transcribed from travelers and which come from ERP. SQEs tolerate "recorded on paper, transcribed here, available as scans" far better than they tolerate inconsistencies discovered later. Then start closing the gap: even capturing only material-lot confirmation and output counts at a terminal, per work order, digitalizes the two links every customer request needs most, and the paper residue shrinks with each month.
The customer didn't set a deadline — how fast is fast enough?
Same business day for a single-PO request signals a controlled process; five days signals a reconstructed one. Even if you cannot go faster today, reply with the pack's structure and a delivery date within 24 hours, then hit it. Reviewers grade responsiveness on the first request and remember it for years. The deadline in the email is the floor, not the target.
Do we need to give the customer everything — machine and operator included?
For the PO in question, yes: the four questions at the top of this post are the scope they expect, and machine/operator detail is what lets their engineer isolate a defect to a shift instead of suspecting your whole output. What you are not obliged to share is anything outside the PO — other customers' lots, pricing, other production. A good pack answers the question fully and nothing more; that boundary is what the scope statement in section 1 is for.
One CSV, Not One Week
Voltrus MES records material lots, operators, and output at the terminal, so genealogy for any PO exports as one pack — inputs, events, shipments — in minutes. One line to start.
See Voltrus MES