B2x Commerce: Was das für die Frontend-Architektur bedeutet

B2B und B2C sind kein getrennter Build mehr. Immer mehr Marken verkaufen aus demselben Katalog, unter derselben Domain und zunehmend im selben Storefront an Geschäftskund:innen und Endverbraucher:innen. Für diese Konvergenz gibt es einen Namen, B2x Commerce, und sie setzt einen Teil des Stacks unter Druck, den die meisten Replatforming-Projekte als Nebensache behandeln: das Frontend. Account-spezifische Preise, Rollen und Freigaben, gemischte Kataloge und Self-Service sind keine Backend-Funktionen, die du einfach einschaltest. Es sind Erfahrungen, die an der Oberfläche komponiert werden müssen, pro Nutzer:in, pro Session.

Was ist B2x Commerce?

B2x Commerce ist das Betriebsmodell, in dem ein einziger Storefront sowohl Geschäftskund:innen als auch Endverbraucher:innen bedient, ohne sich in zwei getrennte Anwendungen aufzuteilen. Das "x" steht für das, was die besuchende Person tatsächlich ist: anonyme:r Shopper:in, eingeloggte:r Verbraucher:in, Einkäufer:in mit ausgehandeltem Vertrag oder Reseller mit account-spezifischen Preisen. Statt einen B2C-Shop und ein B2B-Portal nebeneinander zu betreiben, löst ein B2x-Setup den Käufer-Kontext zur Laufzeit auf und rendert den passenden Katalog, die passenden Preise und Aktionen für diesen Kontext.

Warum das gerade jetzt zählt: Die Grenze zwischen beiden Zielgruppen verschwimmt. B2B-Käufer:innen erwarten denselben Self-Service und dasselbe Tempo, das sie als Privatpersonen kennen, und Consumer-Marken öffnen zunehmend Wholesale-, Pro- oder Mitglieds-Stufen. Zwei Codebasen für weitgehend denselben Katalog zu pflegen ist teuer, und es sorgt zuverlässig dafür, dass die beiden Erfahrungen auseinanderdriften.

Warum B2x-Logik ins Frontend gehört, nicht in den Backend-Monolith

Es gibt die verlockende Annahme, B2x sei ein Backend-Problem: B2B-Modul dazu, Account-Preise an, fertig. In der Praxis wird das meiste, was eine B2x-Erfahrung ausmacht, an der Oberfläche entschieden.

Schau dir an, was sich zwischen Verbraucher:in und Geschäftskund:in auf genau derselben Produktseite ändert:

• Preis: Listenpreis gegenüber einem Vertragspreis, der am Account hängt.
• Verfügbarkeit und Einheiten: Einzelstücke gegenüber Gebindemengen oder Mindestbestellwerten.
• Aktionen: "In den Warenkorb" gegenüber "Angebot anfragen", "Auf die Bestellliste" oder "Zur Freigabe einreichen".
• Katalog-Sichtbarkeit: manche SKUs sind nur für Verbraucher:innen, manche nur für freigegebene Accounts.
• Navigation und Content: eine Geschäftskund:in sieht Nachbestellung, Budgets und Kostenstellen, wo eine Verbraucher:in Wunschlisten und Empfehlungen sieht.

Nichts davon ist ein einzelner Backend-Wert. Diese Dinge werden aus mehreren Quellen gleichzeitig komponiert: dem Commerce-Backend für den Basiskatalog, einem Pricing- oder Vertrags-Service für account-spezifische Preise, einem Identity-Provider für Rollen und einer Content-Schicht für die Ansprache. Das Frontend ist die einzige Schicht, die all das für eine:n bestimmte:n Nutzer:in in einer bestimmten Session zusammen sieht. Deshalb muss B2x-Logik dort komponiert werden. Ein Backend-Monolith kann die Daten speichern, aber er kann die Erfahrung nicht zusammensetzen, ohne selbst zu einem zweiten Frontend zu werden.

Rollen und Freigaben sind eine Session-Angelegenheit

Freigabe-Workflows sind das klarste Beispiel. Ob ein:e Nutzer:in auschecken darf oder einen Warenkorb nur zur Freigabe durch eine:n Vorgesetzte:n einreichen kann, hängt an der Rolle der Session, am Warenkorbwert und an den Regeln des Accounts. Diese Entscheidung verändert die UI in Echtzeit: Buttons, Hinweise und verfügbare Schritte. Steckt sie tief im Backend, wartet jede Änderung an einer Freigaberegel auf ein Backend-Release. Im Frontend gegen eine Rollen-API komponiert, geht dieselbe Änderung als Frontend-Deployment live.

Wie ein Composable Frontend B2x ohne Backend-Replatforming löst

Der Composable-Move für B2x ist derselbe wie bei Suche, Payments und Subscriptions: Lass die spezialisierten Systeme, wo sie sind, und komponiere die Erfahrung in einer entkoppelten Frontend-Schicht. Konkret:

• Eine einheitliche Datenschicht (in der Regel GraphQL) liegt vor dem Commerce-Backend, dem Pricing- oder Vertrags-Service und dem Identity-Provider, sodass das Frontend einen Endpunkt abfragt und Katalog, Account-Preis und Rolle in einer aufgelösten Antwort erhält.
• Der Käufer-Kontext (anonym, Verbraucher:in, Geschäftsaccount, Rolle) wird pro Session aufgelöst und steuert, welche Komponenten rendern. Ein Composable, Headless Frontend behandelt diesen Kontext als erstklassigen Input, nicht als Sonderfall, der an ein B2C-Theme geklebt wird.
• Katalog, Pricing und Rollen bleiben in ihren eigenen Systemen. Du migrierst nicht das Backend, um B2x-Verhalten zu bekommen; du komponierst auf dem Backend, das du ohnehin betreibst.
• Dieselbe Komponenten-Bibliothek rendert beide Zielgruppen. Eine Produktkarte, ein Preis-Block oder eine Warenkorb-Aktion wird einmal kontext-bewusst, und jede Seite, die sie nutzt, erbt das B2x-Verhalten.

Weil die Logik in einer entkoppelten Schicht liegt, kann ein Team einen "Angebot anfragen"-Flow oder eine Bestellliste zum bestehenden Consumer-Storefront hinzufügen, ohne das Backend anzufassen und ohne eine separate B2B-Anwendung aufzusetzen. Der Composable Storefront ist ein Build, der sich pro Käufer-Kontext anders verhält, nicht zwei zusammengenähte Builds.

Gemischte Kataloge und Self-Service in einem Build

Zwei der härtesten B2x-Anforderungen, gemischte Kataloge und Self-Service, zeigen, warum das Frontend der richtige Ort zum Komponieren ist.

Gemischte Kataloge heißt, derselbe Storefront zeigt unterschiedlichen Käufer:innen unterschiedliche Produktmengen: Consumer-SKUs, reine Business-SKUs und account-beschränkte SKUs. Das rein im Backend zu filtern, führt zu brüchigen, zielgruppen-spezifischen API-Varianten. Im Frontend gegen den Käufer-Kontext aufgelöst, wird die Katalog-Sichtbarkeit zu einem Query-Parameter, und ein Satz Listing- und Detail-Komponenten deckt jeden Fall ab.

Self-Service, also Account-Verwaltung, Bestellhistorie, Nachbestellung, Budgets und Nutzer-Administration, ist der Bereich, in dem B2B-Kund:innen die meiste Zeit verbringen, und in dem die Erfahrung am häufigsten bricht, wenn sie auf eine Backend-Admin-Maske umgeleitet wird. Im Frontend komponiert, nutzt der Account-Bereich dieselben Komponenten wie der Storefront, sodass die Geschäftskund:in deine Marke nie verlässt, um den Account zu verwalten. Das gilt auch für Details wie Nachbestell-Listen, freigegebene Warenkörbe und die Anzeige von Kostenstellen: Sie entstehen aus denselben Bausteinen, mit denen dein Team ohnehin arbeitet, statt aus einer separaten, fremd wirkenden Oberfläche.

Backend-natives B2B-Modul vs. Composable B2x-Frontend

• Dimension | Backend-natives B2B-Modul | Composable B2x-Frontend
• Käufer-Kontext | Fix pro Store oder Site | Pro Session und Rolle aufgelöst
• Account-spezifische Preise | Backend-Wert, kaum Darstellungskontrolle | An der Oberfläche komponiert, voll gestaltet
• Rollen und Freigaben | Backend-Release-Zyklus | Frontend-Deployment gegen eine Rollen-API
• Gemischte Kataloge | Separate API-Varianten pro Zielgruppe | Eine Query, kontextgesteuerte Sichtbarkeit
• Self-Service-Bereich | Oft eine Backend-Admin-Maske | Dieselbe Komponenten-Bibliothek wie der Storefront
• B2C zu einem B2B-Build ergänzen (oder umgekehrt) | Zweite Anwendung | Ein Build, neuer Kontext

FAQ

Ist B2x Commerce einfach B2B und B2C auf derselben Domain? Nein. Dieselbe Domain ist der einfache Teil. B2x heißt, ein Storefront löst den Käufer-Kontext zur Laufzeit auf und rendert den richtigen Katalog, die richtigen Preise und Aktionen für diese:n Nutzer:in, statt sie in eine separate B2B- oder B2C-Anwendung zu leiten.

Müssen wir das Backend replatformen, um B2x zu unterstützen? Nein. Der Sinn, B2x im Frontend zu komponieren, ist, dass Katalog, Pricing und Identity in ihren bestehenden Systemen bleiben. Eine einheitliche Datenschicht verbindet sie, und das Frontend setzt die Erfahrung auf dem Backend zusammen, das du ohnehin betreibst.

Woher kommen account-spezifische Preise? In der Regel aus einem Pricing- oder Vertrags-Service getrennt vom Basiskatalog. Das Frontend fragt den aufgelösten Preis für den aktuellen Account über die einheitliche Datenschicht ab und rendert ihn in derselben Preis-Komponente, die Verbraucher:innen sehen, nur mit anderen Werten.

Wie werden Freigabe-Workflows gehandhabt? Die Rolle der Nutzer:in und die Regeln des Accounts werden pro Session aufgelöst. Das Frontend liest sie aus einer Rollen-API und passt die verfügbaren Aktionen in Echtzeit an, Checkout gegenüber Zur-Freigabe-einreichen. Regeländerungen gehen als Frontend-Deployment live, nicht als Backend-Release.

Können wir mit B2C starten und B2B später ergänzen? Ja, und das ist der Hauptvorteil. Weil der Käufer-Kontext ein erstklassiger Input fürs Frontend ist, heißt eine Business-Stufe zu ergänzen, einen Kontext und seine Komponenten hinzuzufügen, nicht einen zweiten Storefront zu bauen.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend: die entkoppelte Schicht, in der Käufer-Kontext, Pricing und Rollen zu einer Erfahrung komponiert werden.
• Composable Storefront: ein Build, der Geschäfts- und Verbraucher:innen rendert, ohne sich in zwei Anwendungen aufzuteilen.
• Frontend as a Service: wie die Frontend-Schicht unabhängig vom Commerce-Backend betrieben und deployt wird.
• Agentic Frontend Management Platform: wie sich Routine-Änderungen an Kontext-Regeln und Komponenten mit KI-Agenten erledigen lassen.

Nächster Schritt

Willst du sehen, wie deine B2x-Logik, Account-Preise, Rollen, gemischte Kataloge und Self-Service, in einem entkoppelten Frontend komponiert aussieht? Sprich mit dem Laioutr-Team und wir bilden sie auf dem Backend ab, das du ohnehin betreibst.