Text version of this lessonExpand
Many ecommerce teams do not lack data. They lack one operating rhythm. Paid media brings ROAS, operations brings SKU notes, support brings refund reasons, and leadership brings revenue numbers. The meeting becomes a round of explanations instead of a decision system. A weekly business review, or WBR, should put profit facts, path evidence, root causes, and next-week actions into one decision ledger.
Lesson output: one WBR decision ledger
After this lesson, you should be able to turn the weekly review into one checkable table: what changed, which evidence proves it, whether the issue is revenue, cost, page, product, support, or fulfillment, which team is responsible, when it will be reviewed, and which metric will judge progress.
| Review layer | Question to answer | Output to keep |
|---|---|---|
| Profit facts | Did the business improve, or did refunds, discounts, ads, and fulfillment costs eat the gain? | Net sales, refunds, ad spend, margin, or profit proxy |
| Path evidence | Which channel, page, SKU, buyer group, or promotion changed the result? | Channel, page, SKU, AOV, CVR, and order-quality segments |
| Exception routing | Should ads, merchandising, site, support, fulfillment, or the business team fix it? | Responsible team, due date, validation metric |
| Action closure | Did last week's action finish, and did it change the metric? | Continue, close, escalate, or add action |
First, define WBR plainly: it is not a report show
WBR stands for Weekly Business Review, but in this lesson it means a weekly operating decision meeting. It is not a slide deck made from Shopify, GA4, ad platform, and support readouts. It is not each team explaining its own number. A useful WBR answers a sharper question: which facts are strong enough to change next week's actions?
The reason this matters is simple. Ecommerce growth can be fake. Revenue can rise because discounts became heavier, refunds increased, low-margin SKUs took more share, ads bought more expensive traffic, or shipping and support issues ate the margin. If the weekly review only reads revenue and ROAS, it can mistake weak growth for scale-ready growth.
| What WBR solves | What it is not | Real output |
|---|---|---|
| Align profit facts | Not one page of platform readouts | This week's net sales, refunds, cost table, ad spend, and profit proxy logic |
| Locate the path of change | Not a vague claim that ads improved or the page got worse | First evidence from channel, SKU, page, support, fulfillment, or promotion |
| Close or escalate actions | Not a vague keep watching note | Responsible team, due date, validation metric, and next status |
Align profit facts before discussing growth
WBR breaks when everyone uses a different meaning of profit. Shopify sales, GA4 purchase events, ad-platform ROAS, and support refund reasons are not the same thing. Each source is useful, but it needs the right job in the review.
| Fact type | Plain meaning | How WBR uses it | Common misread |
|---|---|---|---|
| gross sales / net sales | Gross order value versus sales after discounts and returns. | Start with net sales and refund movement before channel debate. | A revenue number can hide refunds and cancellations. |
| cost per item | The product or variant unit cost behind many margin reads. | Check whether the cost table is current and SKU margin is reliable. | Supplier cost changes, but the review still uses old cost data. |
| GA4 purchase / refund | Behavior events that describe the user path. | Diagnose channels and pages, not final finance profit. | Missing events distort channel or page judgment. |
| Ad ROAS / CPA | Revenue return and cost per acquisition from the ad view. | Put it into the profit proxy with refunds, margin, and fulfillment cost. | Good ROAS is treated as permission to scale immediately. |
Shopify's profit reports need cost per item to make gross profit and margin more useful. Shopify also documents why sales reports can differ because of timing and reporting logic. So the WBR question is not only "how much revenue did we make?" It is "is this fact stable enough for a decision?"
Use a pet warming mat example to connect profit, path, and action
For example, imagine you sell a self-warming pet mat. Shopify net sales are up 18% this week and Meta ROAS looks strong, but support notes show refunds clustering around size expectations, the warehouse says the large size is nearly out of stock, and GA4 shows a lower product-page-to-checkout conversion rate. Checkout means the process where the shopper moves from cart into payment, shipping, and order completion; it is not just one button. A WBR should not jump straight to the conclusion that ads can scale.
| Signal | Question to ask first | Possible action | Next-week validation |
|---|---|---|---|
| Revenue is up 18% | Does net sales deduct refunds, discounts, and cancellations? | Do not scale from the revenue number; restate the profit proxy. | Net sales, refund rate, discount share, and contribution profit |
| Meta ROAS looks good | Are orders concentrated in low-margin SKUs or high-refund regions? | Scale only higher-margin SKUs and cap low-margin SKU expansion. | SKU margin, CAC, refund rate, and contribution profit inside the guardrail |
| Size-related refunds rise | Do PDP, size chart, support script, and shipping email say the same thing? | Add size proof to the product page and route repeated confusion back to support notes. | Size refunds, size questions, negative reviews, and PDP add-to-cart rate |
| Large size is low in stock | Are ads, page modules, and stock promises still pushing the large size? | Adjust hero SKU, replenishment priority, and page promise. | Stockout loss, inventory turnover, and low-stock SKU spend |
This is the job of WBR: it does not prove one platform right or wrong. It turns surface growth into profit, path, cause, and action. Then next week's meeting can close old actions instead of debating the same numbers again.
How to use it: keep the weekly process to four steps
The WBR table is practical only if the process stays narrow. Step one, lock the profit fact logic used this week. Step two, route the change back to channel, SKU, page, support, fulfillment, and inventory paths. Step three, decide whether last week's action should close, continue, escalate, or fix the definition first. Step four, add only 3 to 5 next-week actions. If the list is longer, the team probably has not identified the main problem yet.
Common sticking points
If the meeting keeps arguing about which tool is more accurate, pause and write down the definition version. If every action says keep watching, add a responsible team and validation metric first. If new actions keep piling up while old actions never close, WBR has turned into task accumulation instead of business review.
Profit proxy can be rough, but the logic must stay stable
Some teams wait for perfect finance reconciliation before talking about profit. That makes the weekly review too slow. A better starting point is a stable profit proxy. It is not the final finance statement, but it must use the same calculation every week and be good enough to show trend and risk.
A practical minimum logic
The worst case is not low precision. It is changing the formula every week.
If ad spend is included this week but ignored next week, if refunds are read by order date this week and refund date next week, or if old costs mix with new costs, the trend is no longer trustworthy.
Write exceptions as reviewable actions, not meeting conclusions
"Watch refunds," "the page may have a problem," and "ads look unstable" are not WBR actions. A useful action has a responsible team, due date, validation metric, and next review state. Without those fields, next week's meeting repeats the same debate.
| Exception | Evidence | Good action | Next check |
|---|---|---|---|
| Meta spend rises while profit proxy falls | CAC moves from $18 to $26 and refund rate rises. | The ads team pauses low-margin SKU scaling and recalculates the ad profit guardrail. | CAC, refund rate, SKU margin, and contribution profit return inside guardrail. |
| Google Shopping gets clicks but conversion is low | High-click SKUs have mismatched price, stock, and page promise. | The product data team fixes feed and page facts before budget review. | Feed status, page promise, add-to-cart rate, and purchase rate. |
| Organic traffic grows but revenue stays flat | New clicks land on informational posts with weak internal links and buying CTAs. | The SEO team adds collection links and buying-guide CTAs. | Collection clicks, PDP entries, and assisted conversions. |
| Refunds concentrate around shipping timing | Tickets and refund reasons both point to delay expectations. | The support / fulfillment team changes page promise and email timing. | Refund reasons, delay tickets, bad reviews, and pre-delivery questions. |
WBR Action Closure Lab: decide action status before adding next work
Weekly reviews become heavy when teams keep adding new actions without closing old ones. The first part of WBR should decide the status of last week's action: close it, continue it, escalate it, fix the definition first, or block new work for now. This is not about making the spreadsheet complex. It prevents the same issue from coming back for four weeks with a new label, a new responsible team, and a new metric.
| This week signal | Last action | Status call | Next move wording |
|---|---|---|---|
| Ad profit guardrail is still broken | Pause low-margin SKU scaling and move budget back to higher-margin SKUs. | Continue, but narrow the scope | Scale only higher-margin SKUs and lower-refund markets, then review contribution profit, refund rate, and SKU margin next week. |
| Feed and page facts are aligned | Fix price, stock, and page promise mismatch for high-click SKUs. | Close and add a monitoring rule | Close the repair action and add price, inventory, and promise consistency to weekly feed QA. |
| Tickets fell, but refunds still cluster in delayed regions | Adjust page promise and shipping notification timing. | Escalate to fulfillment and page promise | Review delivery timing, PDP promise, and pre-order messaging by region. Do not call the support script done. |
| Organic traffic rose, revenue has not moved yet | Add collection links, buying-guide CTAs, and product paths to informational posts. | Continue path review, do not call it failed | Keep it for one more week and add a product path test between collection entry and single-product entry. |
| Profit logic changed the cost table mid-week | Use contribution profit to decide whether promo budget can return. | Fix the definition before judging the action | Restate last week under the same cost logic, mark the cost table version, then decide whether budget can return. |
Ask this before adding work
Can last week's action be closed with evidence? If not, is the problem execution, a changed definition, a scope that was too wide, or a root cause routed to the wrong team? That decision matters more than adding three more tasks.
Use one fixed meeting order: outcome, path, cause, action
The fastest way to improve WBR quality is not adding more metrics. It is using the same order every week. Once the order is fixed, the team stops jumping between revenue, ROAS, support, and inventory without making decisions.
Weekly business review builder: create the pre-read, meeting order, and 3 actions from a real case
Many teams say they have a WBR template, but the meeting still becomes number reading. The reason is that the template has empty fields but does not help the team decide what kind of meeting this week actually is. A better template starts with the main weekly problem, then creates the pre-read, meeting order, three actions, and review window.
| WBR case | Pre-read required | First meeting question | After-meeting action |
|---|---|---|---|
| Margin recovery WBR | Net sales, refunds, SKU margin, Meta CAC, low-margin SKU share. | Did the business really improve, or did refunds, CAC, and low-margin SKUs eat the profit? | Pause low-margin SKU scaling, add size proof, and mark the cost table version. |
| Organic traffic without revenue WBR | Search Console queries, GA4 landing pages, collection clicks, PDP entries, Shopify orders. | Is the traffic answering an informational question, or is it moving toward purchase? | Add collection entry, buying-guide CTA, and product proof blocks to high-click posts. |
| Shipping refund WBR | Refund reasons, support tickets, carrier timing, regional orders, PDP / ad shipping promises. | Is this a support problem, or a mismatch between front-end promise and real fulfillment timing? | Rewrite regional shipping promises across PDP, checkout hint, order email, and ad creative. |
The point of this template is not to make the meeting more formal. It makes every WBR leave the same kind of evidence: main weekly problem, pre-read, meeting order, three actions, responsible team, review window, and next status. Otherwise the meeting can look complete while leaving no action that can be closed.
Separate daily, weekly, and monthly rhythm
Not every issue belongs in WBR. Daily incidents should be handled the same day, weekly review should set operating priorities, and monthly review should change structure. If every issue goes into one WBR, the meeting gets longer and decisions get weaker.
| Rhythm | Main focus | Purpose | Do not |
|---|---|---|---|
| Daily check | Spend anomaly, site issue, stock risk, shipping incident. | Stop incidents from spreading. | Change strategy because of one-day noise. |
| Weekly review | Channels, products, pages, profit, support, and fulfillment quality. | Set next-week priorities. | Turn the meeting into number reading. |
| Monthly review | Category role, pricing, channel role, budget structure, inventory strategy. | Make structural changes. | Use monthly review to replace weekly follow-through. |
WBR exception routing table: decide where the problem belongs before assigning next week's work
The biggest waste in a weekly business review is forcing every exception back into the same meeting and explaining it again. A better WBR routes the exception first: profit-definition issues go to finance and profit review, ad-efficiency issues go to ROAS and budget guardrails, product-truth issues go to Feed and pages, and retention issues go to Email lifecycle work. Then every action has a responsible team, evidence, and closure standard.
If you need to move ROAS from revenue return to profit return, start with the ROAS tool to restate the break-even line. If the week has become a profit-structure issue, continue to Weekly Business Review and Variance Routing. If the issue is promotion depth or discount mechanics, route it to Promo, Discount, and Offer Profit Guardrails.
| WBR exception | First judgment | Next-week action field | Next route |
|---|---|---|---|
| ROAS looks good, but net sales and contribution profit do not follow | Whether ad-driven orders cluster in low-margin SKUs, high-refund markets, or heavy-discount orders | Pause low-margin SKU scaling; restate CPA / ROAS break-even; mark budget recovery conditions | ROAS tool + ad profit guardrail |
| Revenue rises, but refunds, discounts, and support cost rise with it | Whether growth is being eaten by post-purchase, fulfillment, discount, and support cost | Split refund reason, promise issue, discount rule, and fulfillment exception; decide page fix or campaign downgrade first | Profit weekly review + fulfillment returns lesson |
| Google Shopping gets clicks, but purchase rate is weak | Whether PDP, Feed price, stock, shipping promise, and ad landing URL match | Freeze hero budget; fix Feed / page facts; review add_to_cart, purchase, and Feed status next week | Merchant Center / Feed operations |
| New customers buy once, but 30 / 60 day repeat purchase is weak | Whether post-purchase email, replenishment timing, review request, and cross-sell are in one lifecycle path | Add welcome / post-purchase / replenishment flows; name trigger field, suppression rule, and review window | Email lifecycle map |
Copyable lesson notes must state
Which route the exception belongs to, why it is not another route, who closes it, and which number will decide closure next week. Without those four fields, WBR is still just a number-explanation meeting.
Source boundary: events show paths, reports show orders, WBR creates actions
GA4 ecommerce measurement and GA4 recommended events can help define purchase and refund path events. Shopify profit reports are better for returning to order, sales, cost per item, gross profit, and gross margin. Shopify sales discrepancies also remind teams that timing and report logic can differ. WBR turns those signals into a short list of reviewable actions.
Copyable lesson notes: leave only these 5 fields after the meeting
If the team already has a WBR template, do not copy only the five labels below. A better note turns WBR into a reviewable action table: lock the profit fact version first, then write the exception route, last action status, responsible team, review window, and counter-signal.
| WBR copy field | Evidence to copy | What it decides | How to close it next time |
|---|---|---|---|
| Main weekly exception | The one net sales, refund, discount, ad spend, inventory, support ticket, or fulfillment issue that changes next week’s action. | Decide whether this WBR starts with profit, channel, page, product, service, or fulfillment. | Next week, review whether this exception moved back inside the line before adding new topics. |
| Profit fact version | The gross sales, net sales, refund, discount, cost per item, ad spend, contribution profit, or profit-proxy version used this week. | Stop the team from debating one issue with different revenue and cost logic. | If cost table or refund logic changed mid-week, restate the baseline before judging the action. |
| Path evidence | Channel, SKU, PDP, checkout, support ticket, fulfillment record, inventory table, or Search Console / GA4 path. | Decide whether the exception comes from lead quality, page fit, product facts, service promise, inventory, or fulfillment. | Use the same path next week; do not switch metrics just to prove the old call right. |
| Exception route | Whether the issue belongs to ads, product data, page, support, fulfillment, Email, SEO, or profit review. | Decide who closes it and which tool or next tutorial should receive it. | If the route was wrong, move the responsible line instead of adding more tasks. |
| This week’s decision | Scale, cut, fix page, restock, change promise, pause SKU, restore promo, or fix the definition first. | Turn the meeting conclusion into one operating action. | Next time, judge only whether this action should continue, close, escalate, or roll back. |
| Last action status | Close, continue, escalate, fix definition, or block new work first. | Prevent WBR from adding tasks every week without closing old work. | An action without closure evidence should not be hidden behind “keep watching.” |
| Responsible team and review window | Responsible team, due date, validation metric, review date, and update location. | Make WBR an operating record another teammate can continue. | If the date arrives without a metric or responsible team, the default state is escalation, not completion. |
| Next WBR counter-signal | The signal that would prove this call wrong, too broad, or routed to the wrong workstream. | Admit uncertainty before the team cherry-picks supporting numbers. | When the counter-signal appears, fix the judgment before adding more action rows. |
Next, do not make another pretty report. Bring these copyable lesson notes into next week's meeting, close last week's actions first, then add new ones.
Next learning path: connect WBR exceptions to profit, ads, and promo guardrails
If ROAS needs a break-even restatement, start with the ROAS tool. If the exception needs profit-structure diagnosis, continue to weekly business review and variance routing. If the issue comes from promotions or discounts, use promo, discount, and offer profit guardrails. If the anomaly comes from channel quality, return to multi-channel advertising.