Ein B2B-Webshop mit Selfservice hinter dem Login ist ein Kundenportal. Es sind keine zwei Systeme, die Sie nebeneinanderstellen, sondern zwei Aufgaben derselben Umgebung: neue Kunden gewinnen und bestehende Kundenbeziehungen pflegen.
Großhändler fragen sich oft, ob sie neben ihrem B2B-Webshop auch ein Kundenportal brauchen. Das ist die falsche Frage. Sie wird so häufig als Entscheidung gestellt, weil bei vielen Großhändlern tatsächlich zwei Dinge daraus geworden sind. Das hat sich über die Jahre eingeschlichen, ohne dass sich jemals jemand dafür entschieden hätte.
Warum es trotzdem oft zwei Umgebungen sind
Viele B2B-Webshops wurden für die erste Bestellung entworfen. Suchen, Warenkorb, Kasse. Die Fragen, die nach dieser Bestellung kommen, etwa wo meine Lieferung bleibt und ob diese Rechnung stimmt, blieben beim Innendienst liegen. Als das zu viel wurde, kam eine Lösung hinzu: ein Portal des ERP-Anbieters, eine separate Händlerplattform, ein Mein-Konto-Bereich, der nicht mehr tut, als ein paar PDFs anzuzeigen, oder eine Kundenumgebung, die einst für einen großen Abnehmer gebaut wurde.
Das Ergebnis ist eine geteilte Umgebung, und die kostet mehr, als sie löst:
- Zwei Wahrheiten über dieselben Daten. Der Shop zeigt einen Preis, das Portal einen anderen. Der Kunde ruft an, um zu fragen, welcher stimmt.
- Zwei Login-Wege. Der Einkäufer weiß nicht, wo er den Lieferschein findet, also schreibt er eine E-Mail.
- Zwei Pflegeaufwände. Benutzer, Rollen und Preise werden an zwei Stellen gepflegt, mit den entsprechenden Abweichungen.
- Ein gebrochener Bestellweg. Der Kunde sieht im Portal, was er im Vormonat gekauft hat, muss aber in den Shop wechseln, um es erneut zu bestellen.
Eine Umgebung, die nach dem Login auf kundenspezifische Preise, Bestellhistorie, offene Rechnungen und Nachbestellungen umschaltet, löst das. Für den Besucher ist es eine Website. Technisch ist es ein Datenmodell mit einer Quelle: Ihrem ERP.
Was Sie stattdessen entscheiden müssen
Wenn die Frage nicht lautet, ob Sie ein Portal neben Ihren Webshop stellen, wird sie zu der Frage, welche Selfservice-Ebenen Sie wann ergänzen. Das ist eine echte Abwägung, denn jede Ebene stellt Anforderungen an Ihre Daten.
| Selfservice-Ebene | Daten, die das ERP bereitstellen muss | Was sie abnimmt | Abhängigkeit |
|---|---|---|---|
| Bestellhistorie und Auftragsstatus | Aufträge und Auftragspositionen, einschließlich Aufträge außerhalb des Shops, mit Teillieferungen | Statusanfragen, Bitten um eine Kopie des Lieferscheins | der Status muss auf Positionsebene verfügbar sein, nicht nur je Auftrag |
| Kundenspezifische Preise | Preisvereinbarungen, Staffeln, Vertragskonditionen, freigegebenes Sortiment | Preisprüfungen, Gutschriften nach einem falschen Preis | die Konditionen in Ihrem ERP müssen aktuell und sauber sein |
| Nachbestellen | Bestellhistorie sowie aktueller Bestand und Lieferzeit | Suchen im Katalog, Bestelllisten per E-Mail | der Bestand darf nicht hinterherhinken, sonst bestellt der Kunde falsch |
| Rechnungen und offene Posten | Rechnungen, Zahlungsstatus, offene Beträge | Rechnungskopien, Zahlungsfragen, manuelle Erinnerungen | die Finanzdaten müssen zu dem passen, was Ihre Buchhaltung sieht |
| Benutzer, Rollen und Standorte | Ansprechpartner, Debitorennummern, Kostenstellen | falsch gebuchte Aufträge, unberechtigte Einsicht | Ihre Kundenstammdaten müssen der tatsächlichen Organisationsstruktur folgen |
Die Reihenfolge bestimmen Sie nicht danach, welche Funktion sich am schönsten vorführen lässt, sondern nach zwei Dingen: welche Frage Ihr Innendienst am häufigsten bekommt und welche Daten Ihr ERP zuverlässig bereitstellen kann. Diese beiden fallen selten zusammen, und wo sie auseinandergehen, liegt Ihr erstes Projekt.
Ein Portal macht schlechte Daten für den Kunden sichtbar
Solange Preisvereinbarungen und Bestände nur im ERP stehen, sieht vor allem Ihr Innendienst die Abweichungen. Die werden im Gespräch korrigiert, meist ohne dass der Kunde es merkt. Legen Sie dieselben Daten hinter ein Login, sieht der Einkäufer sie direkt. Eine veraltete Staffel ist dann kein interner Punkt mehr, sondern eine Diskussion mit Ihrem Kunden.
Das ist kein Argument dafür, Selfservice aufzuschieben. Es ist ein Argument dafür, je Ebene zuerst zu prüfen, ob die zugrunde liegenden Daten stimmen. In der Praxis bedeutet das drei Situationen, in denen Sie besser mit Bereinigen oder Bereitstellen beginnen als mit Bauen:
Das ERP kann die Daten nicht liefern. Sind Auftragspositionen, offene Posten oder Preisvereinbarungen nicht über eine Schnittstelle verfügbar, bauen Sie eine Ansicht, die hinterherhinkt. Das kostet Vertrauen, das Sie schwer zurückgewinnen.
Die Kunden- und Preisdaten sind nicht verlässlich. Veraltete Konditionen, doppelte Ansprechpartner, Debitorennummern, die nicht zu den tatsächlichen Standorten passen, Rabatte, die einst mündlich vereinbart wurden. Das ist der am meisten unterschätzte Teil jedes Projekts.
Das Problem ist die Akzeptanz, nicht die Funktionalität. Kommt nur ein kleiner Teil Ihrer Aufträge online herein, obwohl die Funktionen längst da sind, hilft mehr Funktionalität nicht. Dann geht es um das Onboarding der Einkäufer und um die Frage, ob Ihre eigenen Kundenbetreuer den digitalen Weg fördern oder daran vorbeiarbeiten. Verhaltensänderung dauert erheblich länger als die Implementierung.
Eine Plattform oder ein Portal obendrauf?
Weil es eine Umgebung sein sollte, verschiebt sich auch die Plattformfrage. Sie dreht sich nicht darum, welches Portal Sie neben Ihren Shop hängen, sondern darum, ob Ihre Plattform Selfservice als Teil desselben Datenmodells behandelt. Fünf Fragen, die weiter helfen als ein Funktionsvergleich:
- Wie tief geht die Standardintegration mit Ihrem konkreten ERP, und was ist Individualentwicklung?
- Welche Daten kann die Plattform in Echtzeit bereitstellen und welche nicht?
- Wie werden Firmenkonten mit mehreren Benutzern, Rollen und Standorten abgebildet?
- Was passiert bei einem Release: gehen Sie mit oder bleiben Sie auf einer alten Version zurück?
- Wer ist verantwortlich, wenn die Anbindung ausfällt, und wie merken Sie das, bevor Ihr Kunde es merkt?
Eine Plattform, die als Konsumenten-Webshop entworfen und später um B2B-Funktionalität ergänzt wurde, stößt an Grenzen, sobald kundenspezifische Preise, Angebotsworkflows, Rechte je Standort und Freigabeschritte zusammenkommen. Diese Grenzen merken Sie selten in der Demo und fast immer im zweiten Jahr.
CloudSuite ist aus der operativen Logik von Großhändlern und Markenherstellern heraus aufgebaut, mit B2B-E-Commerce für Großhändler und Selfservice in derselben Plattform statt als separater Schicht. Wie unterschiedlich das ausfällt, zeigen die Kundenbeispiele: Secrid wickelt die Geschäftsbestellungen über eine Mobile-only-B2B-Plattform ab, daneben läuft ein Headless-B2C-Webshop auf demselben Backend, Beko Groothandel beliefert als Einkaufsorganisation Bäcker, Patissiers und Chocolatiers, und Versluis, Großhändler für Malerwerkzeug, löste einen veralteten Webshop ab. Drei sehr unterschiedliche Bestellprozesse, mit derselben zugrunde liegenden Anforderung: die Daten kommen aus dem ERP und müssen stimmen. Welche Anbindungen möglich sind, zeigt die Übersicht der ERP-Integrationen.
Womit Sie morgen anfangen können
Zwei Bestandsaufnahmen, beide ohne Projekt und ohne Budget durchführbar, die dem weiteren Verlauf die Richtung geben.
Zählen Sie zwei Wochen lang die Anfragen an Ihren Innendienst. Kategorisieren Sie grob: Auftragsstatus, Rechnung oder Zahlung, Preis oder Kondition, Bestand, Korrektur an einem laufenden Auftrag, Sonstiges. Danach haben Sie Ihre eigenen Zahlen und müssen sich nicht auf Branchendurchschnitte stützen.
Erfassen Sie je Datenart aus der Tabelle oben, was Ihr ERP bereitstellen kann. Über eine Schnittstelle verfügbar, wie aktuell, und wie verlässlich der Inhalt heute ist.
Wo sich diese beiden Listen kreuzen, liegt Ihre erste Selfservice-Ebene.