B2B und B2C sind zwei unterschiedliche Welten. Nicht nur im Marketing, sondern vor allem in der Technologie. Wenn du Shopware für B2C eingesetzt hast, wirst du merken: B2B verlangt nach einer anderen Architektur. Commercetools war dafür gemacht. Und die MACH-Philosophie, die dahintersteckt, ist für B2B-Komplexität genau das richtige Rezept.
Inhalt
- Warum B2B andere Anforderungen hat
- Commercetools B2B Features im Detail
- MACH-Architektur und warum sie für B2B sinnvoll ist
- Commercetools vs. Shopware B2B Suite
- Eine typische B2B-Architektur mit commercetools
- Kosten realistisch kalkulieren
- Wann macht commercetools für B2B wirklich Sinn?
Warum B2B andere Anforderungen hat
B2B ist nicht einfach B2C mit anderen Margen. Die Geschäftslogik ist eine ganz andere.
In B2C zahlst du den angezeigten Preis. Jeder Kunde bekommt dieselbe Rechnung. In B2B? Es gibt Kundengruppen mit unterschiedlichen Preisen. Der große Großhändler zahlt anders als der kleine Salon-Besitzer. Es gibt Preisbindungen pro Kunde, Volumenrabatte die dynamisch berechnet werden, Verträge mit Mindestmengen. Und dann kommen die Freigabeprozesse: Nicht jeder Mitarbeiter der Geschäftskunden soll unbegrenzt einkaufen dürfen. Große Bestellmengen oder teure Produkte müssen von einer anderen Person genehmigt werden.
Das ist nicht Marketing-Schnick-Schnack. Das ist echte Geschäftslogik die in der Software abgebildet werden muss.
Dann kommt die Integration. B2B arbeitet mit ERP-Systemen. SAP, Navision, Exact. Die Bestände, Preise und Kundendaten leben dort. Der Shop kann nicht auf Stand-alone-Basis existieren. Und die Bestellungen aus dem Shop müssen zurück ins ERP. In Echtzeit. Oder mindestens in einem definierten Rhythmus.
Und ein Punkt den viele übersehen: B2B braucht Selbstbedienung auf einem anderen Level. Der Geschäftskunde möchte seine Kundengruppenpreise sehen ohne anzurufen. Möchte historische Bestellungen abrufen. Möchte Bestellvorlagen speichern. Möchte vielleicht sogar Rechnungskopien herunterladen. Das ist selbstständige Information und Verwaltung, die B2C-Shops so nicht brauchen.
Commercetools B2B Features im Detail
Commercetools ist als API-first Commerce Plattform gebaut. Das heißt: Es hat kein fixiertes User Interface das bestimmt wie die Dinge aussehen. Stattdessen gibt es eine Menge von APIs über die du alles tun kannst. Das ist für B2B ein großer Vorteil, weil B2B-Prozesse oft so individuell sind dass kein vorgefertigtes Interface passt.
Die relevanten B2B-Features von commercetools:
Business Units. Du kannst hierarchische Organisationen abbilden. Ein großes Handelsunternehmen mit mehreren Niederlassungen, jede mit eigener Kostenstelle. Jede Unit kann eigene Bestellberechtigungen, eigene Budgets, eigene Kontakte haben. Das wird durch das System gewährleistet, nicht durch Excel und E-Mail.
Quotes. Der Kunde fragt nach einer großen Menge und will ein Angebot. Mit Quotes kannst du auf Basis einer Anfrage ein individuelles Angebot erstellen. Mit Gültigkeitsdauer. Der Kunde antwortet und konvertiert das Quote in eine Bestellung. Oder lehnt ab und du weißt die Quote war nicht am Preis.
Approval Workflows. Bestellgrenzen pro Rollen. Bestellungen über 5.000 EUR brauchen eine Freigabe vom Abteilungsleiter. Bestellungen über 25.000 EUR brauchen auch noch Freigabe von der Geschäftsführung. Workflows die je nach Kunde unterschiedlich sind. Das wird in commercetools nicht über eine fixierte Bedienoberfläche gemacht, sondern über APIs die du mit deinem Custom Frontend oder deiner App verbindest.
Custom Fields und Attributes. B2B Geschäftskunden haben oft Besonderheiten: Projekte-Codes zur Kostenzurechnung, Lieferplätze die vom Firmenhauptquartier abweichen, Versandanforderungen. Du kannst alle diese zusätzlichen Daten an Kunden, Bestellungen und Produkten anhängen ohne die Basis-Struktur zu brechen.
API-Access für Kundensysteme. Der Großkunde hat selbst Systeme. Ein Lager-Management-System, ein Beschaffungs-Portal im Intranet. Diese Systeme sollen direkt mit deinem Shop-Inventory sprechen um Live-Verfügbarkeit zu checken. Mit commercetools APIs ist das kein Problem.
Das wichtigste aber: Alle diese Features sind nicht vorkonfiguriert wie in Shopware B2B. Sie sind Bausteine. Du musst die auf deinen Prozess zuschneiden. Das ist mehr Arbeit, gibt dir aber mehr Kontrolle.
MACH-Architektur und warum sie für B2B sinnvoll ist
MACH steht für Microservices, API-first, Cloud-native und Headless. Mehr zu dieser Architektur-Philosophie in unserem Artikel zur MACH-Architektur.
Bei B2B brauchst du das wirklich:
Microservices. B2B-Prozesse sind oft nicht simpel. Dein Shop ist nicht nur Shop, sondern auch Schnittstelle zu ERP, zu Zahlungssystemen, zu Kundensystemen. Mit einer monolithischen Architektur (wo alles an einer Stelle fest verdrahtet ist) bedeutet jede kleine Änderung ein großes Deployment-Risiko. Mit Microservices hast du kleinere, unabhängige Services die du einzeln updaten kannst. Deine Quote-Engine läuft getrennt vom Inventory-Service. Eine Änderung in der Quote-Engine bricht nicht die Bestandsverwaltung.
API-first. B2B braucht oft mehrere Kanäle: Den Web-Shop für Kunden ohne Kundensystem. Ein API-Interface für große Kunden die direkt mit ihren Systemen anbinden. Ein Mobile-Portal für Sales-Reps vor Ort. Mit API-first brauchst du nicht drei verschiedene Commerce-Lösungen. Eine Backend-API, drei Frontends. Das senkt langfristig die Betriebskosten.
Cloud-native. B2B Prozesse können Spitzen haben. Das große Quartal-Ende wenn alle Großkunden zugleich bestellen. Mit Cloud-native Infrastruktur skalierst du automatisch hoch. Mit On-Premise Systemen brauchst du Hardware für den Peak und zahlst den Rest des Jahres für Kapazität die leer steht.
Headless. Der Shop ist nicht an ein Template gebunden. Das ist für B2B wichtig weil Geschäftskunden oft sehr unterschiedliche Anforderungen an die Bedienung haben. Ein Großhandels-Portal sieht anders aus als ein B2B-Portal für Designer. Mit headless baust du dein Frontend nach den echten Anforderungen, nicht nach den Zwängen eines Theme-Systems.
Das Resultat: deine B2B-Lösung ist flexibel, wartbar und skaliert mit deinen Anforderungen. Nicht gegen sie.
Commercetools vs. Shopware B2B Suite
Das ist die Frage die immer kommt: "Warum nicht einfach Shopware B2B Suite nehmen?"
Der Vergleich ist komplexer als "eine ist besser" weil beide Ansätze unterschiedliche Philosophien verfolgen.
Shopware B2B Suite: Das ist ein vollständiges, vorkonfiguriertes B2B-Modul mit sofort nutzbaren Funktionen von Haus aus. Business Units, Quotes, Approval Flows, Bulk-Orders, Bestellvorlagen. Du setz es auf, passt es an deine Prozesse an, fertig. Die Bedienoberfläche ist bereits da. Das ist schneller wenn deine Prozesse in die Struktur passen.
Das Problem: Wenn deine Prozesse nicht in die Standard-Struktur passen, wird es kompliziert. Shopware B2B ist ein monolithisches System. Es tut vieles von Haus aus, aber wenn du 30% Custom-Logik brauchst, musst du überlegen: Sollte ich deine Architektur ändern (Headless/Microservices) oder wechsel ich zu Commercetools? Das ist eine Architektur-Entscheidung, keine automatische Plattform-Entscheidung.
Commercetools: Keine vorgeformte B2B Suite. Sondern primitive Bausteine über APIs. Business Units sind möglich, aber du musst sie mit deinem Frontend-Code realisieren. Quotes auch. Approval Workflows auch. Das heißt du schreibst mehr Code. Aber du machst dich nicht abhängig von einer monolithischen Struktur.
Das Spektrum von B2B:
| Anforderung | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Beschreibung | Mehrere Kunden mit Gruppen-Preisen | Unterschiedliche Preise pro Kundengruppe, einfache Freigaben | Individuelle Kundenpreise, komplexe Workflows, ERP-Integration |
| Shopware B2B Suite | Überdimensioniert, unnötig teuer | Gut geeignet, macht Sinn | Möglich, aber wird starr bei Custom Logik |
| Commercetools | Overkill, überengineert | Möglich, aber mehr Entwicklung als Shopware | Stark, weil flexibel und erweiterbar |
| Best Choice | Shopify oder Standard-Shopware | Shopware B2B Suite | Commercetools oder Shopware mit Custom Headless |
Wichtig zu verstehen: Commercetools ist kein "Shopware mit noch mehr Features". Es ist ein anderer Ansatz. Statt "hier ist alles konfiguriert, nutze es" heißt es "hier sind APIs, bau was du brauchst". Das ist mehr Arbeit, gibt dir aber mehr Langlebigkeit. Besonders bei komplexem, sich änderndem B2B-Business.
Wir sehen in B2B-Beratungsgesprächen regelmäßig, dass Unternehmen zu früh zu commercetools greifen. Wer noch nicht mit Shopware B2B Suite an seine Grenzen gestoßen ist, sollte das erst tun, bevor er den Architektur-Sprung in Richtung API-first macht. Der Wechsel ist teuer und die Vorteile zahlen sich nur aus wenn die Komplexität es wirklich verlangt.
Eine typische B2B-Architektur mit commercetools
Wie sieht das praktisch aus?
Du hast commercetools als Backend. Die Business Logic der Preise, Verfügbarkeiten, Benutzerberechtigungen leben hier. Aber nicht in einer GUI, sondern als Daten und APIs.
Oben drauf baust du ein Frontend. Meistens Nuxt oder Next.js. Das Frontend zeigt die Daten die commercetools über APIs liefert. Hier definierst du wie der Geschäftskunde die Bestellformulare sieht, wie Preise angezeigt werden, wie Freigabeprozesse funktionieren.
Parallel läuft eine Integration zum ERP. Das ist oft ein Custom-Service, manchmal ein iPaaS-Tool wie Zapier oder Boomi. Wenn eine Bestellung in commercetools erstellt wird, wird sie automatisch ins ERP übertragen. Wenn Lagerbestände im ERP sich ändern, werden sie aus dem ERP zu commercetools synchronisiert.
Zusätzlich: Vielleicht ein API für große Kunden die direkt anbinden. Diese Kunden feuern Bestellungen über ihre Systeme direkt gegen deine APIs ab. Keine Web-UI nötig.
Das ergibt eine Architektur die:
- Nicht überdimensioniert ist wenn du kleine Anforderungen hast
- Aber mühelos skaliert wenn deine Anforderungen komplexer werden
- Einfach zu debuggen ist weil die Komponenten lose gekoppelt sind
- Einfach zu warten ist weil du nicht gegen einen Monolithen entwickelst
Das kostet initial mehr als "Shopware Theme anpassen", aber beim dritten oder vierten Custom-Feature merkst du dass du schneller vorankommst. Aus unserer Beratungserfahrung: Unternehmen die commercetools wählen, haben in der Regel ein klar definiertes, komplexes B2B-Szenario und ein Team das die API-Entwicklung stemmen kann oder stemmen will.
Kosten realistisch kalkulieren
Lass mich ehrlich sein: Commercetools ist teuer. Nicht weil Commercetools böse wäre, sondern weil die Art von B2B-Implementation die du brauchst komplex ist. Hier findest du mehr über commercetools oder B2B E-Commerce. Einen direkten Vergleich mit Shopware B2B Suite findest du in unserem Überblick.
Lizenzkosten. Commercetools berechnet nach Nutzungsvolumen. Das klingt modular, kann aber schnell in den fünf- bis sechsstelligen EUR-Bereich pro Jahr gehen wenn du echte Auslastung hast. Frag direkt bei commercetools nach den aktuellen Konditionen.
Entwicklung. Das ist der größere Posten. Eine B2B-Implementation mit commercetools brauchst du:
- Backend-Integration zum ERP (Custom oder iPaaS)
- Frontend-Development (Nuxt/Next.js)
- API-Integration für große Kunden wenn relevant
- Approval Workflows und Reporting
Das ist nicht "Theme konfigurieren", das ist echte Custom-Entwicklung. Budget: 60.000+ EUR je nachdem wie komplex.
Laufend. Hosting für das Frontend, Updates, kleine Anpassungen. Hier sind die Kosten näher am B2C-Level, aber nicht identisch.
Die echte Frage: Rentiert sich das?
Nur wenn zwei Bedingungen erfüllt sind:
- Dein B2B-Business ist komplex genug dass du Custom-Logik brauchst. Wenn du Level 1 B2B machst (einfach mehrere Kundengruppen mit unterschiedlichen Preisen), ist Shopware B2B günstiger.
- Die Umsatzhöhe rechtfertigt die Investition. Mit 2 Millionen EUR Jahresumsatz über 100+ Großkunden? Ja. Mit 500.000 EUR Umsatz über 20 Kunden? Wahrscheinlich nicht.
Dort wo commercetools wirtschaftlich sinnvoll ist, spart man langfristig durch schnellere Anpassungen und niedrigere Betriebsrisiken.
Wann macht commercetools für B2B wirklich Sinn?
Wenn mehrere dieser Punkte zutreffen:
- Komplexe Preislogik. Nicht einfach "Kundengruppe A zahlt 10% weniger", sondern individuelle Preise mit Volumenrabatten, Mindestbestellmengen, Gültigkeitsbindungen nach Zeiträumen. Das verlangt nach Custom-Logic die über APIs realisierbar ist.
- Einbindung mehrerer Systeme. ERP, PIM, CRM, Kundensystem des Käufers. Commercetools als "Switching Center" mit API-Zugängen zu allen macht das sauberer als monolithische Lösungen.
- Sehr unterschiedliche Kundenprozesse. Der eine Großkunde braucht Freigaben, der andere nicht. Ein Kunde bestellt über Portal, ein anderer über API. Mit commercetools baut du einmal die Infrastruktur und variierst das Frontend je nach Kunde.
- Wachstum und Unabhängigkeit. Du willst nicht in fünf Jahren feststellen dass du wegen Shopware-Grenzen umdenkst. Commercetools lässt dich umskalieren ohne Architektur-Bruch.
Wenn das nicht zutrifft, Shopware B2B Suite oder sogar Shopify mit Custom Apps sind oft die schnellere, günstigere Lösung.