By the time an inventory problem is obvious to everyone, the decision that could have prevented it is usually already behind you.
A hero product is selling faster than anyone planned, and a paid campaign is still pointing customers straight at it. The same unit shows as available on your website and on Amazon, so you sell it twice and disappoint someone. A slow seasonal line quietly ties up cash and shelf space nobody wants to talk about. An inbound container slips by a week, and no one flags it until customers start seeing "notify me" on half the size run. Finance sees the margin damage after the fact. The merchandising team sees it in next week's review. Operations saw the first sign, but it was living in a spreadsheet tab or a supplier email.
The issue is rarely a missing dashboard. Most retail and ecommerce teams have plenty of those. The issue is that stock, demand, campaigns, and margin get looked at in different places, on different days, by different people, so no one sees the single thing that decides the week: where sellable stock and real demand are about to pull apart, and what to do about it before customers feel it.
This guide is written for the person who owns that weekly call. You might be a head of merchandising, an ecommerce or planning lead, or an operations manager at a retail or consumer brand selling across its own site, one or two marketplaces, and a set of physical doors. It should be useful even if you never talk to us, and it stays deliberately practical rather than becoming a theory of supply chains.
See sellable stock and real demand in one view, before the week forces the call
The job of this workflow is not to forecast the year. It is to make the handful of allocation and campaign calls that matter this week while you still have room to make them. That means seeing, for the category in front of you, what you can actually sell right now and in which channel and location, which demand signals are real enough to move stock or spend behind, and who owns the next move when cover and demand disagree.
That is a narrower job than "inventory visibility" usually implies, and narrower is what makes it work. You are not trying to know everything about every SKU. You are trying to catch the few situations where a decision this week prevents a fire drill next week.
A quick test for the next weekly read
Pick one SKU that surprised you last month. Can you see when the signal first appeared, who saw it, what move was available at the time, and why that move did or did not happen? If you cannot answer that, your weekly read is reporting history rather than shaping the decision.
This is also why the read sits so close to the weekly merchandising review workflow. The same meeting that sets price, promotion, and range needs stock and demand in the room at the same time, or it ends up deciding half-blind.
"In stock" is five different numbers once you sell across channels
The first word that breaks in a multi-channel business is "available." A single number on a screen quietly hides several very different realities, and the gap between them is where oversells and phantom stockouts come from.
| What the label says | What it can actually be | Where the truth goes missing |
|---|---|---|
| Available | Reserved against unshipped orders, ring-fenced for another channel, sitting in a store back room, or already picked but not shipped | Between the order system and each channel's own feed |
| In transit | On the water, stuck at customs, at the warehouse dock, or received but not yet put away | Between the purchase order in the ERP and the receipt in the warehouse |
| Sellable | Missing a size in the run, above a channel's safety buffer, or blocked by a quality hold you cannot see from the storefront | Between the catalog and the physical count |
| Returned | Back in the building but not yet inspected, restocked, or written off | Between the returns queue and the sellable pool |
| In stores | Spread thin across many doors, so the total looks healthy while every individual location is nearly empty | Between a headline count and the per-location reality |
None of this is exotic. It is the normal state of a brand that grew one channel at a time and never reconciled what "sellable" means across all of them. The first real improvement is a single honest pool of stock per SKU per location, with those states separated so a number on the screen means one thing.
Decide how much sellable stock each channel and location actually gets
Once you can see one honest pool, the next question is how much of it each channel is allowed to sell. This is the part that gets skipped, and it is specific to selling in more than one place at once.
If your website, your marketplace listings, and your stores all draw from the same physical stock without any allocation, you are effectively racing yourself. A promotion on the site can empty the pool that a marketplace listing was counting on, and a marketplace stockout can suppress a listing for weeks even after you restock. So each channel needs a deliberate share: a buffer that keeps a fast marketplace from going dark, a floor that keeps your best stores from looking empty, and a slice you can hold back when a promotion is about to land.
The point is not to freeze stock in place. It is to make the split a decision you revisit in the weekly read, not an accident of whichever channel sold fastest that morning. When demand shifts, you move the allocation on purpose, and you can see what you moved and why.
Demand is a blend of signals, not a single forecast
Demand is not one number either. Sales velocity over the last few weeks, seasonality, the lift you expect from a planned promotion, search interest and waitlist signups, size-curve completeness, and marketplace trend can all point in different directions for the same SKU. A product can be selling steadily while one size is already gone, which means your cover looks fine and your customer experience does not.
The useful move is not to model all of this at once. It is to read a small blend of signals well: how fast the SKU is selling now, what is scheduled to pull on it next, and whether the size or variant run is intact. Background references like Shopify's guides to inventory management and demand forecasting, and IBM's overview of demand forecasting, are a fair reminder that any forecast is only as good as the inputs and the review around it. In this workflow, the review is the point, and the forecast is one input among several.
Walk your current weekly read before you rebuild it
Before choosing tools or adding anything clever, map how the weekly read actually happens today. Not the version in a process document, the messy real one. In many retail and consumer businesses it looks close to this:
- Sales, stock, and returns reports are pulled from the ecommerce platform, the marketplace dashboards, the point-of-sale system, and the warehouse, each in its own format.
- Demand signals sit in separate places again: campaign calendars, search and waitlist data, customer-service tickets about unavailable sizes.
- Supply updates arrive as supplier emails, a purchase-order tracker, and warehouse notes about what really landed.
- Someone in merchandising or ecommerce stitches a weekly view together by hand, usually the night before the meeting.
- Exceptions get discussed, but ownership is inconsistent, so the same SKU comes up three weeks running.
- Actions happen in yet more tools: campaign changes here, a markdown there, a supplier chase, a product-page edit.
- Next week, the team tries to remember what was decided and whether it worked.
Writing this down is not about blaming anyone. It shows where the work leaks. Most of the pain lives in the handoffs, where a number leaves its source, loses its context, gets copied somewhere else, and then gets discussed by people who cannot see how much checking happened underneath.
Build the minimum weekly stock-vs-demand view
The first version should not try to see everything. It should help the team see the few decisions worth making this week, for one category, in one screen you open before the meeting rather than after the problem reaches customers.
| Column | The question it answers | Example for one SKU |
|---|---|---|
| Sellable stock by channel and location | What can we actually promise, and where is it? | 1,240 units: 700 web, 300 Amazon, 240 held for stores |
| Cover | How long does that stock last at the current selling rate? | 2.1 weeks and falling |
| Demand signal | What is about to pull on this SKU? | Promo Friday, search up, one size already gone |
| Commercial context | Is this worth protecting? | 62 percent margin, hero SKU, low return rate |
| Exception | What kind of problem is this? | Stockout risk before the promo lands |
| Owner and next move | Who does what, by when? | Ecommerce caps ad spend; ops pulls 200 from store reserve |
| Feedback | Did the move actually work? | Oversell avoided, promo held to plan |
That is enough to change the conversation. The team stops asking "what happened?" and starts asking "what needs a decision now, and who owns it?" Everything else you might add later is a refinement of this.
Connect cover, demand, and margin so the read is honest
A cover number on its own can mislead you. Three weeks of cover on a healthy-margin hero product heading into its best season is a very different situation from three weeks of cover on a returns-heavy line you are trying to exit. The read gets honest when cover, demand, and margin sit next to each other, so the team can tell the difference between stock you should protect and stock you should clear.
Sell-through is usually the sharpest single lens here, because it exposes the slow movers before the markdown clock forces your hand. Shopify's note on sell-through rate is a reasonable primer, but the practical work is putting sell-through beside cover and margin in the same weekly view, so a low sell-through, high-stock, rising-return line is flagged for a price and page decision while a high-velocity, thin-cover, high-margin line is flagged to protect and replenish. Both are exceptions. They just want opposite moves.
Decide the moves the weekly read is allowed to produce
A read that only produces observations is a report. What makes it a workflow is a short, agreed set of moves the team can actually make when an exception fires. In a multi-channel retail setup, those moves are usually some version of the following: rebalance stock between channels or between stores and the warehouse; expedite or split an inbound order; pause, shift, or boost a campaign so paid demand matches real cover; change what the product page promises, including delivery dates and available sizes; mark down or bundle a slow line before it costs more; or hold and watch when the signal is not strong enough to act on yet.
The value is in naming these in advance and attaching each to an owner, so the meeting produces assignments rather than opinions. Campaign moves in particular should not live in a separate conversation from stock, which is where the lifecycle campaign operations workflow connects: the same exception that says "thin cover before Friday" should be able to reach whoever controls the spend, in time to matter.
Give the weekly read a fixed slot on the calendar
The read needs a standing slot, and the slot needs to sit before the decisions it feeds, not after. If your campaigns go live on Monday and your purchase orders cut on Wednesday, the read belongs on Friday of the week before, so there is time to move stock, adjust spend, or chase a supplier before anything is locked.
Keep it short and focused on exceptions. The people who need to be there are whoever owns stock, whoever owns demand and campaigns, and whoever can move inbound orders, which usually means a merchandising or planning lead, someone from ecommerce, and someone from operations. Thirty minutes on the SKUs that are pulling apart is worth more than an hour walking every line that is fine.
A worked example: one beauty retailer across site, Amazon, and 40 doors
Say a beauty retailer sells one hero serum through its own site, its Amazon listing, and about 40 department-store doors, all drawing from a single distribution center. The numbers below are invented to show the shape of the read, not a benchmark to copy. On Friday, the weekly view for that one SKU looks like this.
| Channel | Sellable stock showing | Weekly demand | Weeks of cover | Read |
|---|---|---|---|---|
| Website | 1,500 | 620 | 2.4 | Thin before the weekend promo |
| Amazon | 900 | 700 | 1.3 | Close to a stockout and listing suppression |
| 40 doors | 2,100 (about 52 each) | 480 | 4.4 | Overstocked in stores while online runs hot |
Read as one picture, the story is clear in a way it never is when these three lines live on three dashboards. The stores are sitting on more than four weeks of a product that is selling out online, and the promo scheduled for the website is about to make the online squeeze worse. Nobody did anything wrong. The stock simply landed where last quarter's plan sent it, and demand moved on. The read turns that into a short queue of decisions.
| SKU | Signal | Owner | Next move |
|---|---|---|---|
| Hero serum 30ml | Amazon cover 1.3 weeks with suppression risk; stores at 4.4 weeks | Merchandising and operations | Pull 300 units from the slowest doors back to the DC, lift the Amazon buffer, and hold the web promo one week |
| Holiday lip set | High stock, sell-through 12 percent, return rate rising | Category planner | Review the bundle page and price before any markdown, and check the return reasons first |
| Cleanser refill 200ml | Inbound container six days late; the size stocks out in four days | Operations | Confirm a partial receipt, update the delivery promise on the page, and pause paid ads on that size |
That is the whole point of the workflow in one screen. Three items, three owners, three moves the team can make now, while the moves are still cheap.
Fit the data and systems to the decisions
You do not need to integrate the whole retail stack to get here. You need enough clean data to trust the read for one category. In practice that means the sellable stock from your ecommerce platform or order system, the marketplace feeds, the point-of-sale counts from stores, the warehouse or third-party logistics view of what is really on hand and inbound, the open purchase orders from the ERP, the returns queue, and the campaign calendar.
The first version can run on scheduled exports rather than live connections, as long as everyone agrees the numbers are close enough to decide on. Connect the systems properly once the read has proven it changes decisions, and connect them in the order the decisions demand, starting with wherever "sellable" is currently most wrong.
Where AI helps, and where it must not decide
AI earns its place once the signal and the exceptions are clearly defined. It is not there to conjure a clean forecast out of messy inputs, and it should not be the thing that decides whether to reallocate, pause, expedite, or mark down.
Where it genuinely helps is in the preparation. It can read supplier emails, purchase-order notes, and warehouse exceptions and turn them into a short summary. It can flag the SKUs where velocity, cover, and the campaign calendar are about to conflict, so those float to the top of the read. It can group similar exceptions so the team acts by cause rather than one SKU at a time, draft the weekly exception note for merchandising, ecommerce, and operations, and point out that this same stockout has now appeared three months running. Used that way, it shortens the hour someone spends assembling the view and leaves the decision where it belongs, with the person who can see the whole picture and owns the outcome.
The failure modes that keep you firefighting
A handful of patterns keep teams reacting instead of deciding. The most expensive is treating the same physical stock as if it belongs to every channel at once, which produces oversells and disappointed customers no dashboard warned you about. Close behind is phantom stock, where the count says you have units and the shelf does not, usually because returns, holds, or store shrink never made it back into the number.
Then there is the size-curve trap, where a SKU shows healthy cover while the size people actually want has been gone for a week. There is the campaign planned entirely from a marketing calendar with no glance at cover, so paid demand arrives at an empty shelf. There is the safety buffer that someone set once, a year ago, and never revisited as the channel mix changed underneath it. And there is the quietest one of all: the weekly meeting that ends with a page of observations and no owner, so the same problems come back the following week wearing a different SKU number. A useful workflow is not the one with the most data. It is the one that turns each of these into a named move soon enough to matter.
What to measure
Keep the measures close to the decisions, not to the dashboard. The ones worth watching are the stockouts you caught before customers hit them, the oversell incidents you avoided across channels, the overstock and slow-mover lines you actioned before the margin eroded further, and the campaigns you paused or shifted because cover changed. It is also worth tracking the manual hours spent assembling the category view each week, because that is the cost you are directly buying back.
Those numbers connect straight to the cost of manual analysis and late decisions. Ubisar's guide to the cost of manual work can help you estimate where that effort is worth fixing first, so you start with the category where the read pays for itself fastest.
The first month: make one category visible before you scale
Do not try to make the whole catalog visible in month one. Pick one category where stockouts, overstocks, or margin pressure hurt enough to be worth the effort, and build the read there.
- Choose one category, channel, or SKU group where the pain is real and recent.
- Map the weekly journey from demand signal to inventory decision for that group.
- Define the first exceptions: stockout risk, oversell risk, overstock, supply delay, margin risk, campaign conflict.
- Build one trusted sellable-stock and demand view from current exports or a first system connection.
- Create an owner-and-move queue for the weekly read, so exceptions leave the meeting with names attached.
- Add one feedback field so the team can see, next week, whether the move worked.
- Add AI support only where it summarizes or classifies exceptions, not where it decides them.
By the end of the month, the team should have a view it opens before the weekly decision meeting, not a dashboard it checks after the problem has already reached customers.
How Ubisar would implement this workflow
In week one, we would pick one category or product family and trace the journey from demand signal to inventory decision: velocity, sellable stock by channel and location, reserved and inbound stock, fulfillment constraints, margin, the promotion plan, and who escalates when cover and demand disagree. The first output is one weekly stock-and-demand view with the fields the merchandising, ecommerce, operations, and finance teams need to trust before they act.
In weeks two and three, we would connect the minimum order, inventory, warehouse, purchasing, and margin data that view needs, then build the exception queue around stockout risk, oversell risk, overstock, promise risk, and margin exposure. AI would help classify exception reasons and summarize what changed week to week, while allocation, replenishment, and promotion decisions stay with your team. By week four, the team should be able to run one weekly read without rebuilding the same stock story by hand.
At the end of the first month, keep going if the category team can see decisions earlier and argue about stock less; stop or narrow it if the counts or the ownership still are not trusted. We would treat this as a consumer and retail workflow and connect it, when it helps, to the lifecycle campaign operations workflow. If that weekly call is the one you keep losing, it is exactly the kind of workflow the AI, Data and Tech Implementation Service is built to fix, and you can tell us about yours on the contact page. You can also browse the workflow guide library or read how to choose the first workflow to improve with AI.