Why B2B Search Plays by Its Own Rules

B2B buyers usually know what they want. In B2B implementations at foobar Agency we routinely see a significant share of search queries that aren’t generic product terms but rather SKUs, part numbers, norm designations or technical measurements. A search for “M8x40 galvanised” isn’t browsing behaviour — it’s direct access to a known item in the assortment.

This has consequences for ranking: in B2C, exact match is one component alongside personalisation, sales data and trends. In B2B, an unambiguous SKU or part number search must almost always surface the exact item at the very top — before synonyms, recommendations or personalisation models step in. Search platforms that optimise their ranking primarily on click-through behaviour run into a use case they rarely serve well: professionals click because they have to, not because the ranking convinced them.

Then there’s re-order behaviour. A large share of B2B orders are repeat purchases. B2B search is therefore often not a discovery tool but a fast access path to known items — and should behave accordingly. What your search logs reveal — which part numbers don’t hit, which synonyms are missing, which repeat searches fail — is one of the most precise data foundations a B2B shop has. Anyone who doesn’t analyse it leaves revenue potential buried in the index.

In B2C, personalisation means preferences, recommendations, curated picks. In B2B, it means something fundamentally different — it’s a matter of entitlement, not taste. Which items a buyer is allowed to see at all depends on the customer contract, account configuration, regional approvals and sometimes even the role of the employee within the customer organisation.

Platforms like commercetools, OroCommerce and Spryker model this logic through customer groups, business units or company hierarchies, and contract-bound price and catalogue lists. For search, that means the index must reflect the individual assortment of the authenticated buyer — not the shop’s total catalogue. An item a particular customer isn’t allowed to order has no business appearing in their result list. Not even as a greyed-out, “available on request” hit — that produces complaints, not orders.

Architecturally there are three common patterns: multi-tenant indices (one index per customer group), filtered indices (one shared index with visibility filtering at query time), and server-side re-ranking after the query. Which pattern holds depends on how large your assortment is, how many customer-specific assortments you serve and how often contracts change. The question is decided by scale and performance — and should be answered before the platform choice.

In B2B, different customers see different prices for the same item — and they see them not first on the product detail page but in the result list. Sort functions, filters and comparisons all hinge on that price. Anyone showing list prices in the result list and only fetching the contract price on click is sorting their result list incorrectly across every search query.

There are two architectural options. First: contract prices are pulled at query time from the ERP, the pricing engine or a caching layer and injected into the result list — which means latency and load. Second: contract prices are precomputed and written into the search index, per customer or customer group — which means index size and update frequency. Both paths are valid. Which one holds depends on the number of customers, the volatility of prices and the requirement for real-time consistency.

What doesn’t hold is the third option: showing only list prices and asking the customer to “verify the final price in the cart”. That is the point in live demos where CIOs stop following along.

B2B search doesn’t end at the shop domain. Via cXML — introduced by Ariba in 1999 and SAP-owned since the 2012 acquisition — and OCI, a SAP standard that has established itself as the de-facto norm in e-procurement, buyers land in the supplier catalogue from their ERP procurement tool. SAP Ariba supports both protocols; Coupa and Microsoft Dynamics 365 Supply Chain rely primarily on cXML. With the Level 2 variant of cXML, search and result rendering run directly inside the Ariba UI — hits from the supplier catalogue are rendered in the procurement interface without the buyer leaving the Ariba session. A B2B search must be API-capable for this and produce usable results in foreign UI contexts — including the correct contract prices.

Configurator-driven products are the second special case. An assortment where variants only emerge through selection — lengths, materials, coatings, tolerances — can’t work with classic SKU indexing. Search has to either bypass the configurator (base SKU as the hit, configuration on the PDP) or include the most common configuration variants as virtual SKUs in the index.

Third: stock and lead time. The Sana Commerce B2B Buyer Report 2025 names lack of transparency on inventory and delivery times as buyers’ most important frustration — 40 percent of respondents rank it as their top issue. Search results without current stock data produce orders that collapse at the confirmation stage — and damage trust, which in B2B takes longer to rebuild than a click takes to lose.