How Do You Build a Bag Sourcing Dashboard for Lead-Time Tracking?

Sourcing teams do not lack information; they lack a place where the information is in the same shape twice. One person holds the dates in a mailbox, another holds the quantities in a spreadsheet, and the approval state lives in whoever approved last. That works for one order and fails at four. This piece sets out the twelve fields a bag sourcing dashboard needs, who owns each one, how often it is updated, and — as importantly — what does not belong on it.

What Is a Sourcing Dashboard Actually For?

Four questions, asked weekly: what is being built, where each order is, what is late, and what needs a decision this week. Every field on the dashboard should serve one of those four. A field that serves none of them is decoration, and decoration is what turns a dashboard into a chore and a chore into something that stops being updated.

The second purpose is continuity. People leave, go on leave, and change roles, and a programme should not depend on one person recollection. A dashboard that has been updated weekly for two quarters is a handover document, an audit trail and a planning input at the same time, and it costs twenty minutes a week to keep.

Which Twelve Fields Belong on It?

Twelve, and each exists because somebody will need it: the style reference, the specification revision, the quantity split by colourway, the sourcing desk, the order date, the deposit date with its value date, the sample approval date, the bulk completion date as calculated, the inspection date, the ship date, the status, and the owner. Twelve fields cover the commercial, the schedule and the accountability questions in one view.

Who Owns Each Field?

One person owns the whole dashboard, and that is the important part. Fields can be contributed by several people — finance contributes the deposit value date, quality contributes the inspection date — but ownership of the document itself has to be single, because a document with two owners is a document that is updated twice or not at all. Name a deputy as well, because programmes run 35-50 days and people take leave.

Dashboard owner

Updates it weekly and owns the status column

Deputy

Covers leave, and knows the update rhythm

Finance contributor

Deposit value date, balance due date

Quality contributor

Inspection booking and verdict

Logistics contributor

Ship date and the transport cut-off

Commercial contributor

Specification revision and quantity changes

How Often Should It Be Updated?

Weekly, on a fixed day, and immediately on three events: a sample approval, a change order, and a milestone slip of more than a week. Those three change the downstream dates, and a dashboard that is only updated weekly would be a week stale at exactly the moment it is most needed. Everything else waits for the weekly cycle.

The fixed day matters as much as the frequency. An update that happens "some time in the week" is read at unpredictable times and stops being relied upon. An update that lands on Tuesday morning is read on Tuesday morning, and the team builds a habit around it. The habit is the product; the spreadsheet is only where the habit lives.

How Do You Track Compliance Documents on It?

By expiry date rather than by existence. A declaration held is only useful while it is current, and a restricted-substance list is updated on a cycle that has nothing to do with the order cycle. One column per market, showing the date the document was issued and the date it has to be reviewed, converts a compliance folder into something the dashboard can warn about before a document is needed rather than after it has lapsed.

The second compliance field worth carrying is the material reference each document covers. Where a substitution has been approved and recorded, the declaration that covered the original material may no longer describe what is being built, and that is invisible unless the material reference sits next to the document date. Two columns, and they are what makes the compliance file auditable rather than merely present.

What Does It Tell You About Reorder Timing?

More than most planning tools, because it holds the two facts that decide reorder timing: how long this programme actually takes, and how much of the year has been committed. The slip pattern gives the first, measured from written approval rather than from the first email, which is the interval that matters. The annual quantity column gives the second, and it is what tells a team whether a reorder is discussable below the floor of 500 pcs.

Add one derived column and the dashboard becomes a planning tool: the last safe order date. Calculated backwards from the date goods are needed, through the transit clock, the inspection booking and the bulk window, it tells the team when the decision has to be made rather than when the goods will arrive. One column, and it is the one a planner will actually look at.

How Do You Onboard a New Team Member With It?

Hand them the dashboard and one folder per style, and they have the programme. The dashboard gives the state and the owner; the folder gives the specification, the sealed reference, the compliance documents and the inspection history. Together they answer the questions a new person asks in the first week, which otherwise consume the time of the person who happens to remember.

The test of whether the dashboard is good enough to hand over is simple: can somebody who has never seen the programme read it and name what is late and what needs deciding? If yes, the onboarding costs an hour. If no, the fields are not specific enough, and the fix is usually to replace a narrative with a date somewhere.

What Should It Show for Each Live Order?

One row per order, with the dates as dates rather than as durations, and the status as one agreed word. The status vocabulary matters more than it appears: "on plan", "at risk", "behind", "complete" and "on hold", each with a definition written somewhere on the page. Without definitions, "at risk" means whatever the reader is worried about, and the dashboard stops being a shared view.

Add one column that most teams leave out and that turns out to be the most read: the next decision and the date it is needed by. A dashboard that says what is coming, rather than only what has happened, gets opened by people who are not the owner — which is the measure of whether it is working.

What Should It Show for the Programme Rather Than the Order?

Three things that only become visible across orders: the annual quantity per style, the reorder position, and the pattern of slips. Annual quantity tells the team whether a style is at the floor or well above it, which decides whether the reorder conversation is worth having. The reorder position records which styles have a sealed reference and retained tooling, and are therefore discussable below the floor. And the slip pattern shows which milestone is consistently late.

How Do You Show Cost and Landed Position?

Carefully, and with one column rather than many. The dashboard is not a costing tool, and a cost build belongs in the commercial file. What does belong is a single landed cost per unit, updated when something structural changes, because it is the figure that tells a team whether a freight movement, a duty change or a packing change has moved the programme out of its commercial envelope.

Keep the unit price out of it if the team does not need it, and keep the cost build out of it entirely. A dashboard that carries nine cost lines per style stops being read, because the update burden grows and the signal is buried. One landed figure, with the date it was calculated, is enough for a team to notice when something has moved and go to the commercial file for the detail.

How Do You Build It Without a System?

With a spreadsheet, and the discipline matters more than the tool. One sheet, one row per order, twelve columns plus the next-decision column, and a definitions block at the bottom. Conditional formatting on the status column is enough to make it readable at a glance, and a dated change log on a second tab is enough to make it an audit trail. Most teams that buy a system first end up building this anyway.

The failure mode to avoid is the dashboard that becomes a project plan. A sourcing dashboard tracks a small number of dates and decisions; it does not track tasks, meetings, or the internal approval chain. Those belong elsewhere, and putting them here is what makes the weekly update take two hours instead of twenty minutes.

What Are the Three Views a Team Actually Uses?

The live-order view, sorted by completion date, which is what the owner opens on Tuesday. The late view, filtered to anything behind or at risk, which is what a manager opens when something has gone wrong. And the programme view, grouped by style, which is what gets opened at the point a reorder is being considered. Three views, one data set.

What Should Not Be on the Dashboard?

Anything that is not a date, a quantity, a status or an owner. Unit prices belong in the commercial file; the dashboard carries the order value if it must, but not the cost build. Test reports belong in the compliance folder, with an expiry date on the dashboard rather than the document. Email threads belong in the thread. A dashboard that hosts documents becomes a document store and stops being a dashboard.

Two specific omissions are worth calling out. Do not put the internal approval chain on it, because it changes weekly and makes the update heavy. And do not put a risk register on it; a risk register is a different artefact with a different cadence, and merging the two means neither gets maintained properly.

How Do You Keep It Honest?

By recording the original date beside every revised one. A dashboard that only ever shows the current completion date hides the slippage, and slippage is the most valuable thing it can show. Two columns — original and current — take seconds to maintain and they are what makes the slip pattern visible at the programme level.

A third discipline keeps the dashboard useful rather than merely accurate: review the fields once a quarter and delete anything nobody has used. Teams add fields easily and remove them rarely, and a dashboard that has grown to twenty columns stops being opened. The quarterly review is ten minutes and it is what keeps the weekly update at twenty minutes as well.

The second discipline is to write the reason next to every change, in a few words. Not because anyone will read it this week, but because in six months the reason column is the answer to "why does this style always run long". That answer is worth more than any planning tool, because it is specific to the buyer own programme rather than to a general model.

Where the team runs more than one market, add one column that is easy to overlook and that saves real time: the destination. A style going to two markets carries two document sets and often two tolerance expectations, and a dashboard that does not distinguish them will show one row for what is really two commitments. One column, and the compliance tracking above becomes possible.

One last practical note about the format: keep the dashboard in a place the whole team can open without asking, and keep the definitions block visible on the same screen as the data. A status word whose definition sits on another tab is a status word that will be interpreted rather than read, and interpretation is what turns a shared view into four private ones. Visibility of the definitions is a formatting choice and it decides whether the document works.

Frequently Asked Questions

People Also Ask