Stop Overselling Stock Without Breaking the Bank

Stop Overselling Stock Without Breaking the Bank

A warehouse manager rang me last month, properly stressed. His company had just oversold 47 units of their best-selling product across three different sales channels. They didn't find out until customers started complaining. By then, they'd already promised next-day delivery to people, had to issue refunds, and watched their hard-earned reputation take a hit on Trustpilot.

The kicker? They knew this was coming. They'd been manually updating stock levels in Excel, then copying numbers into their website, eBay, and Amazon Seller Central. Usually twice a day. Sometimes more if they remembered.

"We just need everything to talk to each other," he said. "But every quote we've had is mental."

I've had this conversation probably fifty times in the past two years.

The Overselling Problem Nobody Talks About

Here's what actually happens when you're selling across multiple channels:

You've got 10 units of something. Website shows 10. eBay shows 10. Amazon shows 10. Then someone buys 3 on your website at 2pm. You update the website stock to 7. But eBay and Amazon still show 10 until you manually change them. Maybe you do that at 5pm when you're processing orders. But at 3pm, someone bought 5 on Amazon. And at 4pm, someone bought 4 on eBay.

You've now sold 12 units of a product you only had 10 of.

This isn't a theoretical problem. I see it constantly with businesses turning over anywhere from £500K to £5M. You're big enough that manual updates don't scale, but not big enough that vendors take you seriously without trying to sell you systems designed for Tesco.

The financial hit isn't just the refunds. It's the time spent apologizing to customers, the emergency calls to suppliers begging for stock, the staff hours firefighting instead of growing the business. One client calculated they were losing about 25 hours per week just managing stock discrepancies. That's more than half a full-time employee doing nothing but fixing mistakes.

Why The "Obvious" Solutions Don't Work

When businesses start looking for answers, they usually hit three dead ends:

Dead End #1: "Just buy proper inventory software"

Vendors love this one. They'll sell you a shiny new system that does everything. Except it costs a fortune, takes 9-12 months to implement, and requires you to change how you work to fit their system. I'm not saying these systems are bad - they're brilliant if you're the right size. But if you're a 15-person operation, you don't need (and can't afford) what they're selling.

Dead End #2: "Use a marketplace integration tool"

These exist. Linnworks, ChannelGrabber, that sort of thing. They're actually quite good for what they do. But here's the catch: they become your system of record. Everything flows through them. Which is fine until you realize your existing stock management process - the one that actually works for your business - now has to be rebuilt around their platform. You're not integrating; you're replacing.

Dead End #3: "Just update stock more frequently"

This is what the warehouse manager was trying. It doesn't scale. It's not actually solving the problem; it's just reducing the window where the problem can happen. You're still playing whack-a-mole.

What Actually Works For Small Businesses

I've built inventory sync systems for about a dozen companies now, ranging from fashion retailers to industrial parts suppliers. The approach that works isn't about buying the fanciest tool. It's about connecting what you already have.

Most small businesses already have a system they trust for stock. Maybe it's Sage 50. Maybe it's an Access database someone built in 2008 that everyone's terrified to touch. Maybe it's even a well-maintained Excel file (don't laugh - I've seen it work). That system is your single source of truth.

The trick is making everything else listen to it.

Here's the pattern I use:

1. One system owns the stock count. Just one. Everything else is a display of that number.
2. When stock changes, push updates immediately. Not twice a day. Not every hour. Within seconds.
3. Keep it simple. You don't need perfect real-time sync. You need "good enough" real-time that prevents oversells 99% of the time.
4. Build in buffers. If you've got 10 units, maybe your website shows 8. Gives you breathing room for the inevitable edge cases.

The technical implementation is usually simpler than people expect. I'm not building enterprise service buses. I'm writing Python scripts that check for stock changes and update your channels via their APIs.

A Real Example (Without The Sales Pitch)

Worked with a kitchen supplies company last year. Three staff in the office, warehouse in Nottingham, selling on their WooCommerce site and Amazon. About 800 SKUs. They were spending 2-3 hours every morning updating stock levels manually, and still overselling at least weekly.

Their stock lived in Sage 50. It was accurate - their warehouse manager was religious about updating it. But getting those numbers to their website and Amazon was all manual.

Here's what we built:

A Python service that runs on a small Windows server they already had. Every 2 minutes, it:

• Queries Sage 50 via ODBC for stock levels
• Compares against the last check
• If anything changed, updates WooCommerce via REST API
• Updates Amazon via their MWS API
• Logs everything so they can see what happened

Took about 6 weeks from first conversation to going live. That included testing, handling edge cases, and training their team.

The results were pretty dramatic:

• Oversells dropped by about 95% (you'll never get to zero - sometimes two people click buy at exactly the same moment)
• Staff time saved: roughly 12 hours per week
• Customer complaints about stock availability: down about 80%
• Paid for itself in time savings within about 4 months

They're still using it 18 months later. It just runs.

How To Actually Build This

If you're technical enough (or have someone on your team who is), this isn't rocket science. Here's the basic approach:

Step 1: Figure Out Your Source of Truth

Where does your accurate stock count live? Not where you wish it lived - where it actually, reliably lives right now.

If it's in accounting software like Sage, you'll need ODBC access. If it's a SQL database, even easier. If it's Excel... well, we can work with that too, though I'd rather not.

Step 2: Understand Your Sales Channels

Every platform has an API these days:

• WooCommerce: REST API (pretty straightforward)
• Shopify: Admin API (well documented)
• Amazon: SP-API (bit of a pain, but doable)
• eBay: Trading API (more complicated than it needs to be)

You'll need API credentials for each. This usually means creating a developer account, generating keys, all that fun stuff. Budget a day for just getting access sorted.

Step 3: Build The Sync Loop

Here's a simplified Python example of what the core logic looks like:

import pyodbc
import time
from datetime import datetime

# Connect to Sage (or whatever your source is)
conn = pyodbc.connect(
    'DRIVER={Sage 50 Accounts ODBC Driver};'
    'SERVER=your-server;'
    'DATABASE=your-db;'
)

def get_current_stock():
    cursor = conn.cursor()
    cursor.execute("""
        SELECT ProductCode, QuantityInStock 
        FROM StockRecords 
        WHERE Active = 1
    """)
    return {row.ProductCode: row.QuantityInStock for row in cursor.fetchall()}

def update_woocommerce(sku, quantity):
    # Your WooCommerce update logic here
    # Using their REST API
    pass

def update_amazon(sku, quantity):
    # Your Amazon update logic here
    # Using SP-API
    pass

last_stock = {}

while True:
    try:
        current_stock = get_current_stock()
        
        for sku, qty in current_stock.items():
            if sku not in last_stock or last_stock[sku] != qty:
                print(f"{datetime.now()}: {sku} changed from {last_stock.get(sku, 'N/A')} to {qty}")
                update_woocommerce(sku, qty)
                update_amazon(sku, qty)
        
        last_stock = current_stock
        
    except Exception as e:
        print(f"Error: {e}")
        # Don't crash - log it and continue
    
    time.sleep(120)  # Check every 2 minutes

This is massively simplified, but it's the core concept. Check for changes, push updates when you find them.

Step 4: Add The Important Bits

Logging. You need to know what happened when things go wrong. And they will go wrong.

Error handling. APIs fail. Networks drop. Databases lock. Your script needs to handle this gracefully.

Buffer stock. I usually recommend showing slightly less stock than you actually have. If you've got 10, show 8. Gives you a safety margin.

Rate limiting. APIs have limits. Amazon especially gets touchy if you hammer them.

Alerts. When something breaks, you need to know. Email, SMS, Slack message - whatever works for your team.

The Gotchas (And There Are Always Gotchas)

API Changes

Platforms change their APIs. Amazon's particularly bad for this. You need someone who can update the code when things break. This isn't set-and-forget forever.

Timing Edge Cases

Two people can still buy the last item at the same moment. Your sync might run every 2 minutes, but orders can come in simultaneously. You can reduce this window, but you can't eliminate it entirely without more complex (and expensive) solutions.

Stock Reservations

Some businesses need to reserve stock for quotes or pending orders. Your sync logic needs to account for this. I usually handle it by having the source system (Sage, etc.) already factor in reservations before we read the stock level.

Multi-Location Stock

If you've got stock in multiple warehouses, this gets more complex. Which location do you sell from? How do you handle transfers? These are business logic questions that need answering before you write code.

The Human Factor

Your team needs to trust the system. I've seen situations where staff keep manually updating stock "just to be safe" because they don't believe the automation works. That defeats the entire point. You need buy-in.

When This Approach Isn't Right

Be honest with yourself about these:

You're doing less than £250K turnover

You probably don't need this yet. Manual updates are annoying but manageable. Spend your energy on growing the business.

You're doing more than £10M with complex operations

You've outgrown this approach. You need proper enterprise inventory management. Call the Big Four. I'm serious.

Your source data is unreliable

If your stock counts are wrong in your source system, automating the sync just spreads wrong data faster. Fix your stock accuracy first.

You're about to completely change your systems

If you're six months away from replacing your entire stack, don't build integration now. Wait until the dust settles.

You need sub-second accuracy

This approach checks every few minutes. If you need instant, perfect accuracy across everything, you need a different architecture. And a bigger budget.

Common Questions I Get

Q: Can't we just use Zapier or similar?

Maybe. I've seen it work for very simple setups. But Zapier's pricing gets expensive quickly when you're syncing hundreds of SKUs multiple times per hour. And you're limited by their pre-built integrations. For anything beyond basic scenarios, custom code is more reliable and often cheaper.

Q: What about stock in transit or on order?

Your source system needs to handle this. If Sage knows you've got 50 units on order arriving Tuesday, that's a business logic question about whether to show them as available. The sync just pushes whatever number the source system says.

Q: How do we handle returns?

Again, source system question. When you process a return in Sage (or whatever), the stock level increases, the sync picks it up, channels get updated. The sync doesn't care why the number changed.

Q: What if the internet goes down?

The sync stops working. When it comes back, it catches up. This is why buffer stock is important - it gives you breathing room for these situations. Also why you need alerts so you know when things aren't working.

Q: Can we sync prices too?

Yes, same principle. Though price changes are usually less frequent and more strategic, so the urgency is different.

The Honest Truth About Inventory Sync

This isn't a magic bullet. You'll still have occasional oversells. Systems will still break at inconvenient times. But you'll go from firefighting daily to dealing with edge cases monthly.

The businesses I've built these systems for typically see oversells drop by 90-95%. The time savings alone usually justify the effort within a few months. But more importantly, they stop hemorrhaging customer goodwill.

One operations manager told me the best part wasn't even the time savings. It was being able to sleep at night without worrying about what mess she'd find in the morning.

That's the real win.

Let's Talk About Your Situation

Every business is different. Your sales channels, your source systems, your stock complexity - it all matters.

If you're dealing with overselling issues and want to talk through what might work for your specific setup, drop me a line at hello@stirlingjonessolutions.co.uk or use the contact form at stirlingjonessolutions.co.uk.

I'm not going to try to sell you something you don't need. If manual updates are still your best option, I'll tell you. If you need something more sophisticated than I can provide, I'll tell you that too.

But if you're in that sweet spot - big enough that overselling is costing you real money and reputation, small enough that enterprise solutions are overkill - then this might be exactly what you need.

And honestly? It's probably simpler than you think.