Real-time inventory and customer pricing in ecommerce search

Stale stock costs a distributor an order line, a phone call and a measure of trust every time it happens. The buyer adds an item the storefront says is available. The ERP rejects or back-orders it at fulfilment. Someone in customer service calls to explain. The retailer has a gap on the shelf and a reason to check a competitor's portal next time.

The cause is almost always a sync schedule. Stock changes in the ERP every few minutes during business hours. A storefront refreshed hourly is wrong for most of the hour. A storefront refreshed nightly is wrong all day.

Price belongs in search results because B2B buyers compare in the result list, not on the product page. A buyer scanning twelve variants of a disposable vape is deciding between flavours, puff counts and pack sizes at speed. If price and stock appear only after a click, every comparison costs a page load and the buyer gives up or guesses.

Showing both values in results also removes the most common complaint in B2B portals: "the price I saw is not the price on the invoice". When the result list reads the account's price from the same source as the invoice, the two cannot disagree.

A distributor's ERP typically holds four kinds of price for the same product. Search must resolve the right one per account on every query.

The hard case is precedence. A contract price should beat a tier price. A promotion may or may not beat a contract. The ERP already encodes these rules. Search that reads price lists directly inherits them. Search that syncs one price per product cannot.

Every result should carry one of four stock states, each read from the ERP, each distinguishable by text as well as colour.

• In stock, with the quantity available at the buyer's default location.
• Low stock, below a threshold set per category or per SKU, so buyers can order before it is gone.
• Backorder, with the ERP's expected date, so buyers can choose to wait or substitute.
• Discontinued, shown only to accounts that have ordered the item before, with the replacement, when the ERP holds that history.

Showing quantity rather than a bare "in stock" label matters in wholesale. A retailer ordering 40 cases needs to know whether 38 or 1,240 are available.

Multi-warehouse availability shows stock per fulfilment location, with the buyer's default branch first. A retailer who collects from a local branch needs to see that branch's shelves, not a national total that includes stock three states away. The ERP usually holds quantity per warehouse already. Search should surface it rather than summing it. Confirm that split for the ERP you run before you rely on it.

Some products may only be sold to licensed accounts, in certain states, or to specific customer groups. In regulated categories such as vape and tobacco this is a compliance requirement, not a preference. Search must honour the ERP's restrictions so that an account never sees, let alone orders, an item it may not buy. A search tool that indexes a flat product feed has no way to know these rules exist.

Live values reach search results in four steps when the index reads the ERP directly, and in six or more when a sync layer sits between them.

1. A quantity or price changes in the ERP.
2. The search index receives the change, as an event or by reading the changed rows.
3. The affected index records update.
4. The next query returns the new value.

No cache to clear and no sync job to trigger. Shopsense is a B2B ecommerce search engine for distributors and wholesalers that connects directly to ERP systems. A published latency will be added here when it has been measured on a named catalog. The guide to ERP-integrated ecommerce search compares the two architectures.

1. Change a quantity in the ERP and time how long until search shows it.
2. Sign in as two accounts in different tiers and search the same SKU. Do you see two prices?
3. Find a backordered item. Does search show the expected date?
4. Find a product restricted to licensed accounts. Sign in as an unlicensed account. Does it appear?
5. Search from a branch customer's account. Is the branch quantity shown first?
6. Compare the price in a result against the last invoice for that account.