Chatbot showing outdated stock: what it should say when your system is down

The problem is not the stale number

A chatbot showing outdated stock looks like a sync problem. It is not.

The problem shows up a second later: the customer confirmed a purchase you will not be able to fulfil. Now you have to write back and take it away, and that costs more than never having sold it.

The question that matters is not how often the catalogue refreshes. It is what it says when it cannot know.

The three ways it goes stale

Worth separating, because they have different fixes.

Situation	What causes it	How it gets fixed
The data arrived late	Sync runs every X hours	Shorten the interval, or sync on demand when you change something
The data never arrived	Sync has been failing and nobody noticed	Get told when the catalogue stops arriving
The data cannot be read	Your system is not responding right now	Have the answer say it does not know

The first two are solved with configuration. The third is the one that decides whether automated support helps you or gets you in trouble.

What it should say when your system does not answer

There are exactly two possible behaviours, and the gap between them is the gap between a tool and a headache.

The bad one: assume there is stock and carry on. The customer confirms, the order is created, and the problem shows up in the warehouse.

The right one: say it cannot confirm availability right now, and wait. It does not invent a number, does not say yes just in case, and does not end the conversation.

With Alumbra it is the second, and it is written as a product limit, not as an intention. When the system cannot be reached at the moment an order is confirmed, the answer is that availability is unknown. It never presents a guess as stock you have.

What happens when there is less than they asked for

This is the in-between case and the one most often handled badly.

The customer asked for ten units and there are four. The comfortable move is to build the order with four and mention it later. Comfortable for the system and terrible for the customer, who finds out when there is nothing they can do.

What is right is to say what there is, item by item, and wait for an answer. The customer decides whether to take four, wait, or switch to something else. Trimming the order silently is making a commercial decision that is not yours to make.

How to avoid getting there

Four things, in order of how much they pay off.

1. Have the catalogue come from your system, not from a copy. If you enter price and stock twice, they will diverge.
2. Pick the refresh interval your system can handle. More often is not always better: if your provider has limits, pushing past them breaks sync entirely.
3. Sync on demand right after you change something. A price-list change does not wait for the next cycle.
4. Get told when the catalogue stops arriving. A sync that fails silently is worse than no sync.

Point four is the one most often missing. A frozen catalogue keeps answering with data that looks fine.

Prices follow the same rule

Everything above applies to prices, and there the mistake costs more.

An invented price is a commercial promise. If automated support improvises a figure because it could not read the real one, you either honour it or you look bad. The rule is the same: the price comes from your system or it does not come at all.

Conclusions

• The cost of stale stock is not the number, it is having to take it back.
• What defines the tool is what it says when it cannot check.
• "I cannot confirm that right now" is the correct answer, not a failure.
• If there is less than asked for, say so and wait: trimming silently decides for the customer.
• A sync that fails without telling you is worse than no sync at all.