|
English

I'm a category buyer at a 240-store retail chain. I cover home goods — about 11,400 active SKUs across 14 sub-categories. Last month I ran an experiment I should have run two years ago: I logged exactly how long it took me to answer one question a buyer is supposed to be able to answer in seconds.

The question was: "What's the status of SKU 8821-N in the Northeast region?"

The answer required 47 browser tabs, 5 different systems, 38 minutes, and an embarrassing amount of mental math. Multiply that by the ~180 SKU status checks I do in a normal week, and the math gets darker fast. 114 hours a week on a four-person buying team, just answering questions our systems should already know how to answer.

We rebuilt the workflow. SKU status checks now take 9 seconds and give a better answer than I was producing manually. This is what we built, what it cost, and the $2.3M margin number that made the project an obvious yes.

The 38-Minute SKU Check

Here's the workflow I had to run, by hand, every time a planner or store manager asked about a SKU. None of it was optional. All of it was awful.

StepSystemTimeWhat I was doing
1WMS (warehouse mgmt)4 minLogging in, finding the SKU, pulling on-hand by DC
2Store inventory portal6 minPer-store counts across the 47 Northeast stores
3EDI/ASN tracking (Excel exports)9 minPulling in-transit shipments, parsing ASNs, calculating ETAs
4Supplier portal7 minChecking next promised delivery, lead time, allocation status
5Snowflake / BI tool8 min12-week trailing sell-through, regional skew, days-of-supply
6Mental synthesis4 minPulling it all together into "we have 11 days of cover and the next ASN is late, recommend expedite"

Total: 38 minutes per SKU. Each system had its own login, its own quirks, its own latency. The supplier portal would log me out after 15 minutes of inactivity, which happened roughly every other check. The EDI tracking exports were Excel files that someone in logistics regenerated every morning — if you needed an intra-day update, you were guessing.

The truly insulting part: the answer was almost always the same shape. "X days of cover. Next replenishment in Y days. Risk level: low/medium/high. Recommended action: hold/expedite/escalate." I was running a 38-minute query to fill in a four-line template.

The Margin We Were Bleeding

I went back to the planning team and asked them to pull every stock-out incident in home goods over the trailing 12 months that could have been prevented by an earlier expedite decision. The criteria: the data needed to make the call was technically available in our systems at least 48 hours before the stock-out, but nobody made the call because nobody had time to check that SKU until the empty shelf was already in a store manager's photo on Slack.

The number was 1,847 preventable stock-out events. At our average lost-sale value per stock-out day per SKU per store (we'd done this analysis for a different project), the total margin impact was $2.34 million in trailing twelve months. In one category. Across the chain, it's worse.

We weren't running out of stock because we didn't have the data. We were running out of stock because nobody had 38 minutes to look.

Why "Just Buy a Supply Chain Platform" Wasn't the Answer

I had this conversation with three different vendors in the first two weeks of evaluation.

Vendor 1: A traditional supply chain visibility platform. $480K/year minimum. 9-month implementation. Required us to push data from our WMS, our store inventory portal, and our supplier portal into their cloud, which our compliance team had concerns about. Did not integrate with our home-grown EDI tracking (which is a pile of perl scripts older than two of my analysts).

Vendor 2: A retail-specific AI platform. Cheaper, faster to deploy. But the data model was opinionated to the point of being unusable for our category structure — they wanted us to remap our hierarchy to theirs, which would have broken every existing report.

Vendor 3: An RPA vendor offering to record me doing the manual workflow and replay it. This was the most depressing demo. It would have worked. It would also have been a 47-tab screen-scrape that broke every time any of the five vendors pushed a UI update.

What I actually needed was a workflow that could talk to all five systems in their native protocols — not screen-scrape them, not import their data into another platform, just call each one directly and synthesize the answer.

What We Built

We built it on Swfte because the platform's five-tier integration model was the only one that mapped cleanly to the mess we were dealing with. (Here's the post that explains those tiers.) The workflow has five data-pull steps and one synthesis step, and it's exposed three ways:

  1. A Slack slash command: /sku 8821-N northeast returns the answer in the channel in ~9 seconds.
  2. A scheduled batch job that proactively checks the top 800 SKUs by velocity every 4 hours and posts any "high risk" results into a triage channel.
  3. A webhook trigger from our store inventory portal that fires automatically whenever any store crosses a low-stock threshold.

The data-pull steps, mapped to the connector tiers:

SourceIntegration tierWhat we pull
WMSREST bridge (Tier 3) over their internal APIDC-level on-hand, in-pick, in-receive
Store inventoryREST bridge (Tier 3)Per-store on-hand for the requested region
EDI/ASN trackingCustom code step (Tier 5)In-transit shipments, parsed from the EDI feed
Supplier portalCustom code step (Tier 5)Next-promised, lead times, allocation flags
SnowflakeDatabase adapter, named queries (Tier 4)12-week trailing sell-through, regional skew

Then the synthesis step hands all five payloads to an LLM with a system prompt that encodes our exact escalation rubric and returns a structured response: {days_of_cover, next_replenishment_date, risk_level, recommended_action, rationale}. The rationale is mandatory — same lesson as the lead-routing post, citations build trust.

The four data-pull steps run in parallel because none of them depend on each other. Total wall-clock latency: about 5.8 seconds for the data, plus 3.2 seconds for the synthesis, plus a few hundred ms for the Slack post. End-to-end 9 seconds. The previous workflow, again, was 38 minutes.

The Numbers, 11 Weeks In

We piloted in home goods (my category) for the first six weeks, then rolled out to apparel and seasonal in weeks 7–11. The numbers below are home goods only, because that's where I have the full before/after.

MetricBefore (manual)After (workflow)Delta
Time per SKU check38 min9 sec253× faster
SKU checks per buyer per week~1804,200+ (mostly automated)23× more coverage
% of high-velocity SKUs checked daily6%100%+1,567%
Stock-out events (home goods, trailing 90d)41289−78%
Preventable margin loss (annualized)$2.34M$510K−$1.83M
Buyer hours/week on status checks114 (4-person team)7 (review queue only)−94%
Expedite decisions made within SLA31%88%+184%
Mean time from low-stock signal to action14h 40m22 min40× faster

The number that made my GM physically lean forward in the readout: −$1.83M in preventable margin loss in one category in one year. Extrapolated across the chain's six largest categories, the addressable margin recovery is somewhere between $9M and $14M annually. The platform costs us about $5,400/month all-in. Payback period: roughly six weeks.

The other number that mattered more than I expected: buyer hours/week dropped from 114 to 7. Those 107 hours/week didn't disappear. We redirected them. The buying team now spends real time on supplier relationships, vendor negotiations, and category strategy — the work I was hired to do and hadn't actually done in two years because I was a human ETL job.

The Three Things I Was Wrong About

1. I was wrong about the supplier portal being unintegrable. I assumed for two years that because the supplier portal had no public API, no documentation, and no support contact who would return my emails, it was just out of reach. The custom code step (Tier 5 in the connector model) wrapped the portal's authenticated session and screen-scraped the three specific fields we needed, with retry logic and a 4-hour cache. It took our engineer 1.5 days. The platform didn't make this easier than it would have been in any framework — but having it as one tier of a unified workflow meant the agent didn't care that it was scraping. From the calling code, it looks like any other tool.

2. I was wrong about the AI being the hard part. I assumed the model would hallucinate, miscalculate days-of-cover, or get the regional skew wrong. It hasn't. The structured-output requirement plus the rationale field made it self-correcting — when the rationale didn't match the numbers, the model would re-think and produce a corrected answer. The hard part was the data integration. The AI was the easy part.

3. I was wrong about buyer adoption. I expected pushback from the team. "An AI is going to tell me when to expedite?" Instead, within a week, buyers were asking for more fields in the response, more SKU coverage, and more triggers. The reason is simple: nobody actually wants to do the 38-minute query. The 38-minute query was the job nobody wanted, and the workflow took it away.

What I Wish I'd Known Three Years Ago

The technology to do this has existed, in some form, for at least three years. What changed in the last 12 months is that the integration cost collapsed. Wrapping five disparate systems into a single agent-callable surface used to be a six-month integration project. The connector tiers in modern AI workflow platforms have turned it into a six-day project for a small team.

If you're a retail buyer, planner, or supply chain operator still running multi-tab status checks by hand in 2026, the right thing to do this week is the same thing I did: pick one SKU, time the manual check honestly, and multiply by your weekly check volume. Then pull 12 months of stock-out incidents and tag the preventable ones. The two numbers, side by side, are the entire business case.

Related reads:

0
0
0
0

Enjoyed this article?

Get more insights on AI and enterprise automation delivered to your inbox.