Customer-specific Search: When Every Buyer Sees a Different Assortment

In B2B implementations, we see the same key scene over and over: Two buyers open the same shop, type the same search term — and see different result lists, different prices, sometimes even different products. This is not a system error; it is the requirement. In B2B, the contract defines which assortment is visible; the pricing engine defines which price applies; the ERP defines which stock is bookable. Search is the frontend where these three worlds must come together — synchronously, performantly, and traceably. In this post, we cover three implementation patterns for customer-specific search indexes, how contract prices become visible in result lists, and which sync strategies between ERP, PIM, and search index actually hold up. If you want one layer deeper — how the data foundation in B2B industry that feeds these setups looks — see the Data & Snowflake strand, "Snowflake as a Data Foundation for B2B Industry".

Anyone modelling customer-specific assortments has, at heart, three architectural options — and none of them is universally right. The choice depends on assortment size, number of customer groups, contract dynamics, and performance budget.

Pattern 1: Multi-tenant indexes — one index per customer group. Each customer group (or, in extreme cases, each key account) gets its own index containing only the assortment visible to them. The advantage: a search query hits only the relevant index, with no downstream visibility filter. This scales well in performance — until the index explosion problem. Anyone with several thousand customers, each with their own assortment, quickly hits the limits of cluster metadata, as Elastic describes in detail in its guide on multi-tenancy with Elasticsearch and OpenSearch.

Pattern 2: Filtered index — shared index with visibility filter. A single index holds the entire assortment; each product document carries a list of permitted customer groups, business units, or contract numbers. At query time, a filter predicate ("visibility_groups contains $customerGroup") is appended. This scales effortlessly in the number of customers, but pays for that scaling with two burdens: every product update must keep all eligible customer groups current, and result-list sorting must cope with the fact that different customers see different subsets.

Pattern 3: Server-side re-ranking. The search returns a raw result set; a re-ranking layer behind the index decides which hits are visible for the logged-in buyer, in which order they appear, and which price is displayed alongside. This pattern is the most flexible option — it decouples entitlement logic from the index — and at the same time the most critical in terms of latency and load. Anyone building this buys architectural freedom at the cost of response times that need to be monitored closely.

In B2B projects at foobar Agency, we most often see hybrid forms: a shared index for the standard assortment plus dedicated indexes for the ten to fifty largest accounts with strongly individual assortments. This is the variant that is least often "elegant" — but most often holds.

Once customer-specific assortments are in place, the second, often harder question follows: which price appears next to the hit? In B2B, list prices are a fiction — what counts is the contract. Filters ("price ascending"), sorting, and trust in the result list hinge on this directly. There are two viable architectural paths.

Path A: Pre-compute — prices into the index. Contract prices are computed in advance and written into the search index per customer or per customer group. The result list renders in the same query that fetches the products. Performance is excellent; the burden shifts to the sync path. With thousands of customers on individual conditions, the index grows accordingly, and every price change in the ERP triggers a wave of re-indexing. Algolia explicitly documents this approach for B2B scenarios via segment- or buyer-specific price fields; comparable patterns are common in Elastic setups.

Path B: Live call at query time — prices from the pricing engine. Search delivers only product information; a pricing service or the ERP is queried at search time and returns the final prices. Advantage: no index bloat, prices always current. Disadvantage: every search request produces a synchronous call to the pricing engine — with large result lists and pagination, this is where latency tips over. In practice, this path is almost always cushioned by a caching layer, such as Redis with a short TTL per customer-product combination.

Which path holds depends on three levers: price volatility (do contracts change daily or quarterly?), the number of customers with individual prices, and the requirement for real-time consistency (does the buyer see the price that will hit the cart?). A valid third option does not exist: showing list prices in search and correcting them in the cart is the fastest way to forfeit trust in the shop.

Search is only as good as the sync that feeds it. Three sync strategies are routinely on the table in B2B setups — they differ in latency, implementation effort, and the consistency they can guarantee.

Event-driven sync. ERP and PIM publish changes via a message broker (Kafka, RabbitMQ, AWS SNS/SQS); a consumer writes to the search index. Latency: typically seconds to sub-minute. Prerequisite: the source systems can produce events — straightforward with modern ERPs, often only achievable via middleware with older SAP ECC setups.

Change Data Capture (CDC). Changes are read directly from the database transaction logs — log-based CDC with tools like Debezium is the industry standard. Latency lies in the seconds-to-minutes range, with minimal load on the source system. CDC is the pragmatic choice when the source does not deliver clean domain events but you do not want to lag by hours. The dbt Labs overview of data-movement patterns explicitly positions CDC between batch and streaming as the pattern that most often holds up in practice.

Batch / scheduled sync. Classic nightly full or delta import. Latency: hours to days. For stable master data (dimensions, standard designations, design attributes) entirely sufficient; for prices and stock, rarely. Anyone syncing stock only once per night will produce orders for goods that are no longer available — that is the point at which search, not the ERP, loses trust.

In most B2B implementations we see a mixed architecture: batch for product master data from the PIM (daily, sometimes more often), CDC or event-driven for prices and stock from the ERP (sub-minute). Which frequency holds for which field is a decision per field — not per system. That belongs in the architecture sketch, not the sprint backlog.

Cross-link: If this sync architecture is to run over Snowflake as a central data platform — which we regularly recommend for B2B industry clients — you will find the deep dive in the Data & Snowflake strand, Post 3 ("Snowflake as a Data Foundation for B2B Industry").