# Apparel Quality Dashboard: What to Display, for Whom, and Why > What belongs on a garment factory quality dashboard — DHU, first-pass rate, defect Pareto, rework queue, operator quality, A/B grade ratio — with the right view for checkers, supervisors, and owners, and update frequencies that actually change behavior. **Source:** [https://scanerp.pro/blog/apparel-quality-dashboard.html](https://scanerp.pro/blog/apparel-quality-dashboard.html) --- # Apparel Quality Dashboard: What to Display, for Whom, and Why S Santosh Rijal · August 17, 2026 · 8 min read Quality TL;DR — Direct Answer: A useful apparel quality dashboard shows six things: **DHU**, **first-pass rate**, a **defect Pareto** (which defect types dominate), the live **rework queue**, **per-operator/per-operation hotspots**, and the **A/B grade ratio**. It needs three different views — piece-level for checkers, hourly for supervisors, weekly trends for owners — and its update rate must match the decision rate: per-scan for checkers, hourly for supervisors. A dashboard fed from yesterday's paper isn't a dashboard; it's a museum. Every factory has quality *data*. Very few have quality *visibility* — the difference between a checker's tally sheet that gets totaled at 6 PM and a screen that shows the stitching-defect spike at 10:40 AM, while the operator who's producing it is still sewing the same lot. This is a practical guide to what belongs on that screen, learned from running one in my own 500-machine CMT operation: the six metrics that earn their pixels, the three audiences who need different views, and the update frequencies that actually change floor behavior. ## The Six Metrics That Earn Their Pixels | Metric | What It Answers | Acts On It | |---|---|---| | 1. DHU (defects per hundred units) | How defective is our output overall? | Everyone — the headline number (benchmarks here) | | 2. First-pass rate | What share of pieces clears checking without rework? | Supervisor, owner | | 3. Defect Pareto | Which defect types dominate — stitching, stain, tear, measurement? | Supervisor, mechanic, IE | | 4. Rework queue | How many pieces are waiting for repair right now? | Supervisor — it's hidden WIP | | 5. Quality hotspots | Which operator / operation / machine generates today's defects? | Supervisor — coaching & machine checks | | 6. A/B grade ratio | What share of finished goods is first quality? | Owner — it's margin in one number | Notice what's *not* on the list: total pieces checked (vanity), cumulative defects since January (unactionable), and anything requiring a legend to interpret. A dashboard metric earns its place by changing a decision this week; everything else is decoration that trains people to stop looking. ## Three Audiences, Three Views — Never One Screen for All ### The checker: piece-level, right now The checker's "dashboard" isn't charts — it's the interaction itself: scan the bundle, mark pass or repair, pick the defect type, attach a photo if it's damage. Two design rules matter enormously on a real floor: the pass/fail state should be visible from meters away (a screen that turns green or red does more than any chart), and defect-type entry must be a tap, not typing — checkers won't type, and they shouldn't have to. ### The supervisor: hourly, by line and operation The supervisor view answers one question repeatedly: *where is quality breaking right now?* DHU by line, the defect Pareto for today, the rework queue length, and the hotspot list. The killer feature is **attribution** — when defects spike, knowing within the hour whether it's one operator (coaching), one operation (method), or one machine (mechanic) turns a day-long investigation into a walk across the floor. This is the quality twin of [WIP bottleneck detection](/blog/wip-tracking-garment-factory.html). ### The owner: weekly trend, in money terms Owners don't need piece-level noise. The owner view is four trends: DHU trajectory across weeks, first-pass rate, the A/B ratio by lot, and rework cost (rework pieces × the standard minutes they consumed twice). The last one converts quality from a virtue into a line item — which is what finally gets it managed. Quality's connection to pay matters too: our floor pays a repair bonus on damaged-piece rework and holds payment rules on severe damage, which is only enforceable because [payment and quality run on the same scan data](/blog/piece-rate-payment-calculation-garment-factory.html). ## Update Frequency: Match the Decision Rate **The rule:** a dashboard must update as fast as the decisions it feeds — and no faster. - **Checker screens:** per scan (seconds) — every piece is a decision. - **Supervisor views:** hourly resolution — the cadence of rebalancing, coaching, and mechanic calls. - **Owner trends:** weekly — reacting to daily quality noise from the owner's chair causes more chaos than it prevents. The most common failure mode in factories that "have a dashboard": it's fed from paper tally sheets typed in each evening. The display is digital; the data is a day old. By the time a defect spike becomes visible, the lot is sewn, the operator has gone home, and the conversation is forensic instead of corrective. A day-old quality dashboard is a report wearing a costume. ## Collection Without Data Entry: The Checking Station as a Scan Point The reason most small factories have no dashboard isn't screens — it's collection. Nobody has staff to type defect tallies all day. The scan-based answer: make checking itself the data entry. On my floor, the checker scans the bundle QR like any other station, taps pass or repair with a defect type, and photographs real damage. That one interaction — part of work that was happening anyway — simultaneously feeds DHU, first-pass rate, the Pareto, the rework queue (repair pieces split into their own bundles), per-operator attribution, and the A/B grading that flows into [finished-goods receipts](/blog/end-to-end-garment-tracking-without-data-entry.html). The honest boundary, as always: the dashboard *shows*; it doesn't *fix*. A stitching-defect spike attributed to machine 23 still needs a mechanic with a screwdriver. What the screen removes is the two days it used to take to learn machine 23 was the problem. ## Starting From Zero: The One-Week Version - **Days 1–2:** Define your defect types — five to eight, no more (stitching, stain, tear, measurement, fabric, other covers most floors). More types than a checker can remember means garbage categories. - **Days 3–5:** Put collection at the checking station — scan-based if you have it, a structured tally board if you don't. Per-piece, per-defect-type, per-operation. - **Day 6:** Display exactly two numbers where the line can see them: today's DHU and the top defect type. A whiteboard works. Visibility changes behavior before any software does. - **Day 7:** Run the first Pareto conversation with supervisors: what's our #1 defect, and whose problem is it — training, method, or machine? ### Scan ERP by Country [🇮🇳 India](https://scanerp.pro/india/) [🇧🇩 Bangladesh](https://scanerp.pro/bangladesh/) [🇻🇳 Vietnam](https://scanerp.pro/vietnam/) [🇳🇵 Nepal](https://scanerp.pro/nepal/) [🇰🇭 Cambodia](https://scanerp.pro/cambodia/) [🇱🇰 Sri Lanka](https://scanerp.pro/srilanka/) [🇪🇹 Ethiopia](https://scanerp.pro/ethiopia/) ### A Quality Dashboard That Feeds Itself Scan ERP turns checking into the data entry: pass/repair scans with defect types and photo evidence feed DHU, defect Pareto, rework queues, and A/B grading live — plus a finishing screen that turns green or red, visible from 5 meters. Built in a working CMT factory. [Request a Free Demo](https://scanerp.pro/#contact) The test of any quality dashboard is a single question asked at 11 AM: *what is today's number one defect, and which station is it coming from?* If answering takes more than ten seconds, you don't have a dashboard yet — you have a report that arrives after the damage. *Santosh Rijal is the founder of [Scan ERP](https://scanerp.pro/), a garment manufacturing ERP system designed for factory floor operations. He works directly with sewing lines, cutting rooms, and production supervisors across Nepal's garment manufacturing sector.*