B2B-Produktkonfigurator im Shop: Wann technische Produkte, Varianten und Angebotslogik ein CPQ-nahes Setup brauchen

Ein B2B-Produktkonfigurator im Shop ist für viele Hersteller und technische Händler kein Komfort-Feature, sondern eine Reaktion auf ein sehr praktisches Problem: Produkte lassen sich nicht mehr sauber über ein paar Variantenfelder verkaufen. Material, Abmessungen, Anschlussarten, Zubehör, Kompatibilitäten, Staffelpreise oder Freigaben greifen ineinander. Gleichzeitig soll der Kunde schneller zu einer belastbaren Anfrage, einem Angebot oder direkt zur Bestellung kommen.

Genau deshalb ist die wichtigere Frage selten nur: Brauchen wir einen Konfigurator im Frontend? Die bessere Frage lautet: Welche fachliche Logik muss das System bei technischen Produkten wirklich prüfen, bevor ein Preis, eine Stückliste oder ein Angebot belastbar ist?

1. Woran man erkennt, dass ein normaler B2B-Shop nicht mehr reicht

Viele B2B-Shops starten sinnvoll mit Kategorien, Varianten und kundenspezifischen Preisen. Problematisch wird es, wenn technische Produkte im Alltag mehr Logik brauchen als das Frontend sauber tragen kann.

Typische Signale sind:

• Vertrieb und Innendienst bauen Angebote regelmäßig manuell aus Excel, PDF oder ERP-Daten zusammen
• Kunden müssen Maße, Leistungsklassen, Anschlussarten oder Zubehörkombinationen per Freitext erklären
• Varianten sind fachlich voneinander abhängig und nicht beliebig kombinierbar
• Preise ergeben sich erst aus Konfiguration, Menge, Kunde oder Projektkontext
• dieselbe Konfiguration muss später als Angebot, Auftrag oder Nachbestellung wieder auffindbar sein
• technische Rückfragen blockieren den Self-Service, obwohl die Regeln intern längst bekannt sind

Dann fehlt meist nicht nur ein besseres Design. Dann fehlt ein belastbares Konfigurations- und Angebotsmodell.

2. Was ein B2B-Produktkonfigurator praktisch leisten muss

Ein B2B-Produktkonfigurator ist mehr als ein paar Dropdowns. Er muss fachlich richtige Eingaben ermöglichen und fachlich falsche Eingaben verhindern.

1. Varianten strukturiert statt improvisiert abbilden

Adobe beschreibt konfigurierbare Produkte als ein Produkt mit auswählbaren Optionen, bei dem jede Variation als eigenes Produkt mit eigener SKU geführt werden kann. Das ist wichtig, weil technische Varianten nicht nur optisch anders sind, sondern oft eigene Verfügbarkeiten, Preise oder Beschaffungslogiken haben.

Akeneo beschreibt Varianten ähnlich: Ein Produktmodell bündelt gemeinsame Eigenschaften, während Variant-Produkte eigene Merkmale und Identifikatoren tragen. Genau dieses Denken hilft im B2B, wenn gemeinsame Stammdaten, optionale Module und konkrete Ausprägungen sauber getrennt werden müssen.

In der Praxis relevant sind zum Beispiel:

• Grundmodelle mit abweichenden Leistungsstufen
• technische Ausprägungen mit eigener SKU
• Zubehör, das nur mit bestimmten Basismodellen kombinierbar ist
• optionale Komponenten, die Preis und Lieferzeit verändern
• landes- oder kundenspezifische Unterschiede in Normen oder Ausstattung

Wenn diese Struktur unsauber ist, wird jede Konfiguration schnell zum Sonderfall. Dann lohnt sich oft zuerst unser Beitrag PIM im E-Commerce.

2. Konfigurationsregeln und Ausschlüsse sauber prüfen

Salesforce beschreibt Bundle-Produkte im CPQ-Kontext als ein Produkt mit optionalen Komponenten auf einer gemeinsamen Quote Line. Wichtig daran sind nicht nur die Optionen, sondern auch Features, Min-und-Max-Regeln und Constraints zwischen Optionen.

Genau diese Regelwelt ist bei technischen Produkten oft der Kern:

• Option A erfordert Komponente B
• Variante C schließt Zubehör D aus
• ab einer bestimmten Leistung ist ein anderes Gehäuse nötig
• bestimmte Konfigurationen brauchen andere Versand- oder Montagebedingungen
• Zubehör darf nur in festen Mengenrelationen gewählt werden

Sobald diese Regeln im Kopf einzelner Vertriebsmitarbeitender stecken, wird der Shop nicht skalierbar. Ein belastbarer Konfigurator macht dieses Wissen systemisch nutzbar.

3. Preis und Angebot aus derselben Logik ableiten

In vielen Industrieprojekten ist der Warenkorb gar nicht der eigentliche Zielpunkt. Der Kunde braucht erst eine belastbare Konfiguration und danach ein Angebot.

Adobe Commerce zeigt bei B2B-Quotes sehr klar, dass Mindestbeträge, Laufzeiten und Dateianhänge für Angebotsanfragen konfiguriert werden können. Shopware positioniert Quote Management ebenfalls als festen Baustein seiner B2B Components.

Das ist wichtig, weil Konfiguration und Angebotsprozess zusammengehören, wenn:

• Preise projektbezogen verhandelt werden
• technische Zeichnungen oder Anhänge zum Vorgang gehören
• bestimmte Konfigurationen erst intern geprüft oder freigegeben werden müssen
• aus einer Konfiguration direkt ein wiederverwendbares Angebot entstehen soll

Wenn bei Ihnen genau dieser Übergang zwischen Anfrage, Angebot, Freigabe und Bestellung heute hakt, passt dazu auch unser Beitrag B2B-Angebotsprozess digitalisieren. Wenn Angebote zusätzlich aus umfangreicheren Positionslisten, Leistungsverzeichnissen oder projektbezogenen Angebotswarenkörben entstehen, ergänzt auch unser neuer Beitrag B2B-Shop für Projektgeschäft diese Perspektive.

3. Wann ein CPQ-nahes Setup wirtschaftlich wird

Nicht jedes Unternehmen braucht sofort eine vollwertige CPQ-Landschaft. Aber es gibt sehr klare Fälle, in denen ein CPQ-nahes Setup im B2B-Shop wirtschaftlich sinnvoll wird.

Typische Muster sind:

1. Technische Hersteller mit erklärungsbedürftigen Produkten

Wenn Produkte aus mehreren Komponenten bestehen und die Auswahl fachlich geführt werden muss, spart eine strukturierte Konfiguration spürbar Zeit im Vertrieb.

2. Varianten mit echter Logik statt nur Farbe und Größe

Sobald Ausprägungen Einfluss auf Preis, Lieferzeit, Zubehör, Zulassung oder Montage haben, reicht ein einfacher Variantendialog oft nicht mehr.

3. Wiederkehrende Angebote mit ähnlicher Grundstruktur

Wenn Vertriebsteams ähnliche Konfigurationen immer wieder neu zusammensetzen, ist das ein starkes Signal für Standardisierungspotenzial.

4. Innen- und Außendienst arbeiten parallel an denselben Fällen

Dann wird wichtig, dass Konfigurationen, Angebotsstände und Nachbestellungen für alle denselben Datenstand haben. Dazu passt auch unser Beitrag B2B-Shop mit Außendienst und Innendienst.

4. Welche Systemgrenzen vor dem Projekt geklärt sein sollten

Ein häufiger Fehler ist, den Konfigurator als isoliertes Frontend-Projekt zu behandeln. In der Praxis hängen mehrere Systeme daran.

Der Shop oder das Portal sollte typischerweise verantworten

• Nutzerführung durch die Konfiguration
• Sichtbarkeit von Optionen, Abhängigkeiten und Ausschlüssen
• kundenspezifische Preis- und Sortimentsausspielung
• Übergang zu Anfrage, Angebot oder Bestellung
• Wiederaufnahme gespeicherter Konfigurationen

ERP, CPQ, PIM oder WAWI sollten typischerweise verantworten

• führende Produkt- und Stammdaten
• Preisstammdaten und Kalkulationslogik, wenn diese dort fachlich geführt werden
• technische Regelwerke und Abhängigkeiten, wenn sie tief ins Produktmodell eingreifen
• Stücklisten, Auftragsdaten und operative Abwicklung
• Bestände, Lieferlogik und Belegwesen

Gerade bei gewachsenen Systemlandschaften hilft es, die Verantwortung nicht im Shop zu überladen. Wenn Shop, CMS, CRM und ERP ohnehin stärker orchestriert werden müssen, ist auch unser Beitrag Composable Commerce im Mittelstand relevant.

5. Welche Plattformrichtung oft zu welchem Konfigurator-Szenario passt

Dieser Abschnitt ist bewusst keine Rangliste. Er soll typische Einsatzmuster einordnen.

Shopify

Shopify ist stark, wenn B2B-Prozesse bewusst schlank bleiben und die Konfiguration eher in klaren Standardmustern funktioniert. Für tiefere technische Konfigurationslogik, viele Abhängigkeiten und komplexe Angebotsprozesse muss man sehr nüchtern prüfen, was nativ tragfähig ist und was zusätzliche Architektur übernehmen soll.

Shopware

Shopware wird interessanter, wenn B2B-Komponenten wie Quote Management, Order Approvals, Organisation Units, Budgets und Individual Pricing mit dem Shop zusammenspielen sollen. Das ist für Mittelstandsprojekte relevant, bei denen Konfiguration, Firmenkonto und Angebotsprozess enger zusammenrücken.

Adobe Commerce oder Magento

Adobe Commerce passt oft besser, wenn Variantenmodell, B2B-Quote-Logik und wiederkehrende Beschaffung fachlich tiefer im System verankert werden müssen. Gerade in komplexeren Sortimenten mit vielen Ausprägungen ist diese Richtung oft belastbarer.

Wenn bei Ihnen gerade die Plattformfrage zwischen Standardisierung und tieferer B2B-Logik ansteht, lesen Sie dazu auch Shopify B2B oder Shopware für Firmenkunden.

6. Die häufigsten Risiken in Konfigurator-Projekten

Die größten Probleme liegen selten im eigentlichen UI. Sie liegen fast immer in unklarer Fachlogik.

Typische Risiken sind:

• Produktdaten sind nicht sauber genug strukturiert
• Varianten, Optionen und Zubehörbeziehungen sind historisch gewachsen, aber nirgends eindeutig modelliert
• Preislogik lebt in Excel statt im führenden System
• der Konfigurator erzeugt schöne Kombinationen, aber keine belastbaren Angebote
• Nachbestellungen finden dieselbe Konfiguration später nicht sauber wieder
• Vertrieb, Technik und IT verwenden unterschiedliche Wahrheiten

Wenn diese Punkte nicht gelöst sind, digitalisiert der Konfigurator nur die Oberfläche, nicht den Prozess.

7. Ein pragmatischer Fragenkatalog vor dem Start

Vor dem Start helfen meist diese sieben Fragen mehr als jede Demo:

1. Welche Produkte oder Produktgruppen brauchen überhaupt eine geführte Konfiguration?
2. Welche Regeln sind fachlich zwingend und welche nur nice to have?
3. Wo werden Varianten, Zubehör und Abhängigkeiten heute führend gepflegt?
4. Entsteht aus der Konfiguration direkt ein Preis, eine Anfrage oder ein Angebot?
5. Müssen Konfigurationen gespeichert, geteilt oder später nachbestellt werden?
6. Welche Rollen aus Vertrieb, Technik, Einkauf und Freigabe greifen auf denselben Vorgang zu?
7. Wo entstehen heute die meisten Rückfragen, Medienbrüche oder Fehlkonfigurationen?

Wenn ein Team diese Fragen nicht klar beantworten kann, ist das Projekt meist noch kein Tool-Thema, sondern zuerst ein Modellierungs- und Architekturthema.

Fazit

Ein B2B-Produktkonfigurator im Shop wird immer dann wertvoll, wenn technische Produkte nicht mehr sauber über statische Preislisten, PDFs oder einfache Variantenmasken verkauft werden können. Entscheidend ist dabei nicht die Oberfläche allein, sondern die fachliche Kette dahinter: Variantenstruktur, Regelwerk, Preislogik, Angebotsprozess und Wiederverwendbarkeit müssen zusammenpassen.

Gerade für Industrieunternehmen, technische Hersteller und Mittelständler liegt der Hebel oft nicht in mehr Frontend-Effekt, sondern in weniger Rückfragen, belastbareren Angeboten und einem realistisch skalierbaren Self-Service.

Wenn Sie gerade prüfen, wie ein B2B-Shop, Produktkonfigurator oder Angebotsprozess für technische Produkte sauber aufgebaut werden kann, ist meist zuerst unsere Seite Webseiten & Shops sinnvoll. Wenn bereits konkrete Anforderungen aus Vertrieb, Produktmanagement oder IT auf dem Tisch liegen, ist oft auch direkt unser Kontaktformular der schnellste nächste Schritt.

Quellen

• Adobe Commerce Docs: Configurable product
• Adobe Commerce Docs: Configure quotes
• Shopware Docs: B2B Components
• Salesforce Help: Product Bundles in Salesforce CPQ
• Akeneo Help Center: What about products with variants?