Items flipped from active -> delisted in the last 7 days. Direct shelf-loss; chase reasons within 24h.
At a glance
Count of items in the supplier’s Costco catalogue that flipped fromactivetodelistedin the last 7 days. Each delisted item is direct shelf-loss: Costco buyers will not order it on the next PO cycle, the velocity revenue stops, and re-listing requires a new buyer-meeting commitment. Costco’s delisting decisions are made at the buyer-team level (each Costco merchandise category has a dedicated buyer who curates the SKU range); the supplier learns about delistings through the Costco item-master sync feed, not through advance notice. This card is the supplier’s only systematic early-warning of ranging changes.
Calculation
Calculated automatically from your Costco SIP data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The same US household-goods supplier on Costco SIP, around 84 active items in the catalogue across 4 Costco merchandise categories. Reading taken at 09:00 PT on Monday 09 Mar 26 for the trailing 7 days (02 Mar 26 to 08 Mar 26).
The card reads 3; alert at
>0 is firing. Five things to notice:
- Three delistings is meaningful, even though the count looks small. The estimated revenue at risk (units × ASP) is roughly
1,840 × 18.99 + 920 × 9.49 + 480 × 24.99 = USD 55,378 per week. Annualised at typical buying cadence that is around USD 1.4M of shelf revenue gone unless reversed. - Read the reason codes carefully because each implies a different action. (a)
velocity_below_thresholdfor the paper towels is the hardest to reverse: Costco buyers cut on velocity, and arguing the velocity was depressed by an off-shelf situation (recent stock-out, location reset) is the only path back. Pull the Fill Rate history for that item to make the case. (b)category_review_cutfor the toothbrushes is a “we are refreshing the range” cut, not a performance cut; the supplier should propose an alternative SKU at the next buyer meeting. (c)case_pack_changefor the glass storage is a process failure on the supplier side: the supplier did not update the case-pack on Costco’s deadline, Costco delisted automatically. This is recoverable by submitting the corrected case-pack via item-master update and asking the buyer for re-activation. - The delisting reasons cluster matters more than the individual reasons. If 3 of 5 weekly delistings are
velocity_below_threshold, the supplier has a whole-portfolio velocity issue (pricing, packaging, location) that needs commercial response. If 3 of 5 arecase_pack_changeorgtin_invalid, the supplier has a data-quality issue that needs operational response. - The 7-day window is operational not strategic. Use the rolling 30-day count for trend (typical SIP suppliers see 2 to 8 delistings per quarter depending on portfolio size); use this 7-day count to drive the same-week buyer-conversation queue.
- Pair with Item Delisting Burst (24h) for clusters. A 3-in-a-week count distributed evenly is normal portfolio churn; a 3-in-24-hours cluster is a category-wide review event and needs an urgent buyer call to understand the strategic context.
Sibling cards merchants should reference together
Items Delisted is the shelf-loss dial. Pair with these for the full ranging picture:Reconciling against the vendor’s own dashboard
Where to look in Costco’s own portal: Costco Supplier Portal → Item Master → My Items filter to Status: Delisted, Last 7 days. The portal exposes the same item-master records the card reads via the API or SFTP feed. Counts should reconcile to the unit; gaps usually mean the supplier’s item-master ingest is stale. Why our number may legitimately differ from Costco’s portal:
Cross-connector reconciliation:
Known limitations / merchant FAQs
An item showed as delisted yesterday and is back to active today. Did the dial double-count? The card counts active → delisted transitions in the period; if Costco reactivated the item, the active → delisted transition still counts. The reactivation is good news for the supplier but does not zero the delisting event. Use the drill-down to see the status-change history for each item. Costco delisted an item without a reason code. How do I find out why? Direct buyer conversation is the only path. Reason codes are populated for the most common Costco-side automated flags (velocity_below_threshold, gtin_invalid, compliance_failure); buyer-team curation cuts often arrive with no code. Email the buyer within 1 to 2 days of delisting; later than that the buyer has typically moved on and reactivation conversations need a new commitment cycle.
My item shows delisted but customers can still buy it on costco.com. What gives?
Two possibilities. (1) In-store delisting only. Costco’s warehouse-club shelf and costco.com online range are managed separately by different buyer teams; an item can be delisted from warehouse-club while remaining listed online (or vice versa). The item-master flag in this card reflects the warehouse-club status by default. (2) Existing inventory sell-through. A delisted item is no longer ranged for new POs, but Costco may still be selling through inventory in stores or DCs for several weeks; the consumer-facing experience lags the buyer decision.
Should I treat velocity_below_threshold differently from category_review_cut?
Yes. velocity_below_threshold is a performance-based delisting; reversal requires presenting evidence that velocity was depressed by an explainable cause (off-shelf, location reset, pricing) and proposing a fix. category_review_cut is a strategic decision; reversal is harder because the buyer has decided to refresh the range, but the supplier can propose an alternative SKU. Different reasons, different conversations, different probability of reversal.
The dial says 3 delisted but the supplier portal says 5. Why the gap?
Most likely two of the five were pending_review → delisted transitions where the pending-review state lasted longer than the supplier’s item-master sync cadence (24 hours typical). The portal shows 5 because it can see all 5 transitions; the card may show 3 because the sync only saw the active → delisted snapshot for 3 of them. Force a refresh or extend the integration look-back window.
Costco issued a case_pack_change delisting. The case-pack changed because Costco asked us to change it. Why are we being delisted?
Process gap. Costco’s request for a case-pack change goes through the buyer; the supplier needs to update the case-pack in Costco’s item-master through the corrected item-master sync file before the deadline. If the supplier does not update by the deadline, Costco’s automated process delists the old case-pack record. The fix: submit the corrected item-master, request reactivation through the buyer; reversible within 2 to 4 weeks if caught quickly.
Can I prevent gtin_invalid and compliance_failure delistings?
Mostly yes. (1) gtin_invalid triggers when the GTIN on the item-master record fails check-digit validation or is duplicated across items. Add GTIN validation to the supplier’s item-master submission process; this prevents most occurrences. (2) compliance_failure triggers when Costco’s compliance team flags an item for label, claim, or testing-document gaps. Maintain compliance documents (FDA, FCC, CPSC as applicable) and refresh annually. Both classes of delisting are usually preventable through process discipline; velocity_below_threshold and category_review_cut are commercial decisions and require commercial response.
My delisted-count is consistently rising over months. What do I do?
Treat as a strategic signal. Rising delisting count suggests the portfolio is losing buyer favour systematically (range refresh underway, competitor encroachment, pricing pressure, packaging dated). Three responses: (1) commission a portfolio review with the Costco buyer team for next quarterly meeting, (2) prioritise new SKU proposals to backfill the cuts, (3) review pricing and packaging vs the categories the buyer is favouring. The dial is the symptom; the buyer relationship is the lever.
Does the count include items delisted from costco.com but still active in warehouse-club?
The default integration scope is the unified item-master record, which has separate flags for warehouse-club (is_active_warehouse) and online (is_active_online). The card reads the consolidated current_status which goes to delisted only when both flags are off. Configure the integration to read either channel separately if your business case differs.
Should I get paged on every new delisting or only on bursts?
Every delisting, but route to a Slack channel or Jira queue rather than a phone-page. The 24-hour response window is operationally important (buyer conversations are easier same-day than 5 days later) but a single delisting is not a P1 incident; bursts (>3 in 24 hours) are P1 and warrant the Item Delisting Burst (24h) alert.