Die meisten Fachhändler haben einen Online-Shop. Aber viele davon wurden als B2C-Katalog gestartet und kommen jetzt an Grenzen: bei Preislogik, bei Großkunden, bei den Kosten. Dieses Whitepaper zeigt, wo die Brüche liegen — und wie ein B2B-Setup aussehen kann, das zum technischen Fachhandel passt.
Die meisten technischen Fachhändler haben einen Shop. Das Problem ist nicht, dass er fehlt — sondern dass er nicht für B2B gebaut wurde.
Wer Werkzeuge, Drucklufttechnik, Befestigungstechnik oder Industriebedarf verkauft, hat in der Regel irgendwann einen Online-Shop aufgesetzt. Oft auf einer Plattform, die aus dem B2C-Bereich kommt. Für einfache Bestellungen und einen öffentlichen Produktkatalog reicht das.
Aber dann kommen die Anforderungen, die den Fachhandel vom Consumer-Geschäft unterscheiden: Hunderte individuelle Preislisten. Großkunden, die Budgetfreigaben und Rollenkonzepte erwarten. Drei verschiedene Vertriebskanäle, die aus einem Produktstamm bedient werden sollen. Und eine Shoplizenz, deren Kosten mit jedem Euro Online-Umsatz steigen.
Das ist kein hypothetisches Problem. Es zeigt sich konkret: Der Außendienst pflegt Preise parallel im ERP und im Shop. Großkunden bestellen weiter per Telefon, weil der Shop keine Freigabeprozesse kann. Und mit jedem Prozent mehr Online-Umsatz steigt die Plattformlizenz — bei gleichbleibender Marge.
Je länger die Workarounds laufen, desto teurer wird der Wechsel. Nicht weil die Technik komplexer wird, sondern weil sich Prozesse, Schnittstellen und Gewohnheiten um die Schwächen des bestehenden Systems herum verfestigen.
An diesem Punkt stellt sich die Frage: Weiter mit Workarounds — oder auf ein System umsteigen, das für diese Anforderungen gebaut wurde?
Diese Punkte entscheiden darüber, ob ein Shopsystem im technischen Fachhandel funktioniert oder nur funktioniert.
Im Fachhandel sind Preise nicht einfach. Staffelpreise, Rahmenverträge, projektbezogene Sonderkonditionen, Tagespreise vom Hersteller — das sind nicht fünf Kundengruppen, sondern hunderte individuelle Preislisten, die in Echtzeit aus dem ERP kommen müssen. Jeder Workaround an dieser Stelle kostet langfristig mehr als die saubere Lösung.
Großhandel mit Nettopreisen, Fachhandels-Shop für Handwerksbetriebe, offener B2C-Shop für Endkunden. Drei verschiedene Welten mit unterschiedlichen Sortimenten, Layouts und Konditionen — aber einem gemeinsamen Produktstamm. Wer das über separate Installationen löst, pflegt dreifach und hat irgendwann inkonsistente Daten.
Wenn ein Kunde um 14 Uhr bestellt, muss der Preis von 14 Uhr gelten — nicht der vom letzten Nacht-Import. Bestände, Lieferzeiten, Kundendaten: alles muss live aus SAP, Microsoft Dynamics oder dem jeweiligen ERP kommen. Über eine API, nicht über CSV-Dateien.
Ein Industriekunde mit 8 Standorten bestellt anders als ein Handwerksbetrieb. Der Techniker vor Ort braucht Zugriff auf das Sortiment, der Einkauf muss freigeben, Controlling will Budgets sehen. Wenn der Shop das nicht abbildet, bestellen die Großkunden weiterhin per Telefon.
Bei einem durchschnittlichen B2B-Warenkorb von 2.000 EUR und einer GMV-basierten Lizenz zahlt ein Fachhändler mit 5 Mio. EUR Online-Umsatz schnell fünfstellige Plattformgebühren pro Jahr — zusätzlich zu Hosting, Agentur und Betrieb. Bei festem Lizenzmodell ist dieser Posten kalkulierbar.
Keine Einzelreferenz, sondern ein typisches Projektmuster. So arbeiten mittelständische Fachhändler mit OXID.
Großhandel, Fachhandels-B2B und B2C laufen als separate Frontends auf einer OXID-Installation. Unterschiedliche Sortimente, Preise und Designs — ein gemeinsamer Produktstamm, eine Verwaltung.
Über die GraphQL-API werden Preise, Verfügbarkeiten und Kundendaten in Echtzeit aus SAP oder Microsoft Dynamics gezogen. Keine CSV-Importe, keine Nacht-Jobs, keine Abweichungen.
Rollen, Budgets, Bestelllimits und Freigabe-Workflows für Industriekunden mit komplexen Einkaufsorganisationen. Der Kunde verwaltet seine Nutzer selbst.
Symfony-basiert, eigene GraphQL-Schnittstelle (OXAPI), Headless-fähig. Und: keine Umsatzbeteiligung. Die Lizenzkosten bleiben gleich — auch wenn der Online-Umsatz wächst.
Nicht jede Plattform ist für jedes Problem gebaut. Die Unterschiede zeigen sich im Detail.
| Anforderung | B2C-Plattform mit B2B-Erweiterung | SaaS / Marktplatz | OXID B2B-Setup |
|---|---|---|---|
| Hunderte individuelle Preislisten | ◐ Über Plugins, oft Performance-Probleme bei Skalierung | ✗ Nicht vorgesehen | ✓ Nativ, performant auch bei großer Zahl |
| Multishop (B2B + B2C + Großhandel) | ◐ Separate Installationen | ✗ Ein Shop pro Account | ✓ Nativ aus einer Installation |
| Echtzeit-ERP via API | ◐ Über Middleware, aufwändig | ✗ Kaum möglich | ✓ GraphQL-API, erprobte SAP-Anbindung |
| Rollen & Freigabe-Workflows | ◐ Basis-Funktionen | ✗ Nicht vorgesehen | ✓ Budgets, Limits, Genehmigungen |
| Lizenzkosten unabhängig vom Umsatz | ✗ GMV-basierte Lizenz | ✗ Umsatzprovision | ✓ Feste Lizenz |
Generalisierte Einordnung. Entscheidend ist nicht das Tool-Label, sondern ob Fachprozesse, Systemgrenzen und Betriebsverantwortung sauber beschrieben sind.
Diese Fragen helfen bei der Einschätzung, ob ein Shop-Projekt für Ihr Unternehmen sinnvoll ist — und wie komplex es wird.
In einem kompakten Gespräch klären wir, wo Ihr Fachhandel heute steht und wie ein OXID-Setup für Ihr Unternehmen aussehen könnte.
Gespräch vereinbaren →