ScaledByDesign/Insights
ServicesPricingAboutContact
Book a Call
Scaled By Design

Fractional CTO + execution partner for revenue-critical systems.

Company

  • About
  • Services
  • Contact

Resources

  • Insights
  • Pricing
  • FAQ

Legal

  • Privacy Policy
  • Terms of Service

© 2026 ScaledByDesign. All rights reserved.

contact@scaledbydesign.com

On This Page

The Overselling ProblemWhy Inventory Numbers LieThe Four Layers of Inventory IntelligenceLayer 1: Real-Time Available-to-PromiseLayer 2: Demand ForecastingLayer 3: Reorder Point CalculationLayer 4: Automated Purchase OrdersThe Overselling Prevention SystemThe DashboardImplementation Priority
  1. Insights
  2. Growth Ops
  3. The Inventory Forecasting System That Stopped Our Client From Overselling

The Inventory Forecasting System That Stopped Our Client From Overselling

January 5, 2026·ScaledByDesign·
inventoryforecastinge-commerceoperations

The Overselling Problem

Our client was selling products they didn't have. Twelve percent of orders required either a refund, a backorder notification, or a substitution. Each oversold order cost $47 in refund processing, customer service time, and expedited shipping for replacements. At 3,200 oversold orders per year, that's $150K in direct costs — plus the customer trust damage you can't measure.

The root cause wasn't bad inventory management. It was lag.

Why Inventory Numbers Lie

The inventory gap:

What your system says:          What's actually available:
  Widget A: 200 units             Widget A: 167 units

Where the 33 units went:
  ├── 12 in carts (not yet purchased, reserved for 30 min)
  ├── 8 in orders being packed (picked, not shipped)
  ├── 5 returns in transit (counted as "in stock" but not arrived)
  ├── 4 allocated to subscription orders (process tonight)
  └── 4 in quality hold (damaged, awaiting inspection)

Your available-to-sell number is wrong by 16.5%.
At high velocity, this causes overselling within hours.

The Four Layers of Inventory Intelligence

Layer 1: Real-Time Available-to-Promise

interface InventoryPosition {
  sku: string;
  physicalStock: number;        // What's in the warehouse
  allocated: number;            // Picked/packed, not shipped
  inCarts: number;              // Reserved in active carts
  pendingSubscriptions: number; // Recurring orders due today
  qualityHold: number;          // Damaged/inspection
  inboundInTransit: number;     // POs in transit (don't count yet)
  safetyStock: number;          // Buffer (never sell below this)
}
 
function availableToPromise(inv: InventoryPosition): number {
  return Math.max(0,
    inv.physicalStock
    - inv.allocated
    - inv.inCarts
    - inv.pendingSubscriptions
    - inv.qualityHold
    - inv.safetyStock
    // Don't count inbound — it hasn't arrived yet
  );
}
 
// Update every 60 seconds from warehouse + cart systems
// Display on PDP: "X left in stock" uses this number

Layer 2: Demand Forecasting

Simple but effective forecasting model:

Base demand = Average daily sales over last 90 days
  (weighted: recent weeks count more)

Adjustments:
  + Seasonality factor (same period last year)
  + Promotional uplift (planned campaigns)
  + Trend adjustment (growing or declining SKU)
  - Cannibalization (new product replacing old)

Example:
  Widget A:
    Base demand: 42 units/day
    Seasonal factor: 1.3x (holiday season)
    Promo next week: +25% expected uplift
    Trend: +5% month-over-month

    Forecast next 7 days: 42 × 1.3 × 7 = 382 units
    Forecast during promo: 42 × 1.3 × 1.25 × 7 = 478 units

Layer 3: Reorder Point Calculation

When to reorder:

Reorder Point = (Daily Demand × Lead Time) + Safety Stock

Where:
  Daily Demand = Forecasted (not historical average)
  Lead Time = Supplier lead time + receiving time + QC time
  Safety Stock = Z × σ × √Lead Time
    Z = service level factor (1.65 for 95%, 2.33 for 99%)
    σ = standard deviation of daily demand

Example:
  Widget A:
    Daily demand: 42 units
    Lead time: 14 days (supplier) + 2 days (receiving) = 16 days
    Demand std dev: 12 units
    Service level: 95% (Z = 1.65)

    Safety stock: 1.65 × 12 × √16 = 79 units
    Reorder point: (42 × 16) + 79 = 751 units

    When stock hits 751, place a PO.

Layer 4: Automated Purchase Orders

Daily automated process:

1. Check every SKU against reorder point
2. For SKUs below reorder point:
   a. Calculate order quantity (EOQ or fixed period)
   b. Check supplier capacity and MOQs
   c. Generate draft PO
   d. Route for approval (auto-approve under $5K)
3. Send approved POs to suppliers via EDI/API
4. Track expected delivery dates
5. Alert if delivery is late

Automation eliminates the "forgot to reorder" problem
that causes 40% of stockouts.

The Overselling Prevention System

Real-time inventory checks at every step:

1. Product page load:
   → Show available-to-promise quantity
   → If < 10 remaining: show "Only X left"
   → If 0: show "Out of stock" (not "Add to cart")

2. Add to cart:
   → Reserve inventory for 30 minutes
   → If another customer empties stock while browsing,
     show "Sorry, this item just sold out"

3. Checkout start:
   → Re-verify all cart items are still available
   → If any item sold out, notify before payment

4. Payment processing:
   → Final inventory check before charging card
   → If fails: don't charge, notify customer
   → If passes: decrement inventory atomically

5. Post-order:
   → If warehouse can't fulfill (damaged, miscount):
     notify customer within 2 hours with options

The Dashboard

Daily Inventory Health:

Stockout Risk (Next 7 Days):
├── 🔴 High risk (3 SKUs): Widget B, Gadget X, Tool Y
│   └── Widget B: 89 units, 7-day forecast 120 → stockout in 5 days
├── 🟡 Medium risk (8 SKUs): Will need reorder this week
└── 🟢 Healthy (142 SKUs): 14+ days of supply

Overselling:
├── Today: 0 oversold orders ✅
├── This week: 2 oversold orders (down from 38 last month)
└── Root cause: Warehouse miscount on SKU-4421 (corrected)

Inventory Accuracy:
├── System vs physical count variance: 1.2% (target: < 2%)
├── Last cycle count: Feb 1, 2026
└── Next scheduled: Feb 15, 2026

Purchase Orders:
├── Auto-generated today: 4 POs ($12,400)
├── Pending approval: 1 PO ($8,200)
├── In transit: 7 POs (arriving Feb 8-15)
└── Late: 0 POs ✅

Financial:
├── Inventory value: $1.2M
├── Days of supply (avg): 23 days
├── Dead stock (> 90 days no sales): $42K (3.5%)
└── Carrying cost: $18K/month

Implementation Priority

Week 1-2: Fix available-to-promise calculation
  → Integrate cart reservations with inventory count
  → Subtract allocated/held/subscription orders
  → This alone will cut overselling by 60-70%

Week 3-4: Add real-time checkout inventory verification
  → Check at cart, checkout start, and payment
  → Handle sold-out gracefully (don't charge then refund)

Week 5-8: Build demand forecasting
  → Start with simple weighted average
  → Add seasonality from last year's data
  → Calculate reorder points per SKU

Month 3: Automate purchase orders
  → Daily reorder point checks
  → Draft PO generation
  → Supplier integration

The best inventory system isn't the most sophisticated — it's the one that knows the difference between what's in the warehouse and what's actually available to sell. Get that number right, and overselling drops to near zero. Build forecasting on top, and stockouts follow.

Previous
Database Migrations Without Downtime
Next
Event-Driven Architecture for the Rest of Us
Insights
Your Attribution Is Lying to You — Here's How to Fix ItThe DTC Tech Stack That Actually Scales Past $10MSubscription Churn Is a Systems Problem, Not a Marketing ProblemLifecycle Automation That CompoundsThe Checkout Optimization Playbook That Added $2M in RevenueWhy Your Shopify Store Breaks During Every SaleWhy Your Loyalty Program Isn't Working (And What to Build Instead)COGS Reporting Shouldn't Take 5 DaysHeadless Commerce: When It's Worth It and When It's a TrapThe Inventory Forecasting System That Stopped Our Client From OversellingPayment Processing Architecture for High-Volume Merchants

Ready to Ship?

Let's talk about your engineering challenges and how we can help.

Book a Call