Apurv Adarsh

The Monitors team at Amazon Retail managed vendor relationships for monitor products across 5 Pan-EU markets, operating from Germany. Brand Specialists and Vendor Managers worked directly with vendors to optimise product flow — handling procurement deals, managing overstock through vendor-funded discounts, and running promotional activities to move inventory.

Their core job was to keep products selling efficiently. When a SKU showed overstock risk, they would negotiate vendor discounts, arrange promotions, or flag for transshipment. The quality of these interventions depended entirely on how early they could identify risk — and how accurate their read of that risk was.

The problem was upstream. By the time the retail system flagged a SKU as "unhealthy," the window for cheap intervention had already closed. The team was reactive by design because the tooling gave them no alternative.

Every week before the Monday WBR, one Brand Specialist spent 3–4 hours manually pulling monitor-specific data from Amazon's retail engine, running Excel analysis, identifying the top 5 SKUs at risk, and compiling a report for the WBR discussion.

The existing system flagged products as "unhealthy" — but the healthy/unhealthy binary was too coarse. A SKU with high unhealthy stock but a strong sell-through rate was actually fine. A SKU with moderate unhealthy stock but weak sell-through was a ticking clock. The existing signal couldn't tell the difference.

The relevant data existed — weeks of cover, sell-through rate, purchase order timing, unhealthy stock units — but it lived in separate places. No one had combined it into a single predictive signal. Brand Specialists and Vendor Managers weren't data analysts. They needed a decision, not a dataset.

Step 1 — Self-education first. Before talking to anyone, I went through Amazon's internal wiki and data documentation to understand the retail system, available metrics, and how inventory flow actually worked. I didn't walk into stakeholder conversations blind.

Step 2 — Observe the existing workflow. I sat with Brand Specialists and Vendor Managers to understand how they made decisions. The key question I asked: "After you see the WBR report, what other metrics do you check to validate it?" Their sequential mental validation process — checking weeks of cover, sell-through, PO data in order — became the foundation of the formula.

Step 3 — Validate with historical data. I pulled a historical sample and tested whether past decisions had been accurate using the existing signals. They hadn't — which confirmed the problem was real and the direction was right.

Step 4 — Map available data with BI. I sat with the BI team to catalogue every metric available in the retail engine — including a macro-level overstock prediction model that existed for Amazon-wide use but had never been adapted for team-level decisions.

Step 5 — Beta test before scaling. I ran weekly beta predictions alongside the existing manual process for 3–4 weeks, comparing my predictions against actual outcomes. Accuracy improved from 6/10 to 8/10 SKUs correctly predicted. Only then did I move to automation.

I deliberately staged the build in three phases. The team needed to trust the signal before we automated action on it. Shipping the full automated system before proving accuracy would have created business risk at scale.

Before: One Brand Specialist spent 3–4 hours every Monday morning manually pulling data, running Excel analysis, and compiling a top-5 overstock report. Decisions in the WBR were reactive — the team was discussing SKUs that had already entered markdown.

After: Monday WBR arrived with a pre-built automated report in every relevant team member's inbox. Decision accuracy improved by ~30%. Actions were assigned, tracked, and reviewed in a closed loop. Senior management had visibility into who acted and when. Discount spend on at-risk SKUs dropped 10–15% through earlier vendor intervention.