The one daily judgement that drives profit: how much of each product to send into Amazon. Get it wrong both ways —
Stock out · lose the sale · slide down Amazon rankings.
Cash locked in dead stock · storage + aged-stock penalties bite.
| # | Decision | What we need |
|---|---|---|
| 1 | Turn on the 2 engine upgrades? (seasonality + profit-first) | Your go / partial / wait — built & reversible. Detail → 2 Upgrades tab. |
| 2 | Nightly auto-refresh schedule | What time should the tool run each night? |
| 3 | Real pallet / courier cost | Jiten to bring the per-collection figure — the one number we're missing. |
| 4 | Aged-stock policy | Agree a clear-out target before Q4. Exposure → Costs tab. |
| 5 | Packing workflow | Confirm pack-order · no half pallets · no-double-pack freeze. → Warehouse tab. |
Runs nightly, per product. Every step below is what it's programmed to decide today — the amber ones are built but need your approve / deny.
All ~6,500 products: stock, Amazon inventory, in-transit, sales — refreshed nightly.
How fast each line really sells.
Rule: count only days in stock, net of returns — never raw salesHow long stock takes to land.
Rule: measured per product (~6d); extra buffer on lines that have stalled beforeCushion for demand wobble.
Rule: tier by stockout cost → heroes 99.5%, then 99% / 97% in-stock targetHow many days to hold.
Rule: cheapest cover that won't stock out · never past the 90-day ceilingBuy ahead of the Q4 peak instead of reacting late.
Rule: raise planned stock before Q4, ease after — per productProtect the money-makers with tight cash.
Rule: more cover on high-margin lines, less on thin onesDon't pile onto over-stock.
Rule: if at/over target → send 0One product, two Amazon SKUs.
Rule: merge into one order — never send 67+67=134Fit the period's spend.
Rule: genuine need first; profit-ranking rations only if need > budgetPer product: quantity + by-when + tap-to-see "why". No black-box numbers.
An approver edits any qty and taps fire. Watch-only now — it suggests, sends nothing.
Your calls: (a) the nightly run-time · (b) when to flip from watch-only to autoEngine places the supplier order and books the Amazon inbound shipment itself.
The team only picks, packs and ships. Failed sends ping Manish + Bhavika with one-tap retry.
Paste in Amazon's 14-day sales by hand, then recent sales × 3 months cover on every product alike — fast-seller and slow-mover the same. It worked, but leaked money 5 ways:
| Problem | What it cost us |
|---|---|
| Blanket 3-month rule over-held stock | ~5× the storage cost of a lean approach, for only ~1.85× the stock — pushed slow movers into Amazon's over-stock + aged-stock penalties. |
| Blind to stock-outs | Used raw sales, not in-stock days. A line that sold out day 1 of 14 read as "barely selling" → got starved. |
| No lead-time awareness | Treated Amtech (1–2 days), Tiger/Silvine (7 days) and China (~60 days) identically — no buffer for slow suppliers. |
| No safety-stock logic | A single "× 3", no cushion for demand wobble, no service-level dial. |
| Wrong-product errors | 266 misclassified by SKU text-match — 243 sent into Amazon that shouldn't be, 23 real FBA lines silently skipped. |
Same job, decided per product on real numbers — then backtested over a full 12 months.
| Old way | New engine | |
|---|---|---|
| Cover | Flat ~3 months on all | Tailored per product — fast/risky lines more, slow lines less |
| Delivery time | A guessed flat lead | Measured: ~4-day median first units, ~6-day per product; buffers lines that have stalled before |
| Demand swings | Ignored | Safety stock tiered by stockout cost — heroes 99.5%, then 99% / 97% in-stock targets |
| Double-sending | Two Amazon codes → sent twice (67+67=134) | Collapsed into one order — stops ~double-spend on those lines |
| Over-stocked lines | Could still top up | Sends zero past target; never past the 90-day ceiling |
| Storage cost | Not considered | Aware of Amazon's fee cliffs — trims to cheapest cover that won't stock out |
What our Amazon stock actually costs to hold and to exit. Different buckets — not all simply added.
| Cost | Figure | Detail | Status |
|---|---|---|---|
| FBA storage (12 mo) | £9,787 | Amazon storage-fee report. Heavily Q4-weighted. | Verified |
| Q4 share | 42% | £4,077 — Oct–Dec rates run 2–3× higher. Carrying stock into Q4 is the expensive mistake. | Verified |
| Aged-stock surcharge | £1,161/yr | Stock 241+ days (steps up 271/365). Accelerating ~6× (£39→£237/mo) → heading for ~£2,000/yr. The clearest over-stock signal · 178 products >90 days. | Verified |
| Removals (return to us) | £2,230 | 2,493 units pulled back — 97% shipped to us, 3% disposed. We keep the goods (cost, not write-off). | Verified |
| Customer returns | ~£1,234/yr | 1,464 units · refund-admin £298 + processing £936. Conservative floor (low-return season). Write-off ≈ offset by reimbursements → net ≈ nil. | Verified |
| Reimbursements | +£2,862 | Amazon credits back for lost/damaged stock — offsets the above. | Verified |
| Pallet / courier | ~£50? | Tool assumes ~£50/shipment off an old invoice. UK benchmark £60–100. Need the real number. | Needs Jiten |
Both reversible in one switch. Together: ~£359 better with fewer stockouts over the year replay (combined, not a simple sum).
| Upgrade | What it does | Replay gain | The honest catch |
|---|---|---|---|
| 1 · Seasonality buy ahead of peak |
Learns each product's seasonal shape from years of history; raises planned stock before Q4, eases after — instead of reacting once sales already jumped. | +£185 | The cleaner, fully-evidenced win. Q4 safety fix already in. |
| 2 · Profit-First protect money-makers |
More safety stock on high-earning lines (margin × speed), less on thin ones — so tight cash protects profit first. | +£192 | We only know true margin on ~half our products, so it half-works today — the win grows as we fill cost/price data. |
A test rig that replays a full year of real sales (1 Jun 2025 – 31 May 2026) across 388 active products — so we pit old vs new on identical history, no guessing.
Pulled from Amazon's official Selling-Partner feeds (+ Linnworks for older history), landed in our database, topped up nightly — so Amazon can't age it out. Core feeds live; fees/returns/billing wiring in now.
| What it is | How far back | Status |
|---|---|---|
| Stock movement diary — every receipt/transfer/adjustment/return, per product per day | ~18–24 mo | Live nightly |
| Shipments + real lead-times — sent, left, booked in, how long | ~18–24 mo | Live nightly |
| Live stock health — sellable / inbound / reserved / stuck, + selling speed | Current + daily history | Live nightly |
| Storage fees — monthly cost per product | 24 mo (Jul '24) | Pulled · wiring |
| Aged-stock surcharges | 13 mo | Pulled · wiring |
| Removals · Returns · Reimbursements | trailing 12 mo | Pulled · wiring |
| Billing / settlement — actual money in/out | ~90 days + ongoing | Now adding |
| Sales history — units & £ per product per day | ~2 yr Amazon; older from Linnworks | Next |
Amazon holds no per-product detail before ~mid-2024 (storage Jul '24). Monthly storage totals recoverable to ~2015. From today, nightly top-up means we lose nothing again.
Every night the history grows; the tool reads it back to spot £-costly patterns (over-sending into ageing stock, under-sending in-season) and sharpens the next call.
Phases 1–3 done & live · Phase 4 built (awaiting your go) · Phase 5 in progress · 6–8 ahead.
All ~6,500 products into one clean daily view. New lines self-onboard.
True selling speed + per-product cover + measured lead-times. In production.
Year-replay sim, 20-round stress-test, benchmarked vs 17 OSS projects — no faults.
Seasonality + profit-first. Tested, switched off — one flip from you.
Fees, aged, removals, returns, billing → wired into the nightly feed.
Nightly auto-run + approve→execute: engine proposes, you tap, it orders + books the shipment.
Supplier reorders + China container plan (fires when it fills). Feeds stock toward Amazon.
Watch-only → prove → you flip to auto, one section at a time, container last.
Each stage proven before the next. The warehouse only picks and packs.
| Stage | What ships |
|---|---|
| Foundation | Pull all stock + Amazon data into one view; flag new/unlinked lines |
| Demand | True selling speed (only in-stock days, net of returns) |
| Sizing | Safety-stock + smart cover that dodges fee penalties, keeps bestsellers in stock |
| FBA engine | The "how much to send into Amazon" brain |
| Warehouse engine | Supplier reorders + China container plan (fires when full, not on a calendar) |
| Approval + sending | One approver edits any qty, taps fire; failed sends ping Manish + Bhavika with one-tap retry |
| Screens | Send lists, plain-English "why", budget cap with "didn't fit — add £X" list, Jiten's pick-list |
| Go live | Watch-only → prove → Manish flips to auto, container last |
Guardrails: no silent cuts, no hidden failures, no unexplained numbers; per-period budget where genuine need comes first, profit-ranking only rations when need outruns budget.
The tool only "sees" Amazon transit time — blind to the packing-queue wait here, and to what's already packed. Before we build the fixes:
| Question | Why it matters | What we need |
|---|---|---|
| Pallet / courier cost? | Tool assumes ~£50 (unvalidated). Get it wrong and it can't tell an economic send from a wasteful one. | Jiten: real per-collection cost from latest invoices. |
| Pack order? | Leads are queue-driven — top-of-list packs day 1, deeper items wait. Tool assumes a flat wait → under-sends deep-queue items. | Confirm top-of-list-first. How many units/items can we pack per day? |
| How often do we ship? | Trade-off: more often = fresher but more fees; less = fuller pallets but staler. | Confirm ~2 pallets/week, one shipment — or 2/week, or 1 every 3 days? |
| Never ship a half pallet? | A half pallet still costs full ~£50+, making each unit expensive. | Agree: wait to fill — except to rescue a hero line from stocking out. |
| No-double-pack freeze | Once packed, the tool could re-recommend it next night → packed twice. | Confirm: packed qty counts as on-the-way, releases only when SENT — no time-based reset. |
| Lock packed quantity? | A packed item's qty must freeze so re-runs can't change it under you. | Agree qty locks when a shipment is committed; team records actual packed count. |