Revenue Leaks
In plain English
Money escapes every shop in small, boring ways. Someone fills a basket and leaves. A card gets declined. A popular item runs out. Someone returns an order.
This screen finds all of it and adds it up.
Two numbers matter, and they're different:
- "At stake" — the full amount involved. If people abandoned £23,400 of baskets, that's the at-stake number.
- "Recoverable" — what you can realistically get back. For abandoned baskets that's about 10%, so £2,340.
Most tools only show you the big number, and then you're disappointed when a recovery campaign brings back a tenth of it. We show you both, and you should plan around the smaller one. When we say £2,340 and you get £2,300, you'll know the number can be trusted next time.
How to use it
- Click "Daily Ops" in the left-hand menu, then the "Revenue Leaks" tab.
- Look at the "recoverable" total — that's realistically how much you can get back.
- Start with the top row. The list is sorted with the most recoverable money first.
- If a row says "one-click," press the button — the app sends the recovery messages for you.
- If a row is about stock, place a reorder. If it's about failed payments, set up a payment-retry sequence.
- Dismiss anything that isn't real — a product you've stopped selling, for example. This keeps your total honest.
⏱ ~10 min · 💳 Starter+ · 🎯 Money you can actually get back, ranked
Why this matters for your business
Every store leaks. The question is never whether — it's whether you can see it, and whether you believe the number when you do.
Most tools fail the second test. They report gross: "$23,400 in abandoned carts!" That figure is technically true and practically useless, because nobody recovers $23,400 of abandoned carts. Industry reality is closer to a tenth of that. So the merchant sees a big number, runs a recovery campaign, gets $2,100 back, and concludes the tool overpromises. After two or three rounds of that, they stop reading the number entirely — and then a real leak goes unnoticed because the boy has cried wolf.
This tab reports what you can realistically get back. Each leak type carries a conservative recovery rate derived from what actually converts, and the headline shows gross and recoverable side by side. $23,400 at stake, ~$2,340 recoverable. When you run the recovery send and get $2,300, the number was right — and because it was right, you'll believe it next month too.
That trust is the entire product. A recoverable figure you act on is worth more than a gross figure you learned to ignore.
What this typically unlocks
| Outcome | Typical result |
|---|---|
| Leak visibility | Six types, continuously, in one place |
| Accuracy of the headline figure | Within ~15% of what recovery actually returns |
| Abandoned-cart recovery started | Same day instead of on a monthly review |
| Stockout losses caught | Within the 14-day projection window, not at reorder time |
| Refund-pattern detection | Automatic, from the order stream |
| Trust in the number after 90 days | High — because it stopped over-claiming |
What you actually get
Six leak types, each with its own recovery economics.
| Leak type | What it is | Recovery rate | One-click fix |
|---|---|---|---|
| Abandoned checkouts | Cart created, checkout not completed | 10% | ✓ Recovery send |
| Failed payments | Payment attempted and declined | 70% | — (dunning) |
| Out-of-stock losses | Demand for a SKU you can't fulfil | 80% | — (reorder) |
| Checkout drop-off | Sessions lost inside the checkout funnel | 5% | — |
| Refund leakage | Refunds indicating a fixable underlying problem | 15% | — |
| Unconverted traffic | Sessions that never reached a cart | 2% | — |
Why those rates differ so much
The spread from 2% to 80% isn't arbitrary — it reflects how much control you actually have over each outcome.
- Failed payments at 70%. The customer already decided to buy and tried to pay. A card expired or a bank declined. A dunning sequence recovers most of these, because intent is proven.
- Out-of-stock at 80%. The demand is real and measured. If you restock, most of it converts. The loss is an inventory problem, not a demand problem.
- Abandoned checkouts at 10%. Intent is genuine but weaker — browsing, price-comparing, waiting for payday. Ten percent is what a good recovery sequence returns. Tools claiming 30% are quoting the click-through rate of the email, not the recovered revenue.
- Checkout drop-off at 5% and unconverted traffic at 2%. Enormous gross numbers, tiny recoverable ones. Most people who browse were never going to buy. These are kept deliberately low so they don't dominate the headline with fantasy money.
- Refunds at 15%. The refund itself is gone. What's recoverable is the pattern — a sizing problem, a photo that misleads, a packaging failure. Fix the cause and you recover future refunds, not past ones.
Severity by money
| Recoverable amount | Severity |
|---|---|
| ≥ 500 | Critical |
| ≥ 50 | Warning |
| < 50 | Info |
Thresholds sit on the recoverable amount, not gross — so a $40,000 unconverted-traffic figure (2% → $800 recoverable) is critical because $800 is genuinely at stake, while a $600 gross drop-off figure ($30 recoverable) stays info-level. This is exactly the correction that stops big-but-meaningless numbers from crowding out small-but-real ones.
How it works (without the technical bits)
Out-of-stock projection
A stockout doesn't have a natural gross figure the way an abandoned cart does — nobody added it to a cart, because they couldn't. So it's projected:
gross loss = lost units/day × unit price × 14 days
The 14-day window is the default projection horizon. It's conservative on purpose: projecting a stockout out to 90 days produces a spectacular number that assumes you'd never have noticed or reordered, which isn't how anyone runs a store. Fourteen days is roughly "before the next reasonable reorder cycle."
At an 80% recovery rate, a SKU selling 12/day at $40 that's been out for two weeks shows:
gross 12 × $40 × 14 = $6,720
recoverable $6,720 × 0.80 = $5,376
Resolution on fact, not on a timer
Most findings on the platform auto-resolve when they go stale. Leaks don't — they resolve when reality changes:
| Leak type | Resolves when |
|---|---|
| Abandoned checkout | The cart converts, or it expires |
| Out-of-stock | Stock is restored |
| Refund | Terminal on detection — the refund already happened |
This is why the recoverable total is meaningful rather than decorative. It goes down when money is actually recovered or the opportunity actually closes — not because a countdown ran out.
Re-detection is safe: amounts refresh (an ongoing stockout grows), but status, detection time, and any recovered amount are preserved. A leak you already recovered is never silently reopened by the next detection pass.
Two windows, two purposes
| View | Window | Why |
|---|---|---|
| Recoverable headline | 30 days | "What's on the table right now" |
| Leak list | 90 days | Terminal leaks like refunds never auto-close, so the list holds a longer history without cluttering the headline |
Where leaks show up elsewhere
Every leak mirrors into the Actions worklist
as a leak-domain finding, and feeds the Recoverable now
metric in the Executive Pulse. That mirroring is what lets a
$2,340 cart leak compete directly against a pricing finding or a
readiness gap — one queue, one ranking, one decision.
Real merchant scenarios
Scenario A — The number that finally got believed
Setup. Skincare brand had used two previous tools reporting gross abandoned-cart value. Both showed ~$40K/month. Both times the recovery campaign returned around $3K, and the team quietly stopped trusting the dashboards.
On this platform:
Abandoned checkouts $38,900 at stake · ~$3,890 recoverable
Recovery send returned $3,610 — within 8% of the projection.
What changed. The team started treating the recoverable total as a real operating number. Six weeks later, when it jumped to $9,200 overnight, they investigated immediately instead of assuming the tool was exaggerating. A checkout script had broken on mobile Safari. They found it in 40 minutes.
That second incident is the return on honest reporting. A number you believe is a number you act on.
Scenario B — Failed payments, the quiet 70%
Setup. Subscription coffee brand, 3,400 active subscribers. Never had visibility into failed renewals — cancellations just appeared.
What surfaced:
Failed payments $4,180 at stake · ~$2,926 recoverable [Critical]
Cause. 52 subscribers with expired cards, silently failing across two billing cycles.
Action. A dunning sequence recovered 38 of 52 within nine days — $2,740 against the $2,926 projection.
The compounding part. Those 38 subscribers had an average remaining lifetime value of roughly $290. The immediate recovery was $2,740; the retained future value was about $11,000. Failed payments carry the highest recovery rate for exactly this reason — the customer never chose to leave.
Scenario C — Stockout that outranked everything
Setup. Outdoor-gear retailer, hero SKU out of stock for 11 days during peak season. Nobody had flagged it because it wasn't in any reorder report yet.
What surfaced:
Out of stock — "Trail Pack 40L"
gross 18/day × $129 × 14 = $32,508
recoverable × 0.80 = $26,006 [Critical]
That single row outranked every other finding on the platform by a wide margin.
Action. Emergency reorder placed same day, air freight on half the quantity.
Outcome. Restocked in six days rather than the normal nineteen. Estimated recovery: roughly $19,000 of the projected $26,006 — the shortfall being the six days that couldn't be recovered at any speed.
Scenario D — Refunds pointing at a photo
Setup. Apparel merchant, refund rate drifting upward with no obvious cause.
What surfaced. Refund leakage concentrated on four SKUs from one collection.
Refund leakage $8,900 at stake · ~$1,335 recoverable [Critical]
Investigation. All four had been photographed under warm studio lighting that rendered a charcoal fabric as brown. Customers ordered brown, received charcoal, returned it.
Fix. Re-shot the four products under neutral lighting and added a fabric-swatch close-up. Refund rate on that collection fell from 22% to 7% over the following two months.
Why 15% is the right rate. The $8,900 of past refunds was gone — genuinely unrecoverable. What the 15% represents is the future refunds prevented by fixing the cause, and on this collection that came to roughly $1,400/month ongoing.
Scenario E — Unconverted traffic, correctly ignored
Setup. High-traffic merchant, 180,000 monthly sessions.
What surfaced:
Unconverted traffic $412,000 at stake · ~$8,240 recoverable
Why the merchant didn't panic. At a 2% rate, that four-hundred-thousand-dollar figure resolves to $8,240 — real money, but well below the $26,000 stockout and the $2,900 failed payments in effort-adjusted terms.
What they did instead. Worked the stockout and the dunning sequence first. The unconverted-traffic figure informed a quarterly CRO project rather than a panic.
The design point. A tool reporting gross would have put $412,000 at the top of the page and sent this team chasing the least tractable problem on the list.
Best practices
✅ Wire the abandoned-cart recovery send. It's the only one-click fix here, and abandoned checkouts are usually the highest-volume leak.
✅ Treat failed payments as urgent regardless of size. At 70% recovery plus retained lifetime value, they're the best money-per-minute on the page.
✅ Cross-check out-of-stock rows against your reorder schedule. The projection assumes you'll restock; if you won't, dismiss the row so the total stays honest.
✅ Read refund leakage as a diagnosis, not a recovery. The value is in what the cluster tells you about a product.
✅ Watch the recoverable total's rate of change, not just its level. A sudden jump means something broke.
✅ Dismiss leaks on discontinued products immediately. Otherwise they inflate the headline and displace real work.
❌ Don't multiply gross by your own optimism. The rates are conservative because over-claiming destroys the number's utility.
❌ Don't chase unconverted traffic first because it's the biggest. At 2% it's the hardest money on the page.
❌ Don't expect refunds to "come back." That money is spent. Fix the cause.
❌ Don't reopen resolved leaks manually. Resolution is fact-based — a resolved cart converted or expired, and reopening it double-counts.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Abandoned-checkout leaks | — | ✓ | ✓ | ✓ | ✓ |
| Out-of-stock leaks | — | ✓ | ✓ | ✓ | ✓ |
| Refund leakage | — | — | ✓ | ✓ | ✓ |
| Failed-payment leaks | — | — | ✓ | ✓ | ✓ |
| Checkout drop-off | — | — | ✓ | ✓ | ✓ |
| Unconverted traffic | — | — | ✓ | ✓ | ✓ |
| One-click recovery send | — | — | ✓ | ✓ | ✓ |
| Mirror into Actions worklist | — | ✓ | ✓ | ✓ | ✓ |
| Multi-store recoverable roll-up | — | — | — | ✓ | ✓ |
Frequently asked
Why is my recoverable so much smaller than my gross? Because gross is what was at stake and recoverable is what comes back. A 10% abandoned-cart rate matches what recovery sequences actually return. The gross figure is shown alongside so you can see both.
Can I change the recovery rates? Not per-merchant. Fixed, conservative rates are what make the number comparable over time and across stores — a tunable rate is a rate someone eventually tunes until the dashboard looks good.
Why is a leak still open after I recovered it? Abandoned-cart leaks close when the cart converts or expires — up to a few days. Out-of-stock leaks close on the next inventory sync after restocking.
Does the total double-count? No. Each leak has one identity per type and scope. Re-detection refreshes the existing row; it never adds a second.
Why does an out-of-stock leak keep growing? Because the loss is ongoing. The projection reflects continued lost demand until stock returns — which is the correct behavior.
Are these included in "Revenue driven"? No, and deliberately. Recoverable is a projection of money still on the table; revenue driven is realized, attributed income. The Executive Pulse shows them separately and never sums them.
Where does refund data come from? Refund events arrive from your store's order stream as they happen, so refund leaks appear without any manual import.
What if I never restock a stocked-out product? Dismiss the leak. The recoverable total drops by that amount, which is correct — it was never recoverable.
See also
- Daily Ops overview — the hub and Executive Pulse
- Actions worklist — where leaks compete with every other finding
- Weekly Plan — leaks are the most common one-click actions
- Cart recovery & post-purchase — the recovery sequences themselves
- Inventory & pricing — preventing stockouts upstream
- Inventory forecast — projecting demand before it becomes a leak
- Attribution & revenue — how realized revenue is counted instead