Sourcing Project Tracker Template: Manage 20+ SKUs Across Suppliers

Once you cross about 8 SKUs sourced from 3 or more suppliers, the email-and-folder method breaks. Samples come back without anyone remembering whose batch they're from. POs get repeated because nobody knows the previous one shipped. Tooling deposits sit on three different factories' books and your bookkeeper can't tell you which products have paid molds. The fix isn't more discipline — it's a tracker.

Key Takeaways

• Most sourcing chaos is information-architecture chaos, not execution chaos. A single source of truth for SKU × supplier × stage prevents most of the failure modes.
• A working tracker has eight required fields per SKU/supplier pair: status, stage, key dates, samples, tooling, MOQ, PO, QC outcomes — plus a free-text notes column.
• Three implementations work for different team sizes: Excel (1–3 people, simple), Notion (3–8 people, document-heavy), Airtable (5+ people, want views and automations).
• The tracker should be updated weekly, not on-demand. Standing 30-minute weekly review catches stalled items before they become problems.
• Pair the tracker with a shared folder structure (Google Drive or Dropbox): one folder per supplier, sub-folder per SKU, naming convention strict.

Why Loose Tracking Fails Around 8 SKUs

Up to roughly 5–8 SKUs and 1–2 suppliers, most teams operate from email plus a Slack channel and it's fine. Past that threshold, three things break.

Sample tracking. When 12 sample shipments are in flight from 4 suppliers, "did we approve the v2 sample of the silicone case?" becomes a 20-minute email search. The right answer is to have a tracker row showing sample v2 sent date, received date, evaluation outcome, and approval status — visible to anyone on the team in two seconds.

Tooling deposits and ownership. Different SKUs have different tooling status. SKU A's mold is paid and you own it; SKU B's mold is amortized into the unit price; SKU C's prototype tooling never converted to production tooling. Without a tracker, this lives in someone's head — and walks out the door when that someone leaves.

Re-order timing and MOQ commitments. When you placed PO #3 with Supplier X, did you commit to a quarterly minimum? When does the next PO need to fire to maintain the price tier? Without a tracker, you find out the answer when a supplier sends an invoice with a price increase because you missed the volume threshold.

The tracker doesn't need to be sophisticated. It needs to be a single place where the team agrees the truth lives.

Common Mistake: Trying to use the order-management module of a fulfillment system (Shopify, Cin7, etc.) as a sourcing tracker. These systems are optimized for inbound inventory and outbound orders, not for the upstream supplier-development pipeline. They lack fields for sample versioning, tooling status, and supplier qualification stage — so the team ends up tracking those things in a separate document anyway. Use a dedicated sourcing tracker for upstream; let the OMS handle downstream.

The Eight Required Fields

This is the minimum viable column set. Every implementation below uses these as the foundation; you can add fields, but don't subtract.

1. SKU + Product Name. Internal SKU code + a human-readable name. One row per SKU × supplier combination — if two suppliers make the same SKU, that's two rows.

2. Supplier (Legal Entity Name + City). Use the legal entity name from the business license, not the Alibaba store name. Add city for quick context.

3. Status / Stage. Pipeline stage from a fixed set: Sourcing → Sample Round 1 → Sample Round 2+ → Tooling → Pre-Production → Production → Shipped → Active Reorder. Don't allow free-text status.

4. Key Dates. Sample sent, sample received, sample approved, PO date, deposit wired, production start, ETD (estimated time of departure), ETA (estimated time of arrival).

5. Samples. Version (v1, v2, v3), evaluation outcome, approval status, photo or link to evaluation document.

6. Tooling Status. Required (Y/N), paid (Y/N), amount, ownership documented (Y/N), reference to OEM contract clause.

7. MOQ + Pricing. MOQ for current price tier, current FOB unit price, currency, last price-update date.

8. QC Outcomes. Result of last PSI (passed / failed / conditional), AQL major/minor counts, defects called out, link to QC report.

Plus a free-text Notes column for context that doesn't fit the structured fields.

Expert Tip: Add a hidden ninth field — Owner (the team member responsible for moving this row forward). When everyone is responsible, no one is. A named owner per row makes the weekly review productive: instead of "what's the status of X," the question becomes "Sara, where is X?" Two-minute updates instead of fifteen-minute archaeology.

Implementation 1 — Excel (Best for 1–3 Person Teams)

Excel works when the team is small enough that everyone has the file open at the same time isn't a real problem (Microsoft 365 / Google Sheets handles light concurrency). Strengths: fast to set up, no learning curve, plays well with the existing cost-sheet model, exports easily for ad-hoc analysis. Weaknesses: limited automation, no good way to enforce status values without dropdowns and validation, links to documents are messy.

Best practices for the Excel version:

1. Use Data Validation dropdowns on the Status column to enforce the fixed set

2. Conditional formatting on key date columns (red if date passed, no follow-up)

3. Filter view by supplier or by status for weekly review

4. One sheet for active SKUs, one sheet for archived (shipped + closed)

Implementation 2 — Notion (Best for 3–8 Person Teams)

Notion's database view is a stronger fit when each SKU has substantial associated documentation — sample evaluation notes, supplier audit results, internal photos. A Notion database lets each row open into a full page where unstructured content lives.

Strengths: native rich-text per row, easy linking between supplier pages and SKU pages, good mobile experience for warehouse/QC team in the field. Weaknesses: slower to load on large datasets, less powerful filtering than Airtable, exports are cumbersome.

Best practices for Notion:

1. Separate databases for Suppliers and SKUs, with relations between them

2. Each Supplier page contains business-license documents, NNN signed copy, OEM contract signed copy

3. Each SKU page contains specification sheet, golden sample photos, all PO history

4. Status column as a select field with the same fixed values

Implementation 3 — Airtable (Best for 5+ Person Teams Who Want Views and Automations)

Airtable shines when multiple people need different filtered views of the same data — operations needs the production view, finance needs the cash-flow-out view, the founder needs the high-level pipeline view — and when you want light automations like "ping #ops in Slack when a sample has been waiting for evaluation more than 5 days."

Strengths: powerful views and filters, strong API, native automations, good integration with Slack and Gmail. Weaknesses: pricing scales fast above 5 users, structural changes are harder once data is in, can become a "spreadsheet that thinks it's a database" without discipline.

Best practices for Airtable:

1. Three core tables: Suppliers, SKUs, POs — with linked records between them

2. Standard views: All Active, By Stage, Sample Pipeline, Tooling Status, This Week's POs, Overdue

3. Automations: Slack notification on stage change, weekly digest email of overdue items

4. A separate Documents table that links to the others, holding contract files, QC reports, etc.

The Weekly Review Discipline

The tracker is only as good as the discipline that maintains it. The single most important habit: a 30-minute weekly review on a fixed day.

Agenda:

1. Filter for "stalled" rows — anything that hasn't moved in 7+ days. For each, the owner names the next action and a date. This catches 80% of the failure modes.

2. Review samples in flight — anything sent more than 14 days ago without receipt, anything received without evaluation in 5 days. Sample latency is the single biggest source of project delay.

3. Tooling not paid + production blocked — usually a finance signoff issue rather than a supplier issue. Resolve it the same day.

4. POs landing this week — confirm QC inspection scheduled, confirm freight booked, confirm warehouse receiving capacity.

5. Reorder triggers — any active SKU within 30 days of stockout if reorder doesn't fire this week.

Thirty minutes done well prevents three hours of fire-fighting later in the week.

Frequently Asked Questions

How many SKUs can each implementation handle?

Excel comfortably handles up to ~50 active SKUs before performance and concurrency become real issues. Notion comfortably handles 200+ if database design is good. Airtable handles 1,000+ on the Pro tier. For most e-commerce brands under $10M in revenue, any of the three works.

Can I migrate between them later?

Yes, but it's painful. Excel → Notion is moderate (paste tables, redo formulas as Notion formulas). Excel → Airtable is easy (CSV import). Notion → Airtable is hardest (manual rebuild). Pick once, well, rather than planning to migrate.

What about ERP systems like NetSuite or SAP for sourcing tracking?

ERPs are built for downstream execution (POs, receiving, inventory, accounting). They lack good fields for upstream supplier development (sample versioning, tooling status, qualification stage). Most ERP-using brands still maintain a separate sourcing tracker for the pre-production pipeline and feed approved suppliers/SKUs into the ERP only after qualification.

How do I handle multi-supplier sourcing for the same SKU?

One row per SKU × supplier combination. So if Supplier A makes 60% of SKU X and Supplier B makes 40% (dual-sourcing), that's two rows. The tracker shows you both rows when filtered by SKU X.

What if my team won't update the tracker?

This is almost always a "no named owner per row" problem combined with "no weekly review" problem. Adding both fixes most adoption issues. If a specific person consistently doesn't update, the question is whether sourcing is actually their responsibility or whether the org chart implies it without saying it.

Should suppliers see the tracker?

Generally no. The tracker contains pricing across suppliers, qualification notes, and dual-sourcing strategy that you don't want any single supplier to see. If a supplier needs status updates, build a per-supplier shared view that filters to only their rows — both Notion and Airtable support this. Excel can't really.