Always know exactly what you have

Event-driven from the ERP, typically within seconds. Polling every five minutes is either too slow or hammers your ERP — a queue with events avoids both.

Yes — availability is calculated across locations with rules you define: nearest first, cheapest shipping first, or a strict priority order. The rules are explicit and testable, not buried in a plugin.

Reservations at cart or order level, depending on how tight your stock is. We agree the rule with you explicitly, because the right answer differs between a warehouse of spare parts and one of made-to-order machines.

Often it can, and then you should not buy a second system to do it worse. Check first whether the ERP already knows your stock correctly and is simply too slow or too painful to use — that is an interface problem, not a missing system. We build a stock tool when the ERP genuinely cannot model your reservations, locations or lead times.

It will show you how wrong they are, faster. That is worth a lot, but it is not the same as fixing them. Wrong stock almost always comes out of a process: goods booked in on Friday, returns nobody records, the pallet someone took without scanning. The software makes those gaps visible and cheap to close. It cannot count your shelves for you.

Yes, if you are willing to model the boring parts: open purchase orders, supplier lead times, and what is already reserved for someone else. Then the date on the page is a date you can keep. In B2B that beats a fast date — your customer plans around it, and a broken promise costs more than an honestly longer one.

The shop keeps selling against the last known levels, and every movement that could not be delivered waits in the queue instead of being lost. When the ERP comes back, the queue drains in order and the jobs are idempotent, so a retry never books the same reservation twice. What you decide beforehand is how long you are willing to sell on stale numbers.