Sample Approval Dashboards That Track Cohorts and Reopened Work

A sample dashboard reports a nine-day approval time. That sounds useful until the merchandiser asks about the four requests still waiting. They have no approval date, so the average leaves them out.

The number may be correct for completed work. It does not describe the whole queue.

A garment sample approval dashboard needs three views. One shows what is open now. Another follows requests that started together. A third measures the work inside each submission and review round. These views answer different questions and need different denominators.

This guide develops an original measurement design for those views. All requests, dates, and quantities in the worked examples are hypothetical. The aim is a report that can explain its counts, including cancellations and reopened approvals.

Start with the question behind the chart

A morning meeting may ask which sample needs a decision today. A seasonal review may ask whether requests move through approval faster than last season. A technical team may ask how often the first submission needs another round.

One average cannot answer all three.

For daily action, show current status, age, next owner, and due date. For process comparison, follow a defined group of requests over a common period. For review quality, examine first decisions and revision rounds.

Write the question beside each proposed measure before building the visual. If two measures need different dates or populations, keep their definitions separate.

ApparelDiary's guide to sample approval purposes explains what each sample stage must prove. This dashboard design assumes those purposes are already clear. It measures their progress rather than redefining the approval gate.

Choose the request as the main unit

Use one RequestID for one approval purpose under a defined scope. That scope may include style, season, sample type, supplier, colour, and required sizes.

A physical garment is not always one request. A size-set request can contain several garments. A single style can have several approval requests.

Give each submission a separate SubmissionID beneath its RequestID. A second fit round is another submission for the same request, unless the business deliberately opens a new approval purpose.

Keep physical sample IDs as a further level when needed. They help track parcels, pieces, and locations without inflating the request count.

Centric describes barcode-based sample arrival records, including received dates and locations. Such records can supply useful events to an approval report. Arrival itself is still separate from an approval decision. Centric sample management

Keep request submission and event data separate

A useful model has three linked tables.

Add a separate physical-item table if the team tracks individual samples.

The request table provides a stable count. The submission table describes attempts. The event table explains the path and supports an earlier reporting cutoff.

Do not flatten all three tables and count rows as requests. A request with three rounds and ten events would appear larger than a request with one round.

Microsoft's model guidance stresses a consistent fact-table grain. In this design, “one request” and “one event” are different grains. Keep that distinction visible in the model and measure names. Star schema guidance

Define the states without hiding exceptions

Agree a short list of states that the source can support. For example: awaiting brief, with sample room, in transit, awaiting review, revision required, approved, and cancelled.

These are proposed reporting states. A factory should map its actual workflow rather than copy the labels without checking.

Record transitions as events with times. Preserve the reason when an approval is reopened or a request is cancelled. A current-status field alone cannot explain yesterday's queue.

Keep approval with conditions distinct where those conditions still block the intended release. The report must follow the agreed gate. It should not decide that a comment such as “okay except trims” means full approval.

Also flag impossible sequences. A decision before receipt may be valid for a digital submission, but it needs the correct route. A physical-only request with that sequence may have a missing or wrong timestamp.

Use one explicit reporting cutoff

Every open-age number depends on an “as of” time. Display that time and the timezone on the report.

For a closed request, elapsed time ends at the defined decision. For an open request, age ends at the reporting cutoff. Do not replace the missing approval date with today's date and label the result approval lead time.

Use the same cutoff across all cards and detail rows. Otherwise, one refresh can show counts from noon and ages from the following morning.

For cross-border work, store timestamps with enough context to recover the actual instant. Convert them to the chosen reporting zone for display.

Distinguish calendar time from working time. A buyer may review only on weekdays, while a factory operates on a different calendar. Report the chosen clock plainly. Two “days” measures can differ without either being an arithmetic error.

Calculate elapsed time with the right units

Suppose a request opens at 09:00 and receives approval at 15:00 ten days later. Under the example's fixed clock, elapsed time is 246 hours.

Elapsed days = Elapsed hours ÷ 24.

Elapsed days = 246 ÷ 24 = 10.25 days.

The variables are the two event times and their elapsed difference. The result uses calendar days, including nights and weekends. It does not measure hands-on labour.

A date function can count boundaries rather than full elapsed units. Microsoft documents that SQL Server DATEDIFF counts the specified boundaries crossed. Crossing midnight can therefore count as one day even when only a few minutes pass. DATEDIFF reference

Choose precision that fits the measure. Test a short interval across midnight before trusting a days calculation. Also test an interval with a missing end time and one with an end before its start.

Build the open-work view first

The current queue should show each open RequestID once. Include sample type, supplier, current state, age, due date, next owner, and the latest meaningful event.

Sort overdue work by a useful operational rule. That may combine due date with the downstream milestone at risk. A request's age alone does not reveal its urgency.

Show missing due dates as an exception. Do not make them look on time by assigning a distant date.

Keep original and revised due dates in separate fields. The current promise helps daily planning. The original promise helps explain changes over time.

An age band is a display choice, not a universal standard. A team could use zero to seven, eight to fourteen, and more than fourteen days. Define whether each boundary is inclusive and apply the same rule everywhere.

Form cohorts from a stable start event

A cohort is a group that starts under a common rule. For this report, group requests by the week in which the approved brief became ready.

That is one possible choice. A team could choose request creation instead. The key is to state which event begins the clock and keep it stable.

Do not group by approval week and call the result a start cohort. Approval-week reporting describes work completed in that week. It can mix easy recent requests with old difficult ones.

Keep the cohort date even when a request changes owner. Otherwise, a supplier transfer can move slow work out of one group's history and into another's without explanation.

A revised brief may change the work. Record the change and decide whether it belongs to the same approval purpose. Do not reset the clock merely to improve the trend.

Work through a fourteen-day cohort

Ten hypothetical requests begin together. All have a full fourteen days of follow-up at the reporting cutoff.

Six requests received a first approval by day fourteen. Five remain approved at that cutoff. Four are open, including reopened request C. One is cancelled.

Those counts reconcile:

Total cohort = Approved now + Open now + Cancelled now.

Total cohort = 5 + 4 + 1 = 10 requests.

The reconciliation is useful because a dashboard can otherwise lose a reopened request between the approved and pending cards.

Keep the status categories mutually exclusive for this snapshot. Historical event counts do not need to be mutually exclusive; the same request can have both an approval and a later reopening.

Explain each approval rate

For the defined fourteen-day horizon, the first-approval measure is:

First approval by day 14 = Requests first approved by day 14 ÷ Cohort requests.

First approval by day 14 = 6 ÷ 10 × 100 = 60%.

This says that six requests reached an approval event within fourteen days. It does not say all six still hold valid approval.

The current approved share at day fourteen is:

Current approved share = 5 ÷ 10 × 100 = 50%.

The cancelled share is 1 ÷ 10, or 10%. The open share is 4 ÷ 10, or 40%.

Here, cancellations stay in the original cohort. That makes the outcome distribution visible. If a separate business measure excludes cancelled work, label its denominator and show the exclusion count.

Do not silently remove cancellations from one season but keep them in another. The apparent improvement could come entirely from a changed definition.

Show why the completed-only average is incomplete

The six first approvals occurred after 4, 6, 8, 10, 12, and 14 days.

Mean first-approval time among approved requests = Sum of observed first-approval days ÷ Number first approved.

Mean = (4 + 6 + 8 + 10 + 12 + 14) ÷ 6 = 54 ÷ 6 = 9 days.

The median is also nine days. The middle two values are eight and ten, whose average is nine.

Both statistics describe the six observed approvals. Neither includes a future approval time for G, H, or J. Request I was cancelled, and C's later reopening raises a separate question.

Label the card “First-approval time among six approved requests.” Put the open and cancelled counts beside it.

A falling average can mean faster work. It can also mean that only easy requests are closing while difficult ones remain open. The cohort view helps distinguish those situations.

Compare requests with equal follow-up

A request started yesterday has not had fourteen days to reach approval. Treating it as a failed fourteen-day result would bias the measure.

For a simple fixed-horizon report, include only requests whose start is at least fourteen days before the cutoff. Show newer requests in an “awaiting full follow-

up” count.

This rule should follow the start date, not the outcome. Do not include a new request because it approved quickly while excluding another new request that remains open.

NIST describes right-censored data as cases whose eventual event time is beyond the observation limit. An open approval request has a similar measurement issue. Its eventual approval time is not yet known. This is an analytical application of the concept, not a textile-specific NIST standard. NIST on censoring

For routine management, equal follow-up and clear counts are often easier to audit than a complex model.

Use survival methods only with a sound event definition

A more advanced report can estimate time to a defined event while retaining open observations. Kaplan–Meier is one established method for censored time data. NIST documents how event and censoring records contribute to its estimate. Kaplan–Meier documentation

For this use, an analyst must define what the event means. First approval is a one-time milestone. Current valid approval can later reverse. Those are not the same endpoint.

Cancellation also needs care. A cancelled request may never reach approval and may differ from active work. Simply treating every cancellation as harmless censoring can produce a misleading curve.

State the method's assumptions and the treatment of competing outcomes. Show the number still under observation as time increases.

Do not publish a smooth curve that hides a tiny late-stage population. If the data cannot support the chosen method, retain a transparent fixed-horizon table.

Count reopening without erasing the first approval

Request C received approval on day eight and reopened on day thirteen. Preserve both events.

A descriptive reopening share at the cutoff is:

Reopened after first approval = Requests reopened at least once ÷ Requests ever approved.

Reopened share = 1 ÷ 6 × 100 = 16.67%.

This is an as-of measure, not a fair comparison of equal follow-up. Request A has ten days after approval; F has none.

For a seven-day reopening measure, require seven full days after first approval for every included request. In this small example, only A and B qualify at day fourteen. Neither reopened within that window, so the observed result is 0 out of 2.

That does not contradict the overall 1 out of 6. The populations differ. Display the denominator and horizon instead of placing both percentages under the same label.

Separate first-pass decisions from request completion

First-pass approval asks what happened to the first reviewable submission. It needs a SubmissionID and a decision definition.

Suppose eight first submissions have received a decision. Five were approved at that first decision and three needed revision. Two further first submissions still await review.

First-pass approval among decided submissions = 5 ÷ 8 × 100 = 62.5%.

Show the two undecided submissions beside the rate. Do not call them failed unless the measure explicitly counts missed review deadlines.

A request may need another round because the design changed. Another may need it because a seam failed the brief. The rate alone cannot explain the cause.

Use reason codes for analysis, with space for a short factual note. Keep that diagnosis linked to the review record. The dashboard should direct the team to evidence rather than assign blame from a percentage.

Split the elapsed clock into useful states

Consider the request that took 246 hours. Its recorded intervals are:

The sum is 246 hours, or 10.25 calendar days.

The sample-room intervals total 120 hours. Transit totals 72 hours. Review totals 48 hours. Brief and clarification intervals total six hours.

These intervals show where elapsed time accumulated. They do not prove who caused a delay or how many labour hours were used.

Require intervals to join without overlap or unexplained gaps. A request cannot spend the same hour in both transit and buyer review under this exclusive-state design.

Choose percentiles and display them honestly

A median can hide a long tail. A higher percentile can show how slowly the slower part of completed work moved.

Specify the percentile method. SQL Server PERCENTILE_CONT interpolates values and may return a number that is not an observed duration. PERCENTILE_DISC returns an observed value. Percentile function reference

Use the same method across tools before comparing results. A spreadsheet and SQL query can disagree if one uses a discrete method and the other interpolates.

Show the sample count with every percentile. With six completed requests, a high percentile depends heavily on very few cases.

Keep completed-duration percentiles separate from open-age percentiles. The first describes observed completion times. The second describes the age of work still waiting at the cutoff.

Design three linked report pages

The action page should start with open work. Provide filters for sample purpose, supplier, buyer, season, and next owner. Let the user open the latest review record from a request row.

The cohort page should show starts, first approvals within the chosen horizon, current outcomes at that horizon, and follow-up eligibility. Use cohort week on one axis and elapsed day on the other when the audience needs a progression table.

The round page should show first decisions, revision counts, reopening, and state durations. Keep the actual sample size visible.

Every page should carry the same cutoff and data-status note. A missing buyer feed should appear as missing evidence, not as zero activity.

For a wider product-data context, see ApparelDiary's apparel PLM guide.

Test the report with awkward cases

Use the ten-request cohort as a small acceptance dataset. Confirm that the cards show ten requests, six first approvals, five currently approved, four open, and one cancelled.

Then add a second approval after C's reopening. The request count must stay ten. The approval-event count may rise, while the distinct ever-approved count stays six.

Add a duplicate event delivery. It must not create another request or another review round.

Test a request with two sizes and three physical garments. Confirm that the request count remains one under the agreed scope.

Finally, move the cutoff back to day twelve. F must no longer appear approved. Historical state should follow event time, not the latest status copied backward.

Handle late entries and changing scope

A buyer may approve a sample on Monday but enter the decision on Wednesday. Keep both the event time and the entry time. They answer different questions.

Use the event time for the elapsed approval measure once the record is accepted. Use the entry time to explain when the dashboard could first know about it. Do not pretend that Monday's published report already contained a decision entered two days later.

Choose whether historical reports show the latest corrected truth or the exact figures published at the time. Both can be useful. Label them so a manager does not mistake a corrected history for a failed refresh.

Scope changes need a similar trace. Suppose a request begins with sizes S, M, and L, then the buyer adds XL. Record when the extra size joined and whether it changed the due date. A request-level “approved” result needs a clear rule for all required sizes.

One approach is to keep a requirement table beneath the request. Each required size or approval component has its own result. The request closes only when the agreed set is satisfied.

This is a proposed design, not a universal PLM rule. It prevents one approved size from closing a whole size-set request by accident. The dashboard should still count one request while exposing the unfinished component in its detail view.

Read the numbers in a sample meeting

At the day-fourteen review, the buyer sees “60% first approved” and asks why only five requests appear in the approved list. Open request C's history. It reached approval on day eight, then reopened on day thirteen. The chart and list answer different questions; neither needs a hidden correction.

Next, look at J. Suppose its agreed due date was day ten and it has been awaiting review since day eleven. Its total age is fourteen days. It is four days past due and has spent three days in the current review state. Those three values should sit in separate columns.

The next action is to obtain a review decision, not to ask the sample room to make another piece. Confirm the receipt record and identify the reviewer. If the sample never arrived, correct the state first.

Request I calls for a different conversation. It was cancelled on day five. Ask whether it still consumes sample-room work or booked shipping. Its cancellation belongs in the cohort outcome, but it should not occupy the active approval queue.

This small meeting script tests whether the dashboard leads to the right work. If every red row sends the same “please expedite” message, the report has lost the distinction between an overdue decision, missing evidence, and a cancelled request.

Common questions

Should every sample type share one approval target?

Only if the purposes and operating conditions justify it. A simple proto and a complex size set may need different targets. Keep their populations visible.

Can a cancelled request be deleted from the report?

Preserve its identity and outcome. A filtered view may exclude it under a stated rule, but the original cohort should still reconcile.

Is a reopened request new work?

It creates new activity, but it need not create a new request. Keep the original ID when the approval purpose is unchanged.

Can an approval dashboard prove that a supplier caused delay?

No. State durations identify where time accumulated. Cause needs review evidence, dependencies, and the actual sequence.

Make the denominator part of the answer

A useful sample dashboard can explain nine days, sixty percent, and forty percent without treating them as interchangeable results. Each figure needs a named population, a clock, and a cutoff.

Start with stable request and submission IDs. Preserve the event history. Show open work beside completed work, compare cohorts with equal follow-up, and keep reopened approvals visible. Those choices turn a status chart into a report the sample team can use and defend.

Sample approval tracking depends on how samples are defined, so see garment sample types, why samples need rework and factory KPI dashboard design.

References

• Centric Software — Modernise order and sample management.

• Microsoft Learn — Star schema guidance.

• Microsoft Learn — DATEDIFF.

• NIST — Censoring.

• NIST — Kaplan–Meier plot.

• Microsoft Learn — PERCENTILE_CONT.

• ApparelDiary — Garment sample types and approval purposes.

• ApparelDiary — Apparel PLM.