Stock tracking: how to avoid selling what you don't have

Where the problem comes from

An online store is a storefront. The actual product sits in a warehouse, on a shelf, or with a supplier. There needs to be a connection between the storefront and the warehouse. When that connection is missing or broken, your site keeps showing 'In stock' after the product is gone.

This usually happens in three scenarios. First: stock levels are updated manually - someone on the team logs into the admin panel and changes the numbers. Second: there's automatic sync, but it runs once a night. Third: the product sells both online and offline, and the systems don't talk to each other.

The result is the same: a customer sees a 'Buy' button, places an order, and an hour later gets a call saying the product isn't available.

What an error costs

A customer whose order gets cancelled almost never comes back. They already made the decision, went through the entire checkout process, mentally committed to the purchase. Cancellation feels like betrayal, even when you apologize.

If the order was prepaid, you now have to process a refund. It's technically possible, but it takes time, involves accounting, and the customer spends all that time anxious. For marketplaces and aggregators, every cancellation means a penalty or a ratings drop.

There's also the flip side: when your site shows 'Out of stock' for a product you actually have, you lose orders you could have fulfilled.

How to set up stock tracking

The right approach is to connect your site to wherever you keep real inventory records. Usually that's 1C, MoySklad, Bitrix24, or a cloud warehouse system. The site pulls stock data from there and displays it on the storefront.

The connection happens through an API. The inventory system sends data in a structured format, the site receives it and updates product pages. When a customer places an order, the site reserves the item - it sends back a command that one unit is now spoken for. After payment or order fulfillment, the system deducts the item permanently.

If you have no inventory system at all, you need to set one up first. Without it, sync is pointless - there's nothing to sync with. For a small shop, Google Sheets with a script will work, but that's a temporary solution at launch.

How often to update stock

Once a day is bad. In a day, an item might sell five times, and only at night does the site learn it's gone. Updates should happen at least once an hour, preferably every 10-15 minutes.

Real-time sync (where every change in the warehouse system instantly hits the site) isn't always necessary. It makes sense when the product is popular, turnover is high, and minutes matter. Or when you're selling simultaneously through the site, a physical store, and marketplaces - then an hour's delay is critical.

In practice, for most online stores, updates every 15-30 minutes are enough. It's technically simpler, cheaper, and gives acceptable accuracy.

What to do with goods in transit

Some stock may be formally available but physically inaccessible: reserved for another order, sitting in receiving, waiting in returns. If you show that as available, the problem repeats.

You need to separate stock by status. Available for sale - what can ship right now. Reserved - assigned to placed orders. In transit - coming from a supplier. The site shows only the first category.

Some stores show items as 'made to order' or 'expected in a week.' That's honest, but only works if you actually meet the timeline. Better to let customers place a pre-order than to write 'In stock' and then cancel.

Multiple warehouses, one storefront

If stock sits in different cities or multiple warehouses, you need to decide what to show the customer. Two options: show the total from all warehouses, or determine the warehouse by geolocation and show stock only from the nearest one.

The first option is simpler, but a customer in Moscow might order an item that's only in Novosibirsk. Then delivery takes a week instead of two days. The second option is more honest but requires city detection and warehouse selection logic.

We usually do this: show the total stock, but at checkout we confirm the city and immediately state the timeline. If the item isn't at the nearest warehouse, we offer to wait or choose an alternative.

When stock tracking isn't needed

If you sell services, digital products, or work on pre-order, stock sync isn't necessary. There's no point for made-to-order goods either - custom furniture, printing, customization.

You also don't need it in the first months of operation, when orders are few and you have time to check availability manually before confirmation. But once order volume grows or you add automatic confirmation, you can't postpone integration.

Sometimes an owner is afraid to show stock levels because they're low: 'The customer will see there's only one left and think the store is struggling.' That's a mistake. Better to show the truth than to sell something that doesn't exist.

How it works in practice

First we check where inventory is tracked. If it's 1C, we connect an exchange module - it can send stock via API. If it's MoySklad or another cloud system, we use their ready API. We write a script that fetches the data and updates the site's database.

Next we set up reservation. When a customer adds an item to cart, nothing happens - carts get abandoned. When they place an order, the item is reserved for 24 hours. If they don't pay within that time, the reservation lifts. If they do pay, the item is deducted.

On the product page we show status: 'In stock,' 'Low stock,' 'Out of stock,' 'Made to order.' We set the 'low stock' threshold individually - for a fast-moving item it might be 10 units, for a rare one, 2. This helps customers decide faster.

What can break

The most common problem is the inventory system's API going down or returning errors. The site can't update stock and keeps showing old data. To prevent this, we add logging: if an update fails, the system sends a notification.

Second problem - stock updated, but a manager in 1C entered the wrong number. Technically everything works, but the data is wrong. This is solved only by procedure: who enters changes, when, and how.

Third - a customer placed an order in the last second when the item was still there, but reservation didn't trigger in time. For this, at final order confirmation we do a check: if the item is already gone, we show a message before payment, not after.