Every lasting tableware program rests on a boring document: the specification sheet. It is the reference the factory produces to, the receiving bay inspects against, the audit verifies, and the claims conversation opens with. When it is complete, disputes are rare and short. When it is missing fields, every gap becomes a negotiation with your own memory.
This guide builds the spec sheet field by field — the anatomy that turns "we want this plate" into an enforceable document.
The Identity Block
SKU code and name. The program's canonical identifier — the code stamped or marked on pieces where possible (the reorder-identity discipline), and the name humans use. One code, one piece, forever.
Category and format class. Where the piece lives in the fleet's structure (dinner plate class, the rim-profile family, the body family) — the field that connects individual pieces to the program's classes (our vessel-map and kit logic).
Version and date. Spec sheets change (the change-log discipline): the version field is what makes "the spec we approved in March" a precise reference instead of an argument.
The Physical Block
| | |
|---|
Dimensions (Ø, L, W, H) with tolerance bands | Size, rack fit, stack classes | Caliper at named points (FAI bench) |
Capacity (ml) for vessels | | |
Weight (g) with tolerance | | |
| Strength, thermal behavior | Gauge points per the sheet |
| | |
| | |
The physical block's power is in its verification column: every field names how it will be checked, by whom, when (first article, per lot, receiving) — a spec without a verification path is a wish with formatting.
The Material Block
Body specification. The body family and its key data: absorption value, reinforcement claims with data (our body guide's verification), thermal shock parameters.
Glaze system. Color standard (the sealed reference plus the ΔE tolerance from our color guide), gloss target with geometry (our gloss guide's GU clause), finish type, and the decoration layer's position (under/over — our glaze guide's durability logic).
Food-contact documentation. Per-market frameworks, per-SKU results, batch-tied (our test-report guide's structure) — named in the sheet by reference, not restated.
The Production Block
Firing and batch discipline. The qualified cycle reference and the batch-record commitment (our kiln guide) — the sheet requires records, not curves.
Color/gloss per-batch verification. The instrumented release (batch ΔE and GU logs) that our measurement guides define.
Marking. The SKU or brand mark: position, method (laser/underglaze — the durability tiers), and legibility standard — the field that makes reorders identifiable at any store, any year.
The Commercial Block
Par and packaging linkage. Pieces per export carton, carton dimensions, pallet config — the container-loading disciplines (our loading guide) begin on the spec sheet.
Claim conditions. What constitutes a claimable defect (tied to the AQL defect sheet), the claim window, and the evidence format (our claims guide) — the block that keeps post-arrival conversations procedural.
Reorder path. The production-window alignment and the replacement-reserve arrangement (the matching economics from our finish guide) — how this SKU reorders without drifting.
The Fields Missing Most Often
The audit of real-world spec sheets finds the same absences, and each becomes a dispute eventually:
1. The footring finish — omitted, then discovered as stack-grinding.
2. The gloss tolerance — "glossy" instead of a GU band; the drift arrives with reorder three.
3. The marking spec — brand marks applied ad hoc, or not at all; reorders become archaeology.
4. Capacity for bowls — portions drift until the menu engineering conversation exposes it.
5. The change-log version — the sheet itself unversioned; the program argues with ghosts.
Frequently Asked Questions
One sheet per SKU or per family? Per SKU, with family-level annexes for shared body/glaze systems — the SKU sheet is what receiving and claims reference; families organize production.
Who writes the spec sheet — buyer or supplier? Buyer owns it (it is the program's contract), supplier co-signs capability against it (the FAI process). Supplier-written specs describe what they like making; buyer-owned specs describe what the program needs.
How detailed is too detailed? Every field that will ever be verified earns its place; fields nobody will ever check are decoration. The verification column is the honesty test — cut the fields with no verifier.
What if the supplier's capability is below the spec? That is what first articles measure. The spec states the need; the FAI states the reality; the gap is negotiated once, on the bench, with data — the cheapest negotiation the program will ever run.
Paper or system? The sheet is a document; its life (versioning, annexes, references) is a system. The program's spec book — the file our audit and kit guides reference — is where both live.