Digital verkaufen

Einen B2B-Shop starten

Der komplette erste Aufbau: Katalog, Preise, Kunden, Checkout, Go-live.

Das ist das Projekt, in dem alles auf einmal kommt, und die Reihenfolge entscheidet, ob Sie es einmal machen oder zweimal. Datenmodell vor Daten, Preise vor Kunden, Storefront zuletzt. Ein B2B-Shop verkauft an Unternehmen statt an Personen, und fast jeder Unterschied zum Endkundenshop folgt aus diesem einen Satz.

Warum das schwerer ist, als es klingt

Der teuerste Irrtum in diesem Bereich: Ein B2B-Shop sei ein B2C-Shop mit Kundengruppen. Eine Weile sieht das richtig aus. Es hört auf, richtig zu sein, wenn sich der erste Großkunde anmeldet und seine verhandelten Konditionen nicht sieht, wenn der erste Einkauf fragt, wer einen Warenkorb über 12.000 € freigeben darf, oder wenn der erste Konzernkunde nach Punchout fragt. Ab da bauen Sie um das System herum statt darin, und jede Ergänzung macht die nächste schwerer.

Das Zweite, das Sie früh akzeptieren sollten: Den Zeitplan bestimmt Ihr ERP, nicht der Shop. Preise, Bestand, Kreditlimits und Auftragsbestätigung liegen dort. Wie schnell Sie starten können, hängt davon ab, welche Schnittstellen es gibt, wie sauber der Artikelstamm ist und wie die Kundenkonditionen strukturiert sind. Nichts davon kontrolliert das Shop-Projekt. Wer das im dritten Monat merkt, verliert die Zeit doppelt, weil die Storefront inzwischen auf Annahmen gebaut wurde, die nicht stimmen.

Drittens: Der sichtbare Teil ist der kleine Teil. Zum Design hat jeder eine Meinung, also zieht das Design alle Aufmerksamkeit auf sich, während Attribute, Konditionslogik und Organisationsmodell keine bekommen. Diese drei entscheiden, ob das Ganze funktioniert. Widerstehen Sie. Die Storefront ist das Letzte, was Sie bauen, und sie zuerst zu bauen ist der häufigste Grund, warum ein Projekt Arbeit wiederholen muss.

Am Umfang ertrinken diese Projekte. Die Wunschliste am ersten Tag enthält meist einen Konfigurator, Punchout, ein Kundenportal, drei Sprachen und eine App. Starten Sie schmal: ein Land, eine Währung, eine Storefront, ein definiertes Sortiment, eine definierte Gruppe von Pilotkunden. Alles auf der Liste bleibt möglich, und es wird günstiger, sobald echte Bestellungen existieren.

Go-live ist kein Datum, sondern eine Rampe. Ein B2B-Shop ohne Kunden ist in keinem sinnvollen Sinn live, und ein B2B-Shop, von dem alle Kunden am selben Montag erfahren haben, zeigt jeden Fehler allen gleichzeitig.

Die Hebel

Ein Datenmodell, das den Kontakt mit der Wirklichkeit übersteht

Alles Weitere hängt davon ab, und es ist das, was sich später teuer ändert, weil an den Produkten dann Bestellhistorie hängt.

So sieht es gut aus: Die Attribute, nach denen Einkäufer filtern, existieren als strukturierte, typisierte Werte mit Einheiten. Familien fassen zusammen, was sich gleich verhält. Varianten halten die Artikelzahl überschaubar. Kategorien folgen der Logik des Einkäufers, nicht der Ihres ERP.

Wovon es abhängt: Das Modell wird entschieden, bevor Daten geladen werden. Erst laden und dann modellieren heißt, Produkte zu migrieren, auf die bereits Bestellungen verweisen.

Wie Produktinformationsmanagement funktioniert
Datenmodell planen
Attribute und Attributgruppen
Familien
Varianten und Familienvarianten
Ein Produkt anlegen, einmal von Hand, um das Modell zu prüfen
Importdatei vorbereiten und Produkte in Masse importieren

Preise, die die Preise des Einkäufers sind

Das macht aus einem Katalog mit Warenkorb einen B2B-Shop.

So sieht es gut aus: Ein angemeldeter Einkäufer sieht seinen verhandelten Nettopreis mit seinen Staffeln. Ein anonymer Besucher sieht einen vertretbaren Listenpreis oder gar keinen, nach Ihrer Entscheidung. Die Frage „Warum sieht dieser Kunde diesen Preis?" beantworten Sie in unter einer Minute.

Wovon es abhängt: Wo Konditionen gepflegt werden und wie sie in den Shop kommen. Klären Sie das in der ersten Woche. Es ist der Punkt, der Ihren Starttermin am ehesten verschiebt.

Kunden als Organisationen modelliert

So sieht es gut aus: Der Kunde ist eine Organisation mit Adressen, Konditionen und Zahlungsbedingungen. Die Menschen sind Kontakte mit Rollen. Ein Einkauf mit vier Einkäufern hat vier Zugänge und kein gemeinsames Passwort.

Wovon es abhängt: Sie kennen die internen Strukturen Ihrer Kunden gut genug, um sie abzubilden. Der Innendienst kennt sie; das Projektteam meist nicht. Fragen Sie ihn.

Ein Checkout und eine Storefront für die Art, wie B2B bestellt

So sieht es gut aus: Der Einkäufer trägt seine eigene Bestellnummer und seine Kostenstelle auf der Position ein, wählt einen Liefertermin und kann die Lieferung teilen. Rechnung ist eine Zahlungsart. Die Bestätigung kommt sofort, und die Bestellung erreicht das ERP, ohne dass jemand sie abtippt.

Wo die Grenze heute liegt: Die Kostenstelle ist Freitext auf der Bestellposition. Sie reist mit der Bestellung, ist aber kein Stammdatum, und es gibt kein Budget, das sie belastet. Jeder Kontakt hat eine Freigabegrenze; eine Bestellung darüber wird als pending angehalten statt freigegeben. Es gibt keine Freigabe-Warteschlange, kein Routing und keine Benachrichtigung. Die Freigabe ist ein manueller Schritt Ihres Teams. Planen Sie Checkout und Kommunikation zum Start darum herum, nicht um einen Workflow, den es noch nicht gibt.

Wovon es abhängt: Der Bestellweg und seine Nummerierung sind mit denen abgestimmt, die das ERP betreiben, vor dem Start und nicht währenddessen.

Eine sinnvolle Reihenfolge

Phase 1: die unsichtbare Hälfte. Katalog modellieren, Produkte laden, ERP für Preise und Bestand anbinden, Kundenorganisationen modellieren. Nichts davon sieht ein Kunde. Das ist nach Aufwand der größte Teil des Projekts und nach Risiko das ganze. Das Abnahmekriterium ist konkret: Für zehn echte Kunden und fünfzig echte Artikel zeigt die Plattform denselben Nettopreis und dieselbe Verfügbarkeit wie das ERP, Zeile für Zeile geprüft.

Phase 2: ein echter Pilot mit benannten Kunden. Echte Domain, echte Preise, echte Bestellungen, ein begrenztes Sortiment und eine begrenzte Kundengruppe, die weiß, dass sie die erste ist. Alles danach lässt sich leichter beheben, solange das Publikum klein ist. Phase 2 hängt vollständig am Abnahmekriterium von Phase 1. Mit Preisen live zu gehen, die zu 95 % stimmen, heißt, dass jeder Kunde die anderen 5 % persönlich kennenlernt.

Phase 3: erweitern und ergänzen. Sortiment öffnen, Kunden in Wellen über den Innendienst migrieren, dann nachziehen, was auf der Wunschliste stand: Punchout für die Kunden, die es brauchen, eine zweite Sprache, Angebote in der Plattform, Portalfunktionen. Jedes davon ist ein kleines Projekt, sobald das Fundament steht, und ein riesiges davor.

Typische Fehler

Mit dem Design anfangen. Es ist der einzige Teil, den jeder beurteilen kann, und genau deshalb bekommt es Aufmerksamkeit, die es nicht verdient hat.
Die ERP-Anbindung auf „Phase 2" verschieben. Sie ist der kritische Pfad. Alles, was vorher gebaut wird, steht auf Annahmen.
Einen Kunden als Login behandeln. Ein geteilter Zugang macht Freigabegrenzen pro Kontakt wertlos, verbirgt, wer was bestellt hat, zerstört das Reporting und lässt sich nach dem Go-live nur mühsam entflechten.
Den Start allen gleichzeitig ankündigen. Jeder Fehler taucht gleichzeitig auf, vor Ihrem gesamten Kundenstamm, und Sie haben einen ersten Eindruck.
Keine Definition von „die Daten sind fertig". Ohne schriftlichen Vollständigkeitsstandard pro Kanal ist der Katalog nie fertig, und der Starttermin wandert nach Gefühl.
Die Wunschliste ins erste Release bauen. Konfigurator und Punchout sind berechtigte Anforderungen. Sie gehören nicht ins erste Release.

Woran Sie erkennen, dass es funktioniert

Zeit bis zur ersten Bestellung eines echten Kunden ohne Hilfe. Die aussagekräftigste Zahl in diesem Projekt und der Grund, einen Piloten zu fahren statt eine Demo.
Zweitbestellungen. Wie viele Ihrer Pilotkunden haben innerhalb ihres normalen Bestellrhythmus erneut bestellt? Die erste Bestellung beweist, dass der Shop funktioniert. Die zweite beweist, dass er besser war als anrufen.
Gemeldete Preisfehler pro Woche. Gegen Ende von Phase 2 nahe null, vor der Erweiterung genau null.
Durchlaufquote, also Bestellungen, die ohne menschlichen Eingriff im ERP ankommen. Siehe Manuelle Arbeit reduzieren.
Abbrüche im Checkout pro Schritt, plus Bestellungen in pending. Im B2B ist der interessante Schritt nicht die Zahlung. Zählen Sie die Bestellungen, die wegen einer überschrittenen Freigabegrenze angehalten wurden, und wie lange jede gewartet hat, bis jemand sie freigegeben hat. Diese Warteschlange ist heute manuell, also ist das eine Servicekennzahl.
Produkte, die den Vollständigkeitsstandard des Live-Kanals verfehlen. Ziel null für das gestartete Sortiment; die Zahl für den Rest ist Ihr Plan für Phase 3.

Was Sie bauen

Eine Storefront, in der ein angemeldeter Einkäufer seine Artikel zu seinen Nettopreisen sieht, mit dem Bestand aus Ihrem Lager, und eine Bestellung aufgibt, die im ERP steht, bevor morgens jemand im Büro ist. Das ERP bleibt zuständig für Konditionen, Bestand und Rechnung. Die Plattform hält Katalog, Kundenmodell und Checkout, und das Integration Studio bewegt die Daten zwischen beiden.

flowchart LR
  ERP["Ihr ERP"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    P["Produkte"]
    PR["Preise"]
    INV["Bestand"]
    C["Kunden"]
    CART["Warenkörbe"]
    O["Bestellungen"]
    PAY["Zahlungen"]
    SH["Versand"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
  end
  ERP -- "Artikelstamm" --> WF
  ERP -- "Konditionen, Listenpreise" --> WF
  ERP -- "Bestand" --> WF
  WF --> P
  WF --> PR
  WF --> INV
  ERP -- "Kundennummern" --> C
  SF -- "Login, Warenkorb" --> CART
  CART --> O
  PAY --> O
  SH --> O
  O -- "Bestellung" --> WF
  WF -- "Bestellung" --> ERP
  WF -- "Status, Belege" --> SF
  classDef planned stroke-dasharray: 5 5

Was Sie brauchen

Ein schriftliches Datenmodell: Familien, Attribute mit Einheiten, Variantenachsen, Kategorien in der Logik des Einkäufers — Datenmodell planen
Das Startsortiment geladen und vollständig für den Web-Kanal — Vollständigkeit und Bereitschaft
Eine Entscheidung, wo die Kundenkonditionen liegen und wie sie in den Shop kommen — Preise und Ihr ERP
Eine funktionierende ERP-Anbindung für Bestand und Bestellungen, mit benanntem Verantwortlichen — Ein System anbinden
Kundenstammdaten bereinigt auf eine Organisation pro Unternehmen, mit benannten Kontakten — Kundendaten-Hygiene
Zahlungsarten, Versandarten und Nummernkreise, abgestimmt mit Buchhaltung und Lager — Checkout konfigurieren
Eine Domain und ein Storefront-Theme — Domains und Go-live
Fünf bis zehn Pilotkunden, die wissen, dass sie die ersten sind, und ein Innendienst-Kollege, der sie betreut — Bestandskunden online bringen

So bauen Sie es

Datenmodell auf einer Seite aufschreiben und vom Produktmanagement abnehmen lassen — Datenmodell planen
Attribute, Attributgruppen und Familien im Cockpit anlegen — Attribute und Attributgruppen
Ein Produkt von Hand anlegen und für den Web-Kanal auf 100 % bringen — Ein Produkt anlegen
Importdatei aus dem ERP-Export vorbereiten und das Startsortiment laden — Produkte in Masse importieren
Märkte, Währungen und Steuerklassen einrichten — Währungen und Steuern
Listenpreisliste und kundenspezifische Preislisten anlegen — Preislisten
ERP anbinden: Bestand rein, Bestellungen raus, Preise nach der getroffenen Entscheidung — Ein System anbinden
Organisationen, Kontakte, Rollen und Zahlungsbedingungen laden — Organisationen
Zehn Kunden und fünfzig Artikel Zeile für Zeile gegen das ERP prüfen — Prüfen, welchen Preis ein Einkäufer sieht
Checkout, Zahlungsarten, Versand und Nummernkreise konfigurieren — Checkout konfigurieren
Storefront anlegen, Theme anwenden, Domain verbinden — Storefront anlegen
Prüfungen vor dem Start durchführen — Prüfungen vor dem Start
Pilotkunden einzeln im Gespräch onboarden — Bestandskunden online bringen
Bestellübertragung und Preisfehler wöchentlich beobachten, dann erweitern — Synchronisationen überwachen

Entscheidungen, die Sie treffen müssen

Entscheidung	Die Abwägung	Wohin die meisten Kunden gehen
Wo liegen die Kundenkonditionen? Das ERP bleibt Eigentümer und die Plattform liest sie, oder Sie pflegen Preislisten in der Plattform und exportieren ins ERP.	ERP-geführt heißt: Der Shop stimmt immer dann, wenn das ERP stimmt, aber jede Konditionsart des ERP muss lesbar sein, und die Anbindung liegt auf dem kritischen Pfad. Plattform-geführt startet schneller und ist falsch, sobald der Innendienst aus Gewohnheit eine Kondition im ERP ändert.	ERP-geführt, live gelesen für Kundenkonditionen und nächtlich für Listenpreise. Fünfzehn Jahre Konditionen ziehen nicht um, und niemand will zwei Orte, an denen ein Rabatt gepflegt wird.
Was sieht ein anonymer Besucher? Preise, nur Listenpreise, oder einen Katalog ohne Preise.	Öffentliche Preise bringen Suchtraffic und neue Kunden, und Ihre Händler und Wettbewerber lesen mit. Keine Preise schützt die Konditionen und schließt die Tür für neue Nachfrage.	Katalog öffentlich, Listenpreise öffentlich, wo keine Händler beteiligt sind, alles Weitere nach Login. Unternehmen mit Händlernetz halten Preise hinter dem Login und nehmen die verlorene Reichweite in Kauf.
Eine Organisation pro Unternehmen oder pro Standort? Ein Kunde mit drei Werken ist eine Organisation mit drei Lieferadressen oder drei Organisationen.	Eine Organisation hält die Historie zusammen und macht unternehmensweites Reporting trivial, aber jeder Kontakt sieht jeden Standort. Drei trennen die Standorte für Berechtigungen, und die Zentrale verliert den Überblick. Organisationen haben keine Eltern-Kind-Hierarchie, beides zugleich geht heute nicht.	Eine Organisation mit Adressen, außer die Standorte kaufen zu getrennten Konditionen oder dürfen die Bestellungen der anderen nicht sehen. Segmente fassen für das Reporting zusammen, was zusammengehört.
Rechnung als Zahlungsart für wen? Für jeden, der sich registriert, nur für bekannte Kunden, oder für niemanden vor der Prüfung.	Offene Rechnungsziele nehmen jede Hürde und legen das Kreditrisiko auf jede neue Registrierung. Vorkasse für unbekannte Konten ist sicher und kostet einige Erstbestellungen.	Rechnung für Bestandskunden, übernommen aus den Zahlungsbedingungen des ERP; Karte oder Vorkasse für selbst registrierte Konten, bis jemand sie umstellt.
Wie gehen Sie mit Bestellungen über der Freigabegrenze eines Kontakts um? Grenze setzen und Bestellung anhalten, oder Grenzen aus und alles durchlassen.	Eine angehaltene Bestellung respektiert die Einkaufsregeln des Kunden, und die Freigabe ist heute ein manueller Schritt auf Ihrer Seite. Ohne Grenzen kann der Shop von Einkäufern, deren Unternehmen eine Freigabe verlangt, nicht genutzt werden.	Grenzen an für die größeren Kunden, die danach fragen, mit einer benannten Person, die angehaltene Bestellungen täglich freigibt. Alle anderen: keine Grenze, Bestellung geht direkt durch.
Start für wen? Eine Pilotgruppe von fünf bis zehn Kunden oder alle Kunden per Mailing.	Ein Pilot findet Fehler vor Leuten, die sie verzeihen, und kostet ein paar Wochen. Ein Mailing ist schneller und zeigt jeden Fehler allen gleichzeitig.	Ein Pilot. Wer das Mailing einmal gemacht hat, macht es kein zweites Mal.