The weekly merchandising review has a familiar shape. Someone shares a screen, the group walks through sell-through, stock cover, margin, returns, and channel mix, a handful of products get discussed, and the meeting ends on time. Everyone was in the room, plenty of numbers were on the screen, and yet by Thursday nobody is quite sure which products actually got a decision, who was supposed to act, or whether anything moved.
The problem is rarely a shortage of data. Most retailers have more product reporting than anyone can read in an hour. The problem is that the meeting tours dashboards instead of producing decisions, and the few decisions it does produce tend to leak out before the next week. A more useful review starts from a narrower question: which products need an action this week, who owns each one, and what evidence supports the call? Once that question drives the meeting, the reporting around it can get much lighter and far more useful.
This guide is written for the person who owns that meeting: a merchandising lead, a head of ecommerce, a category owner, or an operations lead in a consumer and retail business who is tired of leaving the review with a full notebook and an empty action list.
The weekly meeting is not the workflow
It is tempting to fix the review by fixing the meeting: tighten the agenda, cut the slides, ask each function to send a cleaner update. That helps a little, but it treats the meeting as the whole job. The meeting is only the last visible step. The real work runs from a product signal to an owned decision. Something changes on a SKU, someone notices, the team weighs the evidence, a merchandiser or category owner makes a call, that call gets an owner and a due date, and the following week checks whether it worked.
When people say the review is not working, they usually mean one of the links in that chain is missing. The signal never surfaces until margin has already slipped. The evidence is scattered across four systems, so the conversation stalls on "let me check and come back." The decision gets made in the room but never leaves it. Improving the deck does nothing for any of those, which is why teams redesign their reporting every year and still feel behind.
What the review is actually protecting
Strip away the dashboards and a weekly merchandising review exists to protect four things: revenue, margin, product availability, and the customer experience around the product. Every decision the meeting should make is really a trade between those. Bring a reorder forward and you protect availability but tie up cash. Clear slow stock with a markdown and you protect cash but give up margin. Feature a product that is already short on cover and you protect this week's sales while risking a stockout mid-campaign.
Those trades are the point of the meeting. A review that only reports what happened has skipped the part that matters. The version worth building helps the team decide, product by product, whether to reorder, reprice, feature, substitute, investigate, pause, or retire, and it makes each of those a decision someone owns rather than a number someone read out.
Follow one week from product signal to owned decision
Before changing any tools, map the review as it really runs, not the version in a process document. Pick one recent cycle and trace it. Where did the SKU list come from? Who decided which products were worth discussing? Who checked inventory and open purchase orders? Who explained why conversion dropped on a product with steady traffic? Who owned the pricing or promotion call, and who wrote down what was agreed?
The awkward moments almost always sit at the handoffs between merchandising, ecommerce, marketing, supply chain, finance, and customer service. One team sees weak conversion. Another sees a stock risk. Another sees a spike in returns or service contacts. Each of those teams can make a perfectly reasonable local decision and still produce a worse commercial outcome together, because nobody joined the signals up. Marketing pushes a product that supply already knows is about to run out. Merchandising drops the price on an item whose real problem is a returns issue that a discount will not fix.
Mapping this is not about assigning blame. It is about seeing where product context gets lost between systems and people, because that is where the review either earns its place or becomes a weekly reading of numbers.
Where the weekly review quietly breaks
Merchandising reviews tend to fail in the same few places. Naming them makes the fix obvious.
The meeting reviews every SKU instead of the ones that need a decision
A review that scrolls through the whole catalog spends its energy on products that are fine. The team runs out of attention before it reaches the ten or fifteen SKUs that actually need a call this week. Coverage feels thorough and changes nothing.
The signals live in separate meetings
Inventory is discussed in the supply call, margin in the finance review, returns in a service report, and conversion in the ecommerce standup. By the time those threads reach the merchandising review, they are summaries of summaries, and the connections between them are gone.
Margin is reviewed after the money has already leaked
Reported margin often lands below plan for reasons the weekly numbers do not explain on their own: unplanned markdowns to clear stock, a higher return rate on a specific product, a channel mix that drifted toward a lower-margin marketplace, freight or fulfillment costs that crept up, or a promotion stacked on top of an already reduced price. Each of these is small at first and easy to miss for weeks.
The dashboard becomes the artifact
Teams pour effort into one perfect merchandising dashboard and treat building it as the goal. But a dashboard shows state, not decisions. If the actions from the review live in someone's notebook while the dashboard lives on a screen, the polished view is doing none of the work.
Decisions never leave the room
The meeting agrees to move a reorder forward, adjust a discount rule, and rewrite a product page. A week later, none of it is done, because nobody wrote down the owner and the due date. The review quietly becomes a discussion group.
AI gets pointed at commentary before the decisions are defined
It is easy to ask a model to summarize the week's product movements. But a fluent summary of the wrong things just adds reading. If the team has not decided which product decisions the review exists to make, automating the commentary makes the meeting longer, not sharper.
The smallest useful fix is a SKU exception board
If you change one thing before touching any system, change what the meeting looks at. Instead of the full catalog, bring a short list of products that need a decision this week. Think of it as a SKU exception board. It does not show everything. It shows each flagged product, the reason it was flagged, the evidence behind the flag, the recommended action, the owner, and where the follow-up stands.
The exception types that earn a place on the board are the ones that map to a real decision: low stock cover, excess stock, weak sell-through, margin below target, a return spike, a drop in conversion, a jump in service contacts, a promotion conflict, a supplier delay, or a product performing very differently across channels. If a flag does not point to a decision someone could make this week, it does not belong on the board.
Here is what a handful of rows might look like in practice.
| SKU signal | Why it matters | Owner | Decision to make |
|---|---|---|---|
| High sell-through, low remaining cover | Stock may run out before the campaign ends | Merchandising with supply planning | Bring replenishment forward or reduce promotion exposure |
| Traffic steady, conversion falling | The product page, price, or reviews may be hurting demand | Ecommerce lead | Review the page content, price, reviews, and recent return reasons |
| Margin below target after discounts | Sales volume is masking profit leaking out per unit | Merchandising with finance | Adjust the discount rule before the next review |
| Return rate rising on a single line | The reported margin is worse than the sell-through suggests | Merchandising with customer service | Find the return reason before repricing or reordering |
The board is deliberately small. Ten to twenty products is a working review. Forty is a reading exercise. The discipline of choosing what makes the list is most of the value, because it forces the team to agree what a product decision even looks like this week.
Connect product, inventory, margin, and customer data after the board is clear
Once the exception board exists, connect the systems behind it, and do it in that order. Building the data plumbing first tends to produce a beautiful merchandising dashboard that answers questions nobody is asking. Designing the decisions first tells you exactly which fields each exception type needs.
A stockout risk and a margin problem do not need the same evidence. Trying to load every field for every product is how the dashboard becomes the artifact. Define the evidence by exception type instead, so the person who owns the decision sees what they need and not much else.
| Exception type | The decision behind it | Evidence the owner actually needs |
|---|---|---|
| Stockout risk | Reorder, expedite, or ease promotion | Current stock, sell-through rate, open purchase orders, supplier lead time, substitute options |
| Excess stock | Clear, hold, or slow future orders | Weeks of cover, aging, seasonality, current margin, cost of holding |
| Margin below target | Reprice, adjust discount rule, or change channel mix | Unit cost, discount depth, channel mix, return rate, freight, promotion history |
| Conversion drop | Fix the page, the price, or the availability | Traffic, price, product content, stock status, reviews, common return reasons |
Most of this data already exists across ecommerce analytics, point-of-sale or order records, inventory and purchasing, the product catalog, margin and cost data, returns, service tickets, the promotion calendar, and marketing channel reports. The work is not collecting more of it. The work is joining the few fields each decision needs so the review stops stalling on "I will have to check and come back."
Why margin surprises show up late
Margin is the number that most often disappoints after the fact, and it is worth understanding why, because the weekly review is the best place to catch it early. A product can sell well all month and still land below its margin target, and the weekly sell-through view will look fine the whole time.
The leaks are usually small and cumulative. A markdown taken to clear slow stock trims a few points. A return rate that ran a little hot on one line quietly turns sold units into costs. A shift in channel mix toward a lower-margin marketplace moves the blended number without any single product looking wrong. Freight and fulfillment costs creep up. A promotion gets stacked on a price that was already reduced, so the real discount is deeper than anyone intended. None of these is dramatic on its own. Together they explain the gap between the margin the team expected and the margin the finance report shows a month later.
A weekly review that watches margin at the product level, not just revenue, catches these while they are still a few points instead of a quarter-end surprise. That is the whole argument for looking at margin per SKU every week rather than once a month when it is too late to steer.
Match the decision to the right team
An exception board is only useful if each flagged product goes to whoever can actually act. The decisions themselves stay firmly with your people. Pricing, markdowns, promotions, and the call to drop a SKU belong to your merchandising and marketing teams, not to a tool and not to an outside firm. The workflow's job is to get the right product, with the right evidence, to the right owner while there is still time to decide.
| Decision | Who owns it | What they need to see |
|---|---|---|
| Reorder or expedite | Merchandising with supply planning | Cover, demand trend, lead time, open orders |
| Reprice or adjust a markdown | Merchandising with marketing | Margin, discount depth, competitor context, aging |
| Feature or promote | Marketing with merchandising | Available cover, margin headroom, campaign calendar |
| Fix the product page or price | Ecommerce | Traffic, conversion, content, reviews, return reasons |
| Substitute or resource | Merchandising with supply | Alternatives, cost, availability, customer fit |
| Drop or retire a SKU | Merchandising | Long-run sell-through, margin, cover, replacement |
Writing the owners down like this does something quiet but important. It stops the review from being a place where everyone agrees a product is a problem and no one leaves responsible for it.
Give every flagged product an owner and a follow-up state
The review only improves anything if decisions leave the room. Each product on the exception board should carry an owner, a due date, a short status, and, next week, a result. The status does not need a heavy project tool behind it. A short set of states is enough: new, investigating, action agreed, waiting on a dependency, done, watch next week, closed. The point is simply to stop losing decisions the moment the meeting ends.
Next week, the board opens with last week's flagged products and what happened to them before it moves to anything new. That single habit, checking the previous decisions first, is what turns a weekly meeting into something that compounds. Without it, the same three products get discussed every week and nothing changes.
A worked example: one week on a home-goods category
To make this concrete, here is an illustrative scenario. The company and numbers below are invented to show the shape of the work, not a real client or real results.
Say an omnichannel home-goods retailer with about 2,400 active SKUs runs a Monday merchandising review that regularly overruns and rarely ends with clear actions. The team starts small and rebuilds the review for one category, kitchen and dining, roughly 300 SKUs, before touching the rest.
In the first cycle, instead of walking all 300 products, they bring an exception board of the fourteen that need a decision. A popular ceramic dinnerware set is selling fast with only about two weeks of cover left, and a marketing feature is planned for next week, so merchandising and supply agree to bring the reorder forward and hold the feature until stock lands. A mid-price cookware line shows steady traffic but falling conversion; ecommerce takes it to check the product page and finds three recent reviews complaining about a lid that does not fit, which also explains a small rise in returns, so the real fix is the supplier and the page, not a discount. A seasonal serveware item is running well below its margin target, and when the team looks past revenue they see a promotion stacked on an earlier markdown, so merchandising adjusts the discount rule before the weekend.
None of those calls needed a new system. They needed the right fourteen products, the evidence behind each flag in one place, and an owner with a due date. The next week's review opens by checking those three decisions before adding anything new. By the fourth week, the kitchen and dining review reliably ends with owned actions, and only then does the team consider extending the same board to a second category.
Where AI helps inside the review
AI is genuinely useful in this workflow when it reduces the manual assembly before the meeting and helps the team see what changed. It can summarize how SKUs moved week over week, group similar product issues so the same underlying problem is not discussed five times, draft first-pass notes from approved data, flag unusual changes that a person might scroll past, and turn the meeting's decisions into a clean action list with owners and dates. It can also compare this week's exception board against prior weeks so repeat offenders stand out.
What it should not do is decide markdowns, promotions, reorders, or supplier changes on its own. Those calls depend on context a model does not have and on trade-offs your team is accountable for. The safe pattern is to let AI prepare the review and cut the manual work, while a merchandiser or category owner makes the decision from evidence they can see and trace back to its source.
Where human judgment keeps the decisions sound
Some parts of the review should stay firmly with people, and it is worth being explicit about which. A merchandiser needs to weigh whether a slow product is genuinely dead or simply between seasons before recommending a drop. Someone has to judge whether a margin dip is a real problem or a deliberate, temporary trade to clear stock. Return spikes need a human to find the cause, because a discount aimed at a product whose real issue is a sizing or quality complaint just sells more of a problem. And any decision that touches price, promotion, or a supplier relationship carries commercial consequences that belong to your team, not to a tool that summarized the week.
The goal is not to remove judgment from merchandising. It is to stop spending that judgment on copying numbers between systems and reconstructing what was agreed last week, so the team has energy left for the calls that actually need it.
What to measure
Two kinds of measures tell you whether the review is working. The first are about the workflow itself: how many exceptions were reviewed, how many had a named owner, how many actions were completed before the next review, how often the same product came back unresolved, and how many decisions stalled because a number was missing. The second are commercial, tracked for the products that entered the exception board: sell-through, stock cover, margin movement, return rate, conversion, and service contacts. If flagged products are steadily improving on those while fewer decisions stall, the review is earning its hour.
To size the manual effort behind today's review before you change anything, the AI automation ROI guide and the Workflow Readiness & ROI Calculator are a useful starting point.
Common traps
A few mistakes show up in almost every merchandising review that is not working. Teams review every SKU instead of the products that need a decision, and run out of attention before reaching the ones that matter. Inventory, margin, returns, and customer feedback stay trapped in separate meetings, so no one sees the product where all four point the same way. The dashboard becomes the deliverable while the actions live somewhere else entirely. AI gets pointed at writing commentary before the team has agreed which decisions the review exists to make. And the meeting closes without a follow-up state, so the same products resurface next week untouched. None of these is exotic, which is exactly why they are easy to keep repeating.
The first month should rebuild one weekly category review
Do not try to fix every category at once. Choose one category or product family where sharper weekly decisions would clearly matter, build the exception board for it, connect the minimum data, run the review from that board, and improve the action list after the first real meeting. One category done properly teaches you more than a site-wide rollout that stalls.
| Week | Focus | What should exist by the end |
|---|---|---|
| Week 1 | Map the current review as it really runs | The real meeting, reports, owners, and the product questions that recur |
| Week 2 | Define the exception board | Exception types, thresholds, the evidence each needs, and the action states |
| Week 3 | Connect the minimum data | The few fields each exception type needs, joined for one category |
| Week 4 | Run the review from the board | A meeting that ends with owned actions and a follow-up on each |
If you are unsure whether the merchandising review is even the right first workflow to rebuild, the guide on choosing the first workflow to improve with AI walks through how to pick.
How Ubisar would implement this workflow
In week one, Ubisar would choose one category with you and follow its weekly review from SKU signals to decisions: sales, stock cover, margin, traffic, conversion, returns, promotions, customer feedback, and whatever actions are still open from last week. The first thing we would build is a SKU exception board with, for each flagged product, the signal, the threshold that flagged it, the data source behind the evidence, the owner, the action status, and the next review date.
In weeks two and three, we would connect the minimum ecommerce, order, inventory, catalog, margin, campaign, returns, and service data those flags need, no more. AI would help summarize movement, group exception reasons, draft the review notes, and surface the follow-ups, while your merchandising and marketing teams keep every pricing, stock, content, and promotion decision. By week four, one category's review should end with owned actions instead of a loose discussion, and you would decide from there whether to extend the same board to a second category.
At the end of the first month, the honest test is simple: keep going if the weekly review is catching margin and stock decisions earlier than it used to, and stop or narrow it if the team still cannot agree which products deserve a decision. That is the month-to-month way we work in AI, Data & Tech Implementation. If you would rather talk it through than read another guide, get in touch and we will reply within one business day. To compare doing this in-house against other routes, see AI consultant vs AI automation agency vs software, and to frame the budget, what AI implementation costs in 2026. More guides like this one live in the workflow library.