AI Conversational Product Finder

Why Filters Alone Are Not Enough

HellermannTyton supplies cable management and bundling solutions worldwide. Its catalogue contains around 8,000 products, each with up to 120 technical attributes, including material, temperature range, UV resistance and bundle diameter.

Many of these products look similar. Cable ties, clamps and connectors come in dozens of variants. A customer looking for a heat-resistant cable tie for outdoor use in the automotive industry may not know whether to filter by "temperature range", "UV resistance" or "application area". The catalogue offers separate filters for all three.

To find the right product quickly, customers needed to understand the attribute system. As a result, many preferred to contact the sales team directly.

Our Goal

Customers should be able to describe what they need in everyday language and receive matching products. They should not have to learn HellermannTyton's internal attribute system first.

How We Approached It

We started with UX research. Before writing a single line of code, we investigated how customers actually search for products. What words do they use? How much do they know about the catalogue? In most cases, very little.

We built the solution in three phases. First, we created mockups and a UX concept that translated real customer questions into product attributes. Next, we developed a traditional chatbot to test whether a conversational approach would work at all. Once that was established, we replaced the scripted flows with a large language model (LLM) capable of understanding context and narrowing down the results itself.

The Team

UX design, AI engineering, backend and frontend development, and Bloomreach integration. Everyone worked together from the beginning. The AI engineers participated in the UX sessions, and the developers helped shape the conversational flow. There were no rigid handovers between phases.

6 Months to Production

The first version went live after six months. The biggest effort was integrating the solution into the existing enterprise technology stack. HellermannTyton was already using Microsoft technologies throughout its infrastructure. Product data was stored in a PIM system, and search was powered by Solr. The chatbot needed to build on these existing systems.

How the Pieces Fit Together

We did not build a separate product database for the AI. Instead, it operates as an additional layer on the same PIM and Solr infrastructure that powers the existing product search.

The chatbot interface is embedded in the Bloomreach Hippo CMS. A gateway service within the CMS application orchestrates the conversation. It receives each customer message, coordinates the AI calls, retrieves relevant products and content, and sends a structured response back to the frontend.

What Happens When a Customer Asks a Question

Each query goes through two separate AI calls. This approach is known as Retrieval-Augmented Generation (RAG).

1. Intent Detection

The message is sent to Azure OpenAI (GPT-4o), which determines what the customer wants: a product search, a content-related question or a product comparison. It extracts a normalized search query from the natural language input. This call runs with zero randomness to ensure consistent classification.

2. Retrieval

Based on the identified intent, the gateway service queries Apache Solr for product data and Azure Cognitive Search for editorial content, such as technical guides and application notes. Both systems were already in place.

3. Response Generation

The retrieved products and content are passed into a second AI call. The model now has both the customer's question and the relevant data. It generates explanatory text and specific product recommendations, highlighting the attributes that matter for the particular query. If the results are too broad, it asks a follow-up question.

Both AI calls return structured JSON according to a fixed schema. The frontend receives typed data and renders it directly as product cards, comparison tables or follow-up questions.

The Stack

Everything runs on infrastructure that HellermannTyton already had in place. We added a Spring Boot service for the AI logic and integrated it with the existing CMS, search index and cloud environment. No new vendors or additional hosting were required.

• CMS & Frontend: Bloomreach Hippo 16, server-rendered templates, Alpine.js

• Chatbot Service: Java 21, Spring Boot, Spring AI

• AI Model: Azure OpenAI GPT-4o, JSON Schema Strict Mode

• Product Search: Apache Solr, indexed from the existing PIM

• Content Search: Azure Cognitive Search

• Hosting: Microsoft Azure (the customer's existing cloud environment)

What We Delivered

The result is a product finder that works like a conversation. Customers describe what they need in their own words, and the AI determines which combination of the 120 attributes matches their requirements. Most queries are resolved in two to three steps.

What Has Changed

First-time customers can now find products on their own. The number of incorrect orders has decreased because customers are less likely to select the wrong product variant. The sales team spends less time handling basic enquiries and more time providing valuable advice. The tool continues to be developed and improved.

Why This Case Is Interesting

Many enterprise AI projects start by building something entirely new: a new database, a new frontend and new infrastructure. At HellermannTyton, we integrated AI into the existing systems. The product data stays where it is and can now also be accessed through a conversation.

AI does not replace product search. It creates a second way to find products for people who are not familiar with the terminology of 120 technical attributes.