A procurement officer at Horizon Hotels does not browse Zen Electron Trade for inspiration. They open the catalog knowing they need 40 of a specific monitor, at their negotiated price, in stock, today. That intent is the opposite of a consumer discovering products through merchandising. Before configuring search for B2B, it helps to understand how the B2B buyer's goal reshapes what "search" has to do.
Task-driven, not discovery-driven
B2C storefront search is optimized for discovery: relevance ranking, recommendations, and merchandising that surface products a shopper did not know they wanted. Conversion depends on inspiration.
B2B browsing is optimized for efficiency and precision. The buyer typically arrives with intent and wants to:
- look up a known SKU directly,
- filter to their assortment and their price tier,
- check availability, and
- select many line items in one session, often hundreds of SKUs per order.
The session is a task to complete, not a catalog to explore. This shifts the architectural priority from relevance tuning to scoped, price-aware, fast retrieval across a potentially large catalog.
Product Search fits the B2B task
Product Search is the capability built for this. It is an indexed search surface that supports full-text and non-exact queries (prefix, wildcard, fuzzy), faceting for catalog navigation, and filtering and faceting on price, Channel, Customer Group, Store, and Product Selection. Because the buyer's commercial context is expressed through those resources, Product Search lets you return only what a buyer is entitled to see, priced the way they negotiated.
A key design trait is that Product Search is ID-first: a search returns matching Product IDs quickly, and you fetch the product data you need to render in a second step. This favors low response times over returning full resources, which suits B2B catalogs that are large and queried heavily.
Choosing a product-retrieval method
commercetools offers three ways to retrieve product data. Choosing the right one is the first decision for any browsing feature.
| Method | Use it for | Trade-off |
|---|---|---|
| Product Search | Storefront and buyer-portal catalog browsing: full-text, faceting, price-aware filtering | Indexed data, so it is subject to an indexing delay |
| Query Product Projections | Cases where real-time accuracy matters more than speed | Slower than Product Search for typical storefront queries |
| Query Products | Back-office product management needing current and staged data | Returns the full resource; not for storefront browsing |
For a B2B buyer portal, Product Search is the default. Reach for Query Product Projections only when a specific view cannot tolerate the indexing delay, and for Query Products only in back-office tooling.
Product Search is indexed and eventually consistent: a just-changed price or a newly published Product may take a short time to appear. Never use search (or Product Projection
availability) as the source of truth for live stock; use the Inventory API for that. Treat search as the fast browsing surface, not the system of record.Key takeaways
- B2B search is task-driven (known-SKU lookup, price-tier filtering, bulk selection), where B2C search is discovery-driven (relevance, recommendations, merchandising).
- Product Search fits B2B because it scopes results by price, Channel, Customer Group, Store, and Product Selection, the same resources that define a buyer's commercial context.
- Product Search is ID-first: it returns matching IDs fast, and you fetch product data to render in a second step.
- Choose Product Search for buyer-facing browsing, Query Product Projections when real-time accuracy outweighs speed, and Query Products only for back-office management.
- Product Search is indexed and eventually consistent; use the Inventory API for live stock.