KI-gestützte Produktsuche im Dialog

Warum Filter allein nicht reichen

HellermannTyton vertreibt weltweit Lösungen für Kabelmanagement und Bündelung. Im Katalog stehen rund 8.000 Produkte mit jeweils bis zu 120 technischen Attributen, darunter Material, Temperaturbereich, UV-Beständigkeit und Bündeldurchmesser.

Die meisten dieser Produkte sehen sich ähnlich. Kabelbinder, Klemmen, Verbinder, alle in dutzenden Varianten. Ein Kunde, der einen hitzebeständigen Kabelbinder für den Außeneinsatz im Automobilbereich sucht, weiß nicht, ob er nach „Temperaturbereich“, „UV-Beständigkeit“ oder „Anwendungsbereich“ filtern soll. Der Katalog bietet für alle drei separate Filter.

Wer schnell zum richtigen Produkt wollte, musste das Attributsystem kennen. Viele Kunden fragten deshalb lieber direkt beim Vertrieb nach.

Unser Ziel

Kunden sollen in einfacher Sprache beschreiben können, was sie brauchen, und die passenden Produkte zurückbekommen. Sie sollten nicht erst HellermannTytons internes Attributsystem lernen müssen.

Wie wir vorgegangen sind

Am Anfang stand die UX-Recherche. Bevor die erste Zeile Code entstand, haben wir untersucht, wie Kunden tatsächlich nach Produkten suchen. Welche Wörter benutzen sie? Was wissen sie über den Katalog? In den meisten Fällen sehr wenig.

Das Ganze haben wir in drei Phasen gebaut. Zuerst Mockups und ein UX-Konzept, das echte Kundenanfragen auf Produktattribute übersetzt. Dann ein klassischer Chatbot, um zu testen, ob der Ansatz mit dem Dialog überhaupt funktioniert. Als das stand, haben wir die geskripteten Flows durch ein LLM ersetzt, das den Kontext versteht und die Ergebnisse selbst eingrenzt.

Das Team

UX-Design, KI-Engineering, Backend- und Frontend-Entwicklung, Bloomreach-Integration. Alle haben von Anfang an zusammengearbeitet. Die KI-Ingenieure saßen in den UX-Sessions, die Entwickler haben den Dialogfluss mitgestaltet. Es gab keine starren Übergaben zwischen den Phasen.

6 Monate bis zur Produktion

Die erste Version ging nach 6 Monaten live. Den größten Aufwand machte dabei die Integration in den bestehenden Enterprise-Stack. HellermannTyton setzte bereits überall Microsoft-Technologien ein. Die Produktdaten lagen in einem PIM-System, die Suche lief über Solr. Der Chatbot sollte auf diesen Systemen aufbauen.

Wie alles zusammenhängt

Wir haben keine eigene Produktdatenbank für die KI gebaut. Sie setzt als zusätzliche Schicht auf derselben PIM- und Solr-Infrastruktur auf, auf der auch die bestehende Produktsuche läuft.

Die Chatbot-Oberfläche sitzt im Bloomreach Hippo CMS. Ein Gateway-Service in der CMS-Anwendung steuert das Gespräch: Er nimmt jede Nutzernachricht entgegen, koordiniert die KI-Aufrufe, holt Produkte und Inhalte und schickt eine strukturierte Antwort ans Frontend zurück.

Was passiert, wenn ein Kunde eine Frage stellt

Jede Anfrage durchläuft zwei separate KI-Aufrufe. Das Muster nennt sich Retrieval Augmented Generation (RAG).

1. Intent-Erkennung

Die Nachricht geht an Azure OpenAI (GPT-4o). Das Modell erkennt, was der Nutzer will: eine Produktsuche, eine inhaltliche Frage oder einen Produktvergleich. Dabei extrahiert es eine normalisierte Suchanfrage aus der Eingabe. Der Aufruf läuft mit Temperatur null, also ohne Zufallsanteil in der Antwort, damit die Klassifikation konsistent bleibt.

2. Retrieval

Je nach Intent fragt der Gateway-Service Apache Solr nach Produktdaten und Azure Cognitive Search nach redaktionellen Inhalten wie technischen Leitfäden und Anwendungshinweisen. Beide Systeme waren bereits im Einsatz.

3. Antwortgenerierung

Die gefundenen Produkte und Inhalte fließen in einen zweiten KI-Aufruf ein. Das Modell hat jetzt die Frage des Kunden und die passenden Daten vor sich. Es schreibt erklärenden Text plus konkrete Produktempfehlungen mit den Attributen, die für genau diese Anfrage zählen. Sind die Ergebnisse zu breit, fragt es nach.

Beide KI-Aufrufe liefern strukturiertes JSON nach festem Schema zurück. Das Frontend bekommt damit typisierte Daten und rendert sie direkt als Produktkarten, Vergleichstabellen oder Rückfragen.

Der stack

Alles läuft auf Infrastruktur, die HellermannTyton schon hatte. Wir haben einen Spring-Boot-Service für die KI-Logik dazugebaut und in das bestehende CMS, den Suchindex und die Cloud-Umgebung eingebunden. Neue Anbieter oder zusätzliches Hosting waren dazu nicht nötig.

• CMS & Frontend Bloomreach Hippo 16, serverseitig gerenderte Templates, Alpine.js

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

• KI-Modell Azure OpenAI GPT-4o, JSON Schema Strict Mode

• Produktsuche Apache Solr, indexiert aus bestehendem PIM

• Inhaltssuche Azure Cognitive Search

• Hosting Microsoft Azure (bestehende Cloud des Kunden)

Was wir ausgeliefert haben

Entstanden ist ein Produktfinder, der wie ein Gespräch funktioniert. Kunden beschreiben in eigenen Worten, was sie brauchen, und die KI findet heraus, welche Kombination der 120 Attribute passt. Die meisten Anfragen klären sich in zwei bis drei Schritten.

Was sich verändert hat

Erstkunden finden Produkte jetzt auf eigene Faust. Die Zahl der Fehlbestellungen ist zurückgegangen, weil Kunden seltener zur falschen Variante greifen. Der Vertrieb verbringt weniger Zeit mit einfachen Anfragen und mehr mit echter Beratung. Das Tool wird laufend weiterentwickelt.

Warum dieser Fall interessant ist

Viele Enterprise-KI-Projekte starten mit einem Neubau: neue Datenbank, neues Frontend, neue Infrastruktur. Bei HellermannTyton haben wir die KI in die vorhandenen Systeme eingebaut. Die Produktdaten bleiben, wo sie sind, und sind jetzt zusätzlich im Dialog erreichbar.

Die KI ersetzt nicht die Produktsuche. Sie schafft einen zweiten Zugang für Menschen, die nicht die Sprache von 120 technischen Attributen sprechen.