What a day of an empty shelf is worth.
marql finds SKUs at zero that were still selling and prices the absence from your own sales rather than from cost. This playbook takes that figure the two steps further the screen does not — through margin, then through substitution — and puts the three real options side by side: pay to arrive sooner, absorb the gap, or substitute around it.
At risk
€381
per week — of which €38 is buyable back
- priced from sales, not cost
- runs on a till and a stock feed
- recoverable ≠ at risk
Screens from the Mercado Claro demo market, captured 1 September 2026. The interface runs in dark mode here and marql AI answers in Spanish on this tenant; playbook 01 shows a different market in light mode. The figures are generated, and the tenant advances its own clock, so these are a snapshot rather than a constant.
The shelf is empty. The demand is not.
At Mercado Claro one line at Madrid · Malasaña is at zero — Granola artesanal, two days running — and marql prices it the way it prices everything: from the store's own sales. The incident reads ≈€381 a week at risk until the shelf is refilled. That is where the product stops and where the decision starts, because €381 is not what the chain loses and it is emphatically not what a courier is worth paying. Two multiplications separate the figure on the screen from the figure a buyer can act on, and both of them shrink it.
- €381
- weekly sales at risk
- €223
- margin inside it
- €38
- worth paying for two days
- 2
- days running
From a shelf at zero to a priced decision.
Four stages, and the third is the one that is usually skipped: the options are not equally priced, and the cheapest of them is often to do nothing and say so.
A SKU that was selling is now at zero.
A daily scan reads the stock snapshot against the sales history and raises SKUs that carry revenue in the last 30 days and hold no stock today. Rows collapse into one incident per store rather than one per SKU, and they arrive sorted into lanes by what kind of money is at stake — a recurring weekly leak, sales running out, capital tied up — with the bar under each row showing how much. The stock-out sits in its own lane at €381, below three leaks worth more per week and above the overstock this library's first playbook is about.
Daily scan · one incident per store · bar length = money at stake
A day of absence gets a number, from sales rather than cost.
The rate comes off the SKU's own trailing sales rather than a category average or a list price, which is what makes this the one playbook that runs on a till and a stock feed alone — no cost data required to get this far. It is stated per week because that is the period the incident carries, and converting it to a day is the reader's job rather than a number the product invents.
Priced from the SKU's own sales · no cost data needed
It separates a line that stopped from a line that faded.
marql reads whether anything is on order, whether the same SKU is in stock elsewhere in the network, and whether this store has emptied before. A repeat at one address is a supply problem wearing a shelf problem's clothes, and the product surfaces the count rather than leaving it to memory — which is the difference between fixing a stock-out and paying for the same one monthly.
On order · elsewhere in network · repeat count
Availability restored is not revenue recovered.
Once an action is confirmed, marql fixes the baseline and the measurement window, and the window has to outlive the restock spike — the first days after a shelf refills sell the demand that queued while it was empty and flatter any decision measured against them. Worth being exact about where this lives: on this tenant the impact ledger is a dated report sitting among the saved views, carrying data as of 10 August 2026, not a live surface that updates as you watch. A review you have to open is still a review; a review nobody opens is not.
Dated report · baseline frozen at commit · window outlives the spike
Zero can be the correct number.
The arithmetic is not in question: the SKU was selling and it holds no stock. What is in question is whether anyone should act. In five ordinary situations an empty shelf is the intended state, and a buyer who expedites into one of them is paying a premium to undo somebody's decision.
The line is being run out on purpose
A delisted SKU reaches zero exactly as planned, and the plan lives in a buyer's head or a spreadsheet the product has never seen. The signal reads a line that sold well for 28 days and stopped, which is precisely what a controlled run-out looks like from the data.
Is anything on order, and is a replacement already selling in the same subcategory? A run-out has neither an open order nor a gap in the subcategory's revenue — the successor is already absorbing it.
The season ended, and the window has not caught up
The rate reads the SKU's recent trailing sales. On a seasonal line, that window straddles the end of the season and keeps quoting demand that has already gone. The shelf is empty because nobody is buying, not because nothing arrived.
Same SKU, same weeks last year. If the run rate then fell the way it is falling now, the season ended. If last year kept selling through this point, it did not.
The replacement is already on the shelf under another code
A pack-size change, a supplier switch or a reformulation gives the same product a new SKU. The old code goes to zero and stays there, correctly, while the demand continues undisturbed one barcode away.
Subcategory revenue over the same days. If the subcategory is flat while the SKU is at zero, the demand did not leave — it moved, and there is nothing to recover.
A limited run that was never going to be replenished
A one-off buy, a supplier's end-of-line, a collaboration with a printed end date. Selling out is the outcome the purchase was designed for, and the alert is a description of success.
Was a replenishment ever possible — is there a supplier record with a lead time, or was the original order the whole of it? A SKU with no reorder path cannot be expedited at any price.
The shelf is empty and the stockroom is not
The scan reads the recorded count, and the recorded count is strictly zero. Stock that is physically in the back, unbooked, or booked to the wrong location reads identically to stock that does not exist. This is the most common of the five in a real chain and the cheapest to resolve.
Are sales still occurring on a SKU the system says is at zero? That combination is not possible and settles the question without anyone leaving the office. Where sales have also stopped, the check is somebody walking to the back — and the answer belongs in the record, because an unlogged phantom zero returns every week.
In short
None of these makes the revenue reappear where it was genuinely at risk. What changes is that four of the five make the action «do nothing, and write down why», and the fifth makes it «go and look» rather than «pay to expedite». marql can recognise a reason only where the reason is in the data — an open order, a subcategory holding flat, a supplier record. A run-out that lives in a buyer's head is invisible to it, and the override that records the run-out is the useful artefact.
The shelf was empty. The decision still failed.
Five ways this goes wrong after the signal was right, in the order they occur: the wrong money, the wrong urgency, the wrong address, the wrong win, and the wrong bookkeeping. These are constructed, not observed — no chain's numbers are behind them.
Paying a premium against revenue instead of margin
€381 a week makes a €100 courier look obvious. But the decision does not recover €381; it recovers the gross margin on units that would otherwise not have sold at all — around €223 at this tenant's margins — and then only the share of that which does not walk to another product and earn its margin anyway. Recovering two days of a seven-day week is worth about €38. The courier loses money, and nothing on the screen says so.
Multiply before you decide: sales at risk, times margin, times the share that would not substitute, times the days actually saved over seven. That product is the ceiling on the premium, and on this line it is a tenth of the headline rather than half of it.
Expediting demand that has already walked
A staple is out for nine days. The premium is paid on day eight, the pallet lands on day nine, and the customers who came for it in the first week have already rebuilt their basket somewhere else. The units arrive; the demand does not come back with them. Expediting buys back the days it removes from the front of the gap, not the ones already spent.
Days saved, not days out. If the delivery was going to arrive on Friday and the premium moves it to Wednesday, the arithmetic runs on two days. And on a line that has already been absent longer than a purchase cycle, treat the recovery rate as lower than the calculator's default rather than the same.
Fixing it at the shelf when the cause is upstream
One store empties, gets a transfer, and empties again three weeks later. Every individual response was correct and none of them touched the reason — an order quantity below the store's real run rate, a lead time set to a default nobody checked, or a delivery route that misses that address. The premium gets paid monthly and the defect never surfaces, because each event closes on its own.
Count events per store over 30 days before choosing an action. A repeat is not a stock-out, it is a purchasing or logistics defect presenting as one, and expediting it monthly is a subscription to the symptom.
Substituting into a worse product and calling it a save
The customer is steered to the next item along, the till total for the day holds, and the incident closes as handled. But the substitute carries less margin, and the chain traded a high-margin absence for a low-margin presence without anyone recording the difference. The revenue line stayed flat, which is exactly why nobody looked at the margin line.
Substitution is a legitimate action and it has a price: the margin gap per unit between the two SKUs, times the units. If the gap is unknown because cost prices are missing, then substitution is an unpriced action and should be recorded as one rather than as a win.
Measuring across the restock spike
The shelf refills and the first days sell the demand that queued while it was empty. Measured against those days, any action looks like a triumph. Measured across the following month, the line is back where it was and the ledger has already booked the recovery.
Baseline and window fixed when the action is confirmed, never once the numbers are known, and the window long enough to contain whole weekly cycles rather than the days immediately after the refill. The Impact Ledger has to be allowed to return «no effect» and «not enough data» — a ledger that only says «proven» is not measuring anything.
In short
Four of the five are a wrong action chosen from a right number, and the fifth is a right action recorded dishonestly — the same shape as playbook 01, because it is the same failure of nerve at the same point in the cycle. The two that matter most are the first and the third: one turns a decision on money that is not really there, the other keeps solving a problem at the wrong address.
Start with the one that matters
Which of today's empty shelves are worth paying to refill sooner?
Any anomalies in the last 7 days?
1 anomaly detected — no active alerts.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Which SKUs are at zero today that carried revenue in the last 30 days?
- 02What is each one earning per selling day, and what is the margin on that?
- 03Which of them have something on order, and when is it due?
- 04Which are in stock at another location close enough to transfer from?
- 05Which stores have emptied more than once in the last 30 days, and on what?
- 06Draft the plan: action, owner, deadline and the window it will be judged in.
What it takes to price a day of absence.
Stock on hand by SKU × location
A daily snapshot, not a live count. Without it this playbook does not run at all — and a POS-only connection often does not carry one, which is the first thing to check rather than the last.
Sales by SKU × location
Quantity, revenue and date, over at least the trailing 28 days. This is what prices the day, which is why the playbook runs without cost data.
Gross margin on the SKU
Without it the absence can still be counted and ranked by revenue, but the ceiling on what shortening it is worth paying cannot be computed — so the decision column stays empty rather than being estimated from a network average.
Lead time and what is on order
Supplier, open purchase orders and the observed delivery date. These decide how many days a premium actually buys, which is the multiplier the whole decision turns on.
How this was computed
The scan, the window and the arithmetic.
The product's own words, from the block it prints under the incident: the scan walks per-product daily rows — sales, cost, stock — and names the exact SKUs behind the money, so each listed item carries its own € contribution rather than a share of a total.
Daily per-SKU rows, typically a 7–28 day window depending on the check; trend checks compare two adjacent windows of equal length. The figure is stated per week because that is the period the incident carries.
- margin at risk per week = weekly sales at risk × gross margin
- recoverable = margin at risk per week × (1 − substitution rate)
- worth paying to save a day = recoverable ÷ 7 × days saved
- POS / ERP sync
- product_sales_daily · inventory_daily
- SKU scan
- incident, grouped per store
- inventory_daily
- qty_in_stock
- product_sales_daily
- product_ext_id, revenue
Two things this block will not smooth over. First, cost does not appear in the columns the check reads, which is exactly why this playbook runs on a till and a stock feed — and equally why the margin step below is the reader's number rather than the product's. Second, the two surfaces disagree: on 1 September 2026 the incident read ≈€381 a week on Granola artesanal while marql AI, asked about the same SKU in the same minute, answered ~€316.80 a week — around €53 a day at an average daily demand of 9.6 units and a €5.50 shelf price, multiplied by six days rather than seven. Roughly €65 a week apart on a €381 figure. Neither number is invented and this page is not going to pick a favourite; what it does is note that a decision this size should not be taken on a figure that moves by a sixth depending on which screen you read it from.
Check it on your own numbers
The three equations above, with the fields exposed. It opens on this playbook's figures, so the first thing it prints is the €381 in the hero turned into the number the decision actually runs on — change any field and the arithmetic follows.
- Margin at risk per week
- €223
- Worth paying, at most
- €38
Two of these four fields are assumptions rather than readings. The margin opens at this tenant's blended 58.5% because the incident carries no cost column for this SKU — use your own. The substitution rate opens at 40% because a plausible figure is more useful than a blank, and it is the one number here nobody can look up without receipt-line data. It does not compute the premium: that is a quote from your supplier or your courier. And it does not know whether the days you entered are days out or days saved — failure mode 02 is the difference.
Three options, three different desks.
The three actions in this playbook are owned by three different scopes, and none of them can take the other two. That is unusual — most decisions concentrate — and it is why an empty shelf so often gets the response the nearest person is able to give rather than the one that is right. The product does not leave this to convention: the order sheet below carries the quantity, the buffer timestamp it came from, and the sentence «only the owner or COO can create an order draft». The scope is enforced, not suggested.
Store manager
Own stores only, and the one scope holding a fact none of the others do: whether the shelf and the stockroom agree.
- Counter-case 05: walking to the back, and recording what was found there.
- Substitution at the shelf — steering demand to the nearest live SKU, and saying which one.
- Whether the line is physically sellable at all: damaged, mislabelled, out of date.
The expedite premium and the transfer. Both are costs incurred outside this scope against a benefit measured inside it, and neither shows up in this inbox at all.
Days from the recorded zero to a restocked shelf, and whether the phantom zeros they reported stayed reported.
Region manager
A group of stores, and the first scope that can see the same SKU sitting in stock at one address and absent at another.
- The transfer, because this is the first scope that can see both ends of one.
- The choice between moving stock and waiting — the comparison that has to include the day the transfer itself costs.
- Which store's empty shelf is the network's problem and which is local.
The purchase that created the gap and the lead time it was ordered against. A region can move stock it already holds; it cannot make more arrive.
Days of absence across the group, and how much was closed by moving stock rather than by paying for speed.
Owner
The whole network, and the only scope that sees the same store emptying repeatedly rather than one store emptying once.
- The expedite premium: the only action here that spends money to buy time.
- The order quantity and the lead time behind failure mode 03 — the cause rather than the symptom.
- The decision to absorb a gap and record it as a decision rather than an oversight.
The one fact the smallest scope holds: whether the pallet is in the back room. Every premium paid on a phantom zero was authorised at this scope and could only have been prevented at the other end.
Premium spent against margin recovered, and whether the stores that emptied twice emptied a third time.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
City Center
54 000 €−0%−2%Westside
39 900 €+2%−0%North Park
39 500 €−16%−17%—In short
These are the three scopes the product ships, not a claim about how a chain ought to be organised. A chain with a central replenishment desk has a seat none of the three describes, and this playbook is not going to invent it. Map your own titles onto the scopes rather than the other way round — and note that on this decision the cheapest action belongs to the smallest scope, which is the opposite of the usual arrangement and the reason it gets skipped.
Everything above, on one spreadsheet.
None of this needs marql. The daily scan across every SKU and location is what the product automates; the method is three decisions and about twenty fields, and it runs on paper for one store in an afternoon. Take it. If the arithmetic keeps changing what you would have done, that is the case for automating it.
Is the shelf empty, or is the record empty?
Counter-case 05 and failure modes 02 and 03 in one tree. It runs before any money is discussed, because three of its four endings cost nothing.
Has this SKU sold anything since the count went to zero?
- YesThe record is wrong, not the shelf. Find the stock, correct the count, and log the cause — an unlogged phantom zero returns every week and costs a premium each time.
- NoThe shelf is genuinely empty. Continue.
Does one of the counter-cases in section 03 apply — a run-out, a season that has ended, a replacement under another code, a line that was never going to return?
- YesRecord which one, who decided it, and when the record should be reviewed. Take no action. The record is what stops this arriving as a surprise every week.
- NoThe demand is real and unserved. Continue.
How many times has this store gone to zero in the last 30 days?
- More than onceTreat the pattern, not the event. Check the order quantity against the store's real run rate and the lead time against the observed one before spending anything on speed — that is failure mode 03.
- OnceA single event. Continue to part 02.
Is the same SKU in stock at a location close enough to transfer from without leaving that location short?
- YesCompare the transfer against the premium in part 03 — the transfer also costs a day, and the sending location's own cover has to survive it.
- NoThe choice is expedite or absorb. Go to part 02.
One of five endings: correct the count, record a reason and do nothing, fix the upstream cause, transfer, or price the wait in part 02.
What a day of absence is worth
Failure mode 01 in worksheet form — the three multiplications between the number on the screen and the number the decision runs on. Each line is smaller than the one above it, and that is the point.
- Weekly sales at risk, as the incident prints it
- Straight off the incident, or out of a sales export. No cost data required to get this far — the check that raises it does not read a cost column.
- Average daily demand, and the shelf price
- Write both down. On the demo SKU they are 9.6 units a day at €5.50, which is where the ~€53 a day comes from — and multiplying that out is how you find whether the weekly figure on your screen used six days or seven.
- Weekly sales at risk, reconciled
- Daily demand times price, times seven. If it does not match the figure the incident printed, you have found the same disagreement this playbook found — note which one you are using and why, because everything below inherits it.
- Gross margin on the SKU
- The SKU's own margin, not the category's and not the chain's. If cost prices are missing, stop here and rank by revenue instead — an estimated margin turns a ceiling into a guess wearing a decimal point.
- Margin at risk per week
- Sales at risk times margin. Expediting recovers this, never the line above it.
- Share of demand that substitutes
- An assumption, and it should be labelled as one on the sheet. Nobody can look this up without receipt-line data. Staples with a close neighbour on the shelf substitute heavily; a destination line that people came in specifically for substitutes very little.
- Recoverable margin per week
- Margin at risk times one minus the substitution share. Divide by seven and multiply by the days a premium actually buys — that product, not this line, is what the premium is compared against.
One figure: what a week of this shelf being empty is actually costing in recoverable margin — and the daily rate underneath it.
Is arriving sooner worth what it costs?
The fork itself. Three options, one comparison, and a fourth line most people forget to write down: doing nothing has a price and it is often the lowest one on the page.
- Delivery date without intervention
- The observed one, not the contracted one. If the last three deliveries ran late, the observed one is the real one.
- Delivery date with the premium paid
- Confirmed with the supplier or the courier, not assumed. An unconfirmed date buys nothing.
- Days actually saved
- The difference between the two lines above. Not the days already spent out of stock — those are gone at any price, which is failure mode 02.
- Ceiling on the premium
- Recoverable margin per week, from part 02, divided by seven and times the days saved. Anything quoted above this line loses money even when it works. On the demo SKU that is about €38 for two days, against €381 on the screen.
- Premium quoted
- Total cost of arriving sooner, including anything the expedited route adds — a part-load, an out-of-hours delivery, a driver.
- Transfer cost, if a transfer is possible
- Freight plus the day it takes plus the margin risked at the sending location. A transfer that empties another shelf has moved the problem, not solved it.
- The decision, and its price
- Expedite, transfer, substitute or absorb — and the number that made it the cheapest of the four. Absorbing is a decision with a price, and writing that price down is what makes it one.
A chosen action with the arithmetic that chose it, and a recorded price for the option not taken.
Fix the measurement before you act.
Failure mode 05 in worksheet form, and the only part with a deadline: every field is filled in before the action, because once the result is known none of them can be chosen honestly. The hints name what marql's own ledger requires, so a spreadsheet run to this standard and a product run to it answer the same question.
- The action, in one sentence
- What is being done, to which SKU, in which location, at what cost.
- Owner
- A name holding a scope that can actually take the action — section 07. On this decision the three options belong to three different scopes.
- Baseline, frozen now
- The figure the effect will be measured against, written down and not recalculated later. On a spreadsheet, freezing it means pasting the value rather than leaving a formula that will move.
- Measurement window
- Exact dates, chosen now. It must start after the restock spike has passed rather than during it, and cover whole weekly cycles — measuring across the refill is failure mode 05.
- The metric
- Days out of stock on this SKU in this location. One metric — a second one is how a favourable result gets picked after the fact. Revenue is the wrong choice here: it moves for reasons this action did not cause.
- Matched controls
- Comparable locations that did not receive the action. marql will not call a line proven on fewer than four matched control stores; with no peers it falls back to the unit's own volatility, which is a weaker claim and should be labelled as one.
- What would void the window
- A promotion on the SKU or its nearest substitute, a price change, a supplier change, or a second stock-out inside the window. Any of these and the honest verdict is inconclusive rather than proven.
- What counts as no effect, and as worse
- Both, written before you know them. «Worse» is reachable here: a premium paid that bought fewer days than quoted has spent money for nothing.
A row that can close in any of six directions — found, measuring, proven, no effect, inconclusive, worse. If the last three are unreachable in your version, the first three are not worth having.
In short
That is the whole method. What marql adds is not a better equation: it runs the scan daily across every SKU and location rather than the shelf somebody walked past, groups the rows per store so a repeat is visible as a pattern instead of nine separate incidents, and keeps the ledger so a closed row cannot quietly be reopened and improved. The arithmetic above is the same either way — and the substitution rate is a number neither of us can measure.
09 · The line proof stops at
Revenue at risk
≠ a proven recovery.
€381 is weekly sales at risk on one SKU at one location — the figure the incident itself carries, visible on the screen at the top of this page. It is not a loss: some of that demand buys something else in the same visit and earns its margin anyway. The share that does is the one number in this playbook nobody can measure without receipt-line data, and marql does not hold it, which is why the calculator asks for it instead of printing it.
It is also not margin. Expediting recovers gross margin on units that would otherwise not have sold at all — about €223 at this tenant's margins — and the recoverable part of that, over the days a premium actually buys, is roughly €38. The number on the screen and the number a buyer can act on differ here by a factor of ten, and the direction is always the same one.
And it is not a proven effect. That is recorded only after the action is executed, the baseline is frozen and the control window closes past the restock spike. Where the data is insufficient or an outside factor distorted the result, the Impact Ledger marks the effect unproven. The demo tenant advances its own clock, so every figure here is a snapshot rather than a constant.
What the product does do, and the screen below is the plainest example of it, is print the conditions beside the reading: how much of the day has actually elapsed against how much was expected by now, and how many locations reported at all. A pace figure without those two lines is unreadable, and most dashboards omit both.
Where these screens live
The three surfaces this decision passed through
Ready to see
the euros it found?
The walkthrough is built around the tills and accounting you already run. Leave your details and pick a time.