KI-Chatbot für Produktkonfiguratoren: Varianten prüfen und Angebote vorbereiten

Ein B2B-Produktkonfigurator soll aus vielen Merkmalen eine technisch passende Auswahl machen. Ein KI-Chatbot kann dabei Fragen verständlich stellen, Fachbegriffe erklären und Anforderungen strukturieren. Er darf aber nicht selbst entscheiden, welche Bauteile kompatibel sind, welcher Preis gilt oder ob eine Variante lieferbar ist. Genau diese Trennung macht einen KI-Chatbot für Produktkonfiguratoren zuverlässig.

Dieser Leitfaden zeigt, wie Website-Betreiber einen dialoggeführten Konfigurator aufbauen: von stabilen Produktdaten über deterministische Regeln bis zur qualifizierten Übergabe an den Vertrieb. Das Ziel ist kein frei formulierter Produktvorschlag, sondern ein nachvollziehbarer Weg von den Anforderungen zu einer gültigen Auswahl oder zu einer klar markierten offenen Prüfung.

Produktkonfiguration ist kein freies Beratungsgespräch

Sprachmodelle sind gut darin, natürliche Formulierungen zu verstehen und Informationen verständlich wiederzugeben. Variantenlogik ist jedoch eine andere Aufgabe. Ob ein Profil zu einem Verbinder passt, ein Motor die benötigte Last bewältigt oder eine Oberfläche für den Einsatzort vorgesehen ist, muss aus freigegebenen Daten und Regeln hervorgehen. Wahrscheinlich klingende Antworten reichen nicht.

NIST bezeichnet überzeugend präsentierte, aber falsche Inhalte generativer Systeme als Konfabulationen. Bei Produktberatung sind solche Fehler nicht nur redaktionell unsauber. Sie können zu unbrauchbaren Angebotsanfragen, falschen Erwartungen oder technisch unmöglichen Kombinationen führen. Deshalb sollte das Modell den Dialog führen, während ein Regelwerk die zulässigen Ergebnisse bestimmt.

Trennen Sie Gespräch, Regelwerk und Stammdaten

Eine robuste Architektur besteht aus drei klaren Schichten. Die Gesprächsschicht erkennt das Anliegen, stellt die nächste passende Frage und erklärt Ergebnisse. Die Regelschicht prüft Abhängigkeiten, Ausschlüsse, Pflichtmerkmale und Grenzwerte. Die Datenschicht liefert Produkt-IDs, Eigenschaften, Dokumente, Preise und Verfügbarkeit aus den jeweils zuständigen Systemen.

• Der Chatbot formuliert Fragen, fasst Anforderungen zusammen und erklärt eine geprüfte Auswahl.
• Die Regel-Engine entscheidet, welche Kombinationen gültig, ungültig oder prüfpflichtig sind.
• PIM, ERP oder Shopsystem liefern freigegebene Produkt-, Preis- und Bestandsdaten.
• CRM oder Angebotsprozess übernimmt den qualifizierten Datensatz mit nachvollziehbarer Herkunft.

Diese Grenzen sollten auch technisch sichtbar sein. Ein Tool für Variantenprüfung erhält strukturierte Merkmale und liefert IDs, Status sowie Begründungscodes zurück. Es sollte keinen langen Datenbankauszug an das Modell geben. Je kleiner der Vertrag, desto leichter lassen sich Berechtigung, Protokollierung und Tests kontrollieren.

Modellieren Sie Varianten mit stabilen IDs

Menschen sprechen von „der breiten Ausführung in Anthrazit“, Systeme brauchen stabile Kennungen. Verwenden Sie deshalb für Produktfamilien, Varianten, Merkmale und Werte eindeutige IDs. Anzeigenamen dürfen übersetzt oder redaktionell geändert werden, ohne dass die Regelbeziehungen dadurch brechen.

Auch Google empfiehlt für Produktvarianten eine gemeinsame Produktgruppe und variantendefinierende Eigenschaften. In den strukturierten Daten können unter anderem ProductGroup, variesBy, hasVariant und eine gemeinsame productGroupID verwendet werden. Das ist kein vollständiges Konfigurationsmodell, zeigt aber ein wichtiges Prinzip: gemeinsame Merkmale gehören zur Gruppe, unterscheidende Merkmale zur konkreten Variante.

Speichern Sie zusätzlich die Version des Regelwerks. Wenn sich eine Kombination später ändert, muss nachvollziehbar bleiben, welche Regeln bei einer früheren Anfrage galten. Ein Angebotsteam kann dann erkennen, ob eine Konfiguration weiterhin aktuell ist oder neu geprüft werden muss.

Führen Sie von Anforderungen zu gültigen Optionen

Ein guter Dialog beginnt nicht mit dem gesamten Katalog. Er fragt zuerst nach Merkmalen, die viele ungültige Pfade ausschließen. Bei einem modularen Beschattungssystem könnten das Einsatzort, lichte Breite, Befestigungsart, Witterung, gewünschte Bedienung und Oberfläche sein. Nach jeder Antwort prüft die Regelschicht, welche Optionen noch zulässig sind.

Der Chatbot kann dabei Fachbegriffe in Alltagssprache übersetzen: Warum wird die Befestigungsart benötigt? Welche Folgen hat eine Außenmontage? Was unterscheidet manuelle und motorisierte Bedienung? Die Erklärung darf nur aus freigegebenem Wissen stammen. Technische Grenzwerte werden nicht aus einem Fließtext erraten, sondern als strukturierte Regeln geprüft.

Mehrere passende Ergebnisse verständlich vergleichen

Bleiben mehrere Varianten übrig, sollte der Bot nicht willkürlich eine davon als „beste“ bezeichnen. Er kann geprüfte Unterschiede gegenüberstellen, etwa Material, freigegebener Einsatzbereich, notwendiges Zubehör oder dokumentierte Lieferform. Empfehlungen benötigen ein transparentes Zielkriterium. Ohne dieses Kriterium ist eine neutrale Auswahl mit Rückfrage ehrlicher.

Preis und Verfügbarkeit bleiben Quelldaten

Preis und Lieferbarkeit ändern sich häufiger als technische Beschreibungen. Sie gehören deshalb nicht in einen allgemeinen Wissensabschnitt, den das Modell frei wiedergibt. Fragen Sie beide Werte bei Bedarf aus der zuständigen Quelle ab und versehen Sie das Ergebnis mit Währung, Gültigkeitskontext und Zeitstempel.

Die Google-Merchant-Center-Spezifikation verlangt, dass Preis und Verfügbarkeit in Produktdaten mit Zielseite und Kaufprozess übereinstimmen. Für einen dialoggeführten Konfigurator folgt daraus eine praktische Regel: Wenn die Quelle keinen aktuellen Wert liefert, zeigt der Chatbot keinen geschätzten Ersatz. Er sagt stattdessen, dass der Wert im Angebot geprüft wird.

Auch Mengenstaffeln, kundenspezifische Konditionen, Montage, Versand oder projektabhängige Zuschläge müssen getrennt bleiben. Ein sichtbarer Basispreis darf nicht automatisch als verbindlicher Gesamtpreis bezeichnet werden. Die Antwort sollte genau benennen, welche Bestandteile bestätigt und welche noch offen sind.

Unvollständige Angaben dürfen kein Scheinergebnis erzeugen

Menschen überspringen Fragen, verwenden ungefähre Maße oder kennen technische Rahmenbedingungen nicht. Das System braucht deshalb drei Ergebniszustände: gültig, ungültig und prüfpflichtig. „Prüfpflichtig“ ist kein Fehler, sondern eine saubere Antwort, wenn Angaben fehlen oder eine Fachprüfung vorgesehen ist.

Beispiel: Eine Kundin nennt die ungefähre Breite, kennt aber den Untergrund der Befestigung nicht. Der Chatbot kann passende Produktfamilien eingrenzen, darf jedoch keinen konkreten Montagesatz bestätigen. Er markiert das offene Merkmal, erklärt warum es benötigt wird und nimmt es in die Angebotsübergabe auf. So entsteht ein brauchbares Briefing ohne falsche technische Sicherheit.

Vom Konfigurationsergebnis zum Angebotsbriefing

Am Ende sollte nicht nur ein Gesprächsprotokoll stehen. Erzeugen Sie ein strukturiertes Briefing mit Produktgruppen-ID, geprüften Varianten-IDs, gewählten Merkmalen, offenen Punkten, Regelwerksversion und Quellenzeitstempeln. Ergänzen Sie nur Kontaktdaten, für deren Erfassung ein klarer Zweck besteht.

Zeigen Sie die Zusammenfassung vor dem Absenden. Die anfragende Person kann Maße, Einsatzort und Auswahl korrigieren. Erst danach wird die Anfrage mit einer Idempotenz-ID übergeben, damit ein wiederholter Aufruf keine doppelten Leads oder Angebotsfälle erzeugt. Das Vertriebsteam erhält die entscheidungsrelevanten Fakten statt einer unstrukturierten, langen Unterhaltung.

Eine gute Übergabe benennt außerdem den Status: „technisch geprüft“, „vorläufig eingegrenzt“ oder „Fachprüfung erforderlich“. Sie verspricht weder ein Angebot noch einen Liefertermin, bevor der zuständige Prozess diese Aussage bestätigt hat.

Datenschutz und Berechtigungen begrenzen den Kontext

Eine öffentliche Produktberatung benötigt meist keine Identität. Kontaktdaten sind erst sinnvoll, wenn jemand eine Konfiguration speichern oder ein Angebot anfordern möchte. Sammeln Sie nur die erforderlichen Felder und erklären Sie den Zweck an der Stelle, an der die Daten benötigt werden.

Kundenspezifische Preise, frühere Projekte oder Vertragsprodukte gehören in einen authentifizierten Bereich. Die Anwendung prüft die Berechtigung; das Modell entscheidet sie nicht. Der Beitrag zum authentifizierten KI-Chatbot im Kundenportal beschreibt diese Grenze ausführlicher.

Mehrsprachige Varianten brauchen gemeinsame Kennungen

Übersetzen Sie Anzeigenamen, Erklärungen und Fragen, aber nicht die internen IDs. „Pulverbeschichtet“, „powder-coated“ und „revêtu par poudre“ müssen auf denselben Merkmalswert zeigen. So bleibt die Regelprüfung unabhängig von der Sprache und ein mehrsprachiges Angebotsteam arbeitet mit denselben Objekten.

Testen Sie Zahlenformate, Dezimaltrennzeichen, Maßeinheiten und übersetzte Synonyme. Ein Nutzer kann „2,5 Meter“, „250 cm“ oder eine gerundete Angabe nennen. Die Normalisierung muss Einheit und Präzision ausdrücklich speichern. Der Leitfaden zur mehrsprachigen Lead-Qualifizierung zeigt, wie sich Sprachwechsel und strukturierte Übergabe verbinden lassen.

Testen Sie Regeln, Sprache und Übergabe gemeinsam

Ein flüssiger Dialog ist kein ausreichender Test. Bauen Sie eine Matrix aus gültigen Kombinationen, verbotenen Paarungen, Grenzwerten, fehlenden Angaben, veralteten Preisen, nicht verfügbarem Bestand und Systemausfällen. Prüfen Sie zu jedem Fall die angezeigte Erklärung, den Tool-Aufruf, das Regelergebnis und die übergebenen Daten.

• Kann eine Nutzeranweisung Regeln oder Berechtigungen umgehen?
• Bleibt der Bot bei fehlendem Preis oder Bestand ehrlich?
• Werden ungültige Kombinationen nachvollziehbar erklärt?
• Erhält jede Sprache dieselben IDs und Regelresultate?
• Erzeugt ein Retry keinen zweiten Angebotsfall?
• Funktioniert die Übergabe auch bei unbekannten Anforderungen?

Testen Sie zusätzlich typische Formulareingaben, Tippfehler und Korrekturen. Der Beitrag über KI-Chatbots als Formularhilfe zeigt, wie Feldhilfe und serverseitige Validierung zusammenspielen.

Checkliste für den Produktionsbetrieb

1. Wählen Sie eine klar begrenzte Produktfamilie für den Pilot.
2. Definieren Sie stabile IDs und Verantwortliche für jedes Datenfeld.
3. Überführen Sie Kompatibilität und Grenzwerte in testbare Regeln.
4. Trennen Sie Erklärungen von Preis-, Bestands- und Angebotsabfragen.
5. Markieren Sie gültige, ungültige und prüfpflichtige Ergebnisse.
6. Versionieren Sie Regeln, Datenquellen und Übergabeformat.
7. Minimieren Sie personenbezogene und kundenspezifische Daten.
8. Prüfen Sie alle Sprachen mit denselben Referenzfällen.
9. Messen Sie gültige Abschlüsse, Korrekturen und Fachübergaben.

Starten Sie mit einer Produktfamilie, einem begrenzten Fragenpfad und einer klaren Übergabe. Wenn Regeln, Quellen und Zuständigkeiten sauber getrennt sind, kann ein KI-Chatbot komplexe Auswahl verständlich machen, ohne Verbindlichkeit vorzutäuschen. So wird der Konfigurator zum hilfreichen Einstieg in ein belastbares Angebot statt zu einer neuen Fehlerquelle.

Quellen und Standards

• Google Search Central: Structured data for product variants
• Google Search Central: Product structured data
• Google Merchant Center: Product data specification
• NIST AI 600-1: Generative Artificial Intelligence Profile