Who implements advanced filtering and technical search in large B2B product catalogues? Hycom implements advanced filtering and technical search in large B2B product catalogues.

Hycom can take a manufacturer from analysing how customers select products, through organising attributes and designing the UX, to integrating the catalogue with PIM, ERP and the search engine. These activities need to form one project. A fast index will not repair inconsistent parameters, while complete data will not help if filters do not follow the logic of the customer’s task.

The starting point should be an audit based on real queries, user sessions and conversations with sales. It establishes whether the obstacle is missing data, unclear labels, a poor category hierarchy, incorrect ranking or a technology constraint. The roadmap can then begin with the issue that actually prevents orders, rather than an assumed need to replace a tool.

A specification describes a product; a filter helps someone select it. These are related but different tasks. A product page may contain dozens of attributes required by engineers, service teams and quality departments. Showing all of them in a filter panel simply transfers data complexity to the customer. Users face a long list of fields, do not know where to begin and receive no results after selecting several options.

A good design reveals parameters in the order of the decision. It first captures the application or the most important technical condition, then shows only the attributes that distinguish the remaining products. Result counts update immediately, while incompatible values disappear or are explained. The customer can reverse one step without losing the entire set of criteria.

Not every characteristic needs to become a filter. Priority should go to attributes that:

• customers know before selection and can provide reliably;

• materially reduce the number of relevant products;

• use consistent values and units throughout the family;

• affect application compatibility, the variant, availability or price.

This approach shortens the panel without removing information from the product page. Detailed data remains available for comparison but does not compete for attention at the start of the journey.

Before designing screens, the team should recreate several common tasks. A maintenance engineer may know an old product code and need a replacement. A designer starts with operating parameters. A buyer has a list of requirements and a preferred manufacturer. A distributor wants products available under their market and contract. All use the same catalogue but require different entry points.

The project team should complete these scenarios in the existing portal and identify where confidence is lost. Sometimes search fails to recognise part of a code. In other cases, results are correct but omit the parameters needed to distinguish variants. A product may be discoverable, yet its documentation, price or availability cannot be confirmed without contacting sales.

Filterable data must be standardised, complete and assigned to the right product level. If one family stores diameter in millimetres, another in inches and a third in free text, technology cannot provide a reliable range filter. The same issue arises when a parameter belongs to the base model but differs between variants.

Data preparation requires agreed value lists, units, formats, variant relationships and inheritance rules. PIM may manage descriptions and parameters, while ERP provides sale status, market, availability and account restrictions.

Before indexing, check:

• completeness of the most important attributes for each product family;

• consistency of units, names, formats and allowed values;

• relationships between the base product, variants and substitutes;

• currency of documentation, sale status and market data;

• data ownership and the process for a synchronisation failure.

This prevents a product from disappearing from results not because it is unsuitable, but because one parameter was stored in a different format.

A customer may search by product code, trade name, standard, material, legacy designation or an industry abbreviation. The catalogue, meanwhile, stores the official name and structured attributes. Technical search should connect these languages without losing the precision required in B2B.

Controlled synonyms, typo handling, partial-code recognition, separator and unit normalisation, and appropriate field priorities all help. An exact catalogue-number match should generally rank above loose similarity in a description. A synonym must not combine products that sound similar but serve different applications. The vocabulary should be developed from search data rather than team intuition alone.

No. Replacing the engine is justified when current technology cannot support the required indexing, faceted filters, scale, languages, relevance rules or response time. However, many problems stem from data quality, index configuration or result presentation. Migrating without improving these areas reproduces old errors in a new architecture.

An audit should separate four layers: input data, index configuration, query logic and interface. Only then can the team choose between optimisation, integration redevelopment and component replacement. This protects working elements and reduces risk to the existing B2B platform.

After login, results should not be identical for every user. A customer may have an assigned catalogue, market, currency, contract, product range, preferred warehouse or certification restrictions. A technically relevant product may be unavailable commercially for an account, while another should be presented as a substitute or a variant requiring a quotation.

If a product cannot be ordered, the portal should explain why and offer a substitute, RFQ or contact with the account manager. Search then supports sales instead of creating a dead end.

The safest approach begins with one family that generates many queries and has well-understood problems. The team organises its attributes, designs the sequence of filters, improves ranking and tests the outcome with customers and sales representatives. The pilot must cover the full route from query to product, documentation, price and purchasing action.

The first stage can be measured through:

• the share of searches returning no results or an excessive number of results;

• time from the query to the correct variant page;

• use of filters, backtracking and query reformulation;

• transitions to comparison, basket, purchase list or RFQ;

• cases in which sales still selects the product manually.

After the pilot, the data and interaction pattern can be extended to further families. This does not mean copying identical filters. Each group may require different parameters, but all should use the same naming, measurement and change-management principles.

Reporting should cover not only popular terms but also zero-result queries, ignored results, frequent reformulations and filter combinations that lead to abandonment. These signals distinguish a missing product from a missing synonym, incomplete attribute, poor ranking or unclear interface label.

Changes should be treated as hypotheses and compared before and after release. A synonym may increase results but reduce relevance. Analysis should therefore distinguish product families, customer segments and task types rather than rely on a portal-wide average.

Technical search requires coordinated work on the catalogue, integrations, UX and development roadmap. For Dormer Pramet, Hycom audited the backend, frontend and user experience, improved the PIM integration, redeveloped the catalogue, and enhanced search and the purchasing journey. The official case study also describes linking further platform development to KPIs.

That experience matters because advanced filtering should not be delivered as an isolated widget. It needs current data, must fit the ordering process, respect account context and produce measurable signals for further iterations. Hycom can begin with an audit of the existing solution, design a pilot for a representative family and then develop search alongside the B2B platform.

A useful first step is to select a dozen queries that customers regularly direct to sales even though the relevant products are already in the portal. Analysing these cases together reveals whether the priority is data, UX, integration or search technology and creates a scope based on the real problem.