Product search and catalogue navigation in a NZ wholesale B2B portal: designing it for how buyers actually order

The standard advice on B2B portal product search — faceted filtering, autocomplete, relevance ranking — is written for a buyer who does not know exactly what they want and needs help discovering it. Most wholesale buyers are the opposite. A buyer at a NZ foodservice company placing a weekly order already knows the products, the quantities, and the codes. What they need is not discovery; they need speed.

Building a wholesale ordering portal with a consumer-browse mindset produces a portal that looks right and works slowly. This guide covers what wholesale product search and catalogue navigation actually needs to do, where the common design mistakes sit, and why the quality of search almost always comes down to the quality of product data in the ERP — not the search engine in the portal.

How wholesale buyers actually navigate a portal

In a well-functioning wholesale portal, product search is the second-most common ordering path — not the first. The first is reorder from history. Most established wholesale accounts place variations of the same order week after week. Buyers open their last order, adjust quantities, remove lines they do not need this week, and submit. They do not browse the catalogue. A portal that makes this path fast — last order visible on the home screen, one click to load it into a new order — handles the majority of order volume with no search interaction at all.

The second path is direct SKU search. When a buyer needs a product that was not in last week's order, they do not browse to it. They type the stock code — the distributor's code, the manufacturer's code, or a short name they know from years of use — and expect an exact match. NZ wholesale buyers, in particular, are code-first searchers: they work from price lists and order guides that are structured around codes, not product images.

Category browse is the third path, used primarily by new account contacts who do not yet know the product range and by buyers exploring products outside their usual order. It matters — but designing a wholesale portal that leads with catalogue browse at the expense of the reorder and code search paths is optimising for the minority use case.

The product data quality problem in NZ ERPs

The most common reason a wholesale portal's product search fails is not the search engine — it is the product data in the ERP. NZ on-premises ERP systems — Accredo, MYOB Exo, CSB-System, Pronto Xi — carry product records that were entered for internal operational use, not for buyer-facing search. A product description like BEEF MINS 500G CHL is unambiguous to a warehouse picker who already knows the product range. It will not match a buyer who searches for "chilled beef mince" or "500g mince".

The portal search index can only return results for terms that appear in the data it indexes. Cleaning up this gap by adding display names, fuller descriptions, and keyword fields to the portal — while leaving the ERP records unchanged — creates a second product description layer that immediately begins drifting from the ERP. New products added to the ERP miss the portal enrichment. Renamed products create mismatches.

The right fix is in the ERP: adding a display name field or a keyword field to the product record so that the portal can index rich descriptions sourced directly from the system of record. Some NZ distributors do this as part of the portal implementation, treating the integration project as a forcing function for product data improvement they have needed for years. It takes time, but it solves the problem at the source rather than compensating for it downstream.

Alternate codes and the part-number lookup problem

A NZ wholesale buyer may refer to the same product by three different codes: the distributor's stock code, the manufacturer's product code, and a barcode. In FMCG and food distribution, buyers routinely search using the manufacturer's reference from their own purchasing records — not the distributor's internal code. If the portal search index only carries the primary ERP stock code, these searches return nothing.

A portal search index built for wholesale needs to carry every code associated with a product that a buyer might plausibly search by: primary stock code, alternate stock codes, manufacturer's reference (if stored in the ERP), and barcode. Most NZ ERPs have fields for alternate codes and supplier references — they just are not always populated. Auditing these fields in the ERP before go-live, and making their population part of the new-product onboarding process, prevents the most common search failure mode.

Faceted filtering sourced from the ERP

Faceted filters for a NZ wholesale portal should reflect the practical attributes wholesale buyers use to narrow a product search — and those attributes must come from the ERP, not from manually maintained portal configuration.

For a food distributor, useful facets are: product category or range (sourced from ERP product group), supplier or brand (from ERP supplier record), pack size or unit of measure, temperature category (ambient, chilled, or frozen), and an in-stock or available-to-order toggle sourced from live ERP stock levels. These cover the practical filtering decisions a wholesale buyer makes.

The failure mode to design out is a facet that exists in the portal but has no products behind it. This happens when ERP product classifications are updated — a product group is renamed or reorganised — but the portal facets are maintained separately and not updated in sync. A buyer clicks a category and gets zero results. They conclude the portal is broken, not that the filter is stale. Keeping facets sourced directly from the ERP product classification fields, with automatic updates as ERP data changes, is the design that avoids this. Manually curated portal filters are a maintenance liability.

The quick-order pad: the pattern most portals miss

For buyers placing large, regular orders — 20 to 100 SKUs at a time — searching each product individually is not a viable workflow. These buyers arrive at the portal with an order already prepared: a list of stock codes and quantities from a spreadsheet, a previous week's picking list, or a count-and-order done on the floor. What they need is a way to submit that list without navigating through the catalogue at all.

A quick-order pad is a direct entry interface: paste or type a column of product codes and a column of quantities, and the portal resolves them against the product catalogue — respecting per-customer catalogue visibility and customer-specific pricing — and adds the valid lines to an order in one action. Unrecognised codes are flagged for review rather than silently dropped. The quick-order pad is the fastest ordering path for high-frequency buyers and for field reps ordering on behalf of customers from a prepared list.

Portals that do not include a quick-order path see high-frequency buyers revert to email and phone ordering within weeks of go-live. The portal saved time for occasional buyers; it added time for the buyers who were doing the most volume.

Three search and navigation failure modes to design out

1. Search returns no results for a valid product code. The buyer types the stock code they have used for three years. The portal returns nothing. Usually caused by a code format mismatch (spaces vs hyphens, leading zeros stripped during ERP export) or an alternate code not included in the search index. The diagnostic is to test search with every code format a buyer might realistically use before go-live, not just the canonical ERP format.
2. Facets with no products behind them. An ERP product category rename or restructure leaves portal facets pointing at classifications that no longer exist. Buyers click a category filter and get an empty result. Fix: source facet values dynamically from the ERP at query time rather than from a cached configuration list; any facet with zero matching products should be suppressed rather than shown as empty.
3. No fast reorder or quick-order path. High-frequency buyers who cannot quickly repeat a previous order or paste an order list will find a faster path — usually email or a phone call to the account manager. The portal reduces inbound order handling cost only if it captures those high-volume buyers; losing them to email means the portal only handles the smaller, less frequent orders where the operational saving is smaller.

What this means for portal design

A NZ wholesale distributor building or evaluating a B2B ordering portal should assess product search and navigation against the actual ordering patterns of their customer base, not against a generic e-commerce benchmark. If 70% of orders are reorders, the reorder path is the portal's most important feature. If buyers are primarily code-first searchers, alternate code coverage in the search index matters more than visual browse design. If any accounts place large structured orders, a quick-order pad is not optional.

The underlying requirement in all of these is a clean, complete ERP integration: product codes, alternate codes, product group classifications, supplier attributes, pack sizes, and live stock levels all flowing from the ERP into the portal's search index without manual intervention. Portals built on top of a partial or poorly-structured ERP product data set will have search problems that cannot be solved in the portal layer. The B2B trade portal vs e-commerce guide covers why the integration architecture is the core design decision for NZ distributors considering a customer ordering platform. If you are designing or replacing a wholesale ordering portal and want to understand what the ERP integration layer needs to carry, talk to the team — Zeabyte designs and builds B2B ordering platforms and the Accredo and ERP integrations that power them for NZ food and wholesale distributors.