Ein Kundenportal starten

Bevor ein Kunde online etwas kauft, will er meist das, was er schon hat: seine Rechnungen, seine Lieferscheine, seine Bestellhistorie, seine offenen Angebote, seine Vertragspreise. Der häufigste Serviceanruf im B2B ist eine Suche: „Können Sie mir die Rechnung vom März noch einmal schicken?" Ein Portal ist oft der Einstieg mit dem geringsten Risiko in den digitalen Vertrieb, weil es am ersten Tag nützlich ist und niemand anders einkaufen muss als bisher.

Warum das schwerer ist, als es klingt

Die Belege, die Ihre Kunden wollen, sind nicht schwer zu erzeugen. Sie sind schwer zu adressieren. Ein Rechnungs-PDF liegt im ERP, in einem Dokumentenarchiv oder in der Ordnerstruktur der Buchhaltung, und der Weg zur „März-Rechnung für Meyer GmbH" war bisher eine Person, die weiß, wo sie suchen muss. Das zuverlässig nach Kunde, Zeitraum und Belegart abrufbar zu machen, ist die technische Arbeit in einem Portalprojekt. Sie wird unterschätzt, weil die manuelle Variante so banal aussieht.

Das zweite Problem sind Berechtigungen, und das ist ein Datenschutzproblem, bevor es ein Designproblem ist. Bei einem Kunden mit drei Standorten und elf Einkäufern: Wer darf die Rechnungen sehen? Wer die Bestellungen anderer Abteilungen? Wer das Kreditlimit? Ein Fehler hier ist ein Vorfall, bei einem Kunden, dessen interne Politik Sie nicht kennen. Das Berechtigungsmodell steht fest, bevor der erste Beleg veröffentlicht wird.

Daraus folgt das dritte Hindernis: Sie wissen vermutlich nicht, wer die Menschen bei Ihren Kunden sind. Ihre Stammdaten haben eine Organisation, eine allgemeine E-Mail-Adresse und einen Ansprechpartner, der 2021 gegangen sein könnte. Ein Portal braucht Personen mit Rollen. Die zu erheben ist Datenarbeit mit Ihrem Innendienst und Ihren Kunden, und sie läuft parallel zur technischen Arbeit.

Portale scheitern häufiger an Leere als an Fehlern. Ändert sich zwischen zwei Besuchen nichts, gibt es keinen Grund zurückzukommen. Legen Sie vor dem Start fest, was den zweiten Login wert macht (vollständige Historie, aktueller Bestellstatus, Belege am Tag ihrer Erstellung), und benennen Sie einen Verantwortlichen. Ein Portal ohne Verantwortlichen wird zu einer Login-Seite, die niemand nutzt.

Die Hebel

Modellieren, wer die Menschen beim Kunden sind und was jeder sehen darf

So sieht es gut aus: Der Kunde ist eine Organisation, die Menschen sind einzelne Kontakte mit benannten Rollen. Jede Rolle hat eine ausdrückliche Antwort auf: welche Belege, welche Bestellungen, welche Preise, welche Adressen.

Entscheiden Sie vor dem Laden, wie Sie Niederlassungen abbilden. Organisationen haben keine Eltern-Kind-Hierarchie. Ein Kunde mit drei Standorten wird als eine Organisation mit mehreren Adressen abgebildet, als drei getrennte Organisationen oder über Segmente. Alle drei funktionieren und verhalten sich bei Berechtigungen und Reporting sehr unterschiedlich. Wer sich nach dem Laden entscheidet, lädt noch einmal.

Wovon es abhängt: Geteilte Logins auflösen und Kundenstammdaten so weit bereinigen, dass ein Unternehmen eine Organisation ist und nicht vier Beinahe-Duplikate.

1. Das B2B-Kundenmodell
2. Wie Beschaffungsregeln funktionieren
3. Organisationen
4. Kontakte und Rollen
5. Kundendaten-Hygiene
6. Sicherheit und Datenschutz

Belege und die gesamte Historie sichtbar machen

So sieht es gut aus: Jede Bestellung, die der Kunde bei Ihnen aufgegeben hat, über jeden Kanal, mit aktuellem Status, Lieferscheinen und Rechnungen, verfügbar an dem Tag, an dem der Beleg existiert.

Wovon es abhängt: Eine funktionierende Verbindung dorthin, wo Belege und Bestellstatus liegen, und eine Zuordnungsregel, die einen Beleg zuverlässig einem Kunden zuweist.

1. Der Lebenszyklus einer Bestellung
2. Integrationsmuster
3. Ein System anbinden
4. Teillieferungen und Rückstände
5. Retouren und Gutschriften
6. Synchronisationen überwachen

Den Kunden sich selbst verwalten lassen

Der Sinn eines Portals ist, dass niemand anrufen muss. Das schließt die Verwaltungsanrufe ein: Ein neuer Kollege braucht Zugang, jemand ist gegangen, die Lieferadresse hat sich geändert, ein Einkäufer wurde befördert und darf jetzt mehr freigeben.

Das Ergebnis: Ein benannter Administrator beim Kunden legt eigene Kollegen an und entfernt sie, vergibt Rollen, setzt Freigabegrenzen und pflegt die eigenen Adressen, ohne Sie zu kontaktieren.

Wo die Grenze heute liegt: Kontakte, Rollen, Adressen und die Freigabegrenze jedes Kontakts sind real und pflegbar, und die Grenze greift beim Bestellen. Kostenstellen sind keine Stammdaten. Eine Kostenstelle ist Freitext, den der Einkäufer auf der Bestellposition eingibt; es gibt keine Liste zum Pflegen und kein Budget, das belastet wird. Eine Bestellung über der Grenze eines Kontakts wird angehalten, und die Freigabe ist ein manueller Schritt auf Ihrer Seite.

Wovon es abhängt: Rollen, die dem Kunden etwas sagen und nicht nur Ihrem internen Berechtigungsmodell, und für größere Kunden die Möglichkeit, den eigenen Identity Provider zu nutzen.

1. Kontakte und Rollen
2. Freigaberegeln
3. Kostenstellen und Budgets
4. Benutzer, Rollen und Berechtigungen
5. Single Sign-on

Dann handeln lassen, auf Basis dessen, was sie sehen

Nachbestellen aus der Historie ist normalerweise der erste transaktionale Schritt und der anspruchsloseste, weil der Einkäufer etwas wählt, das er bei Ihnen schon gekauft hat.

So sieht es gut aus: Jede historische Bestellung lässt sich mit zwei Klicks wiederholen oder anpassen, zu den aktuellen Preisen des Kunden. Offene Angebote lassen sich annehmen. Retouren werden aus dem Lieferschein heraus beantragt statt per E-Mail.

Wovon es abhängt: Preise, die stimmen. Sobald das Portal einen Preis zeigt, erbt es jede Anforderung aus Bestandskunden online bringen.

1. Vertragspreise für einen Kunden
2. Eine Bestellung bearbeiten
3. Angebote und Verhandlung
4. Checkout konfigurieren
5. Formulare und Transaktionsmails

Eine sinnvolle Reihenfolge

Phase 1: nur lesend, und vollständig. Belege, komplette Bestellhistorie über alle Kanäle, aktueller Bestellstatus, die Stammdaten des Kunden. Keine Transaktionen. Diese Phase ist der Grund, warum ein Portal ein so gutes erstes Projekt ist: Sie beseitigt eine ganze Kategorie von Serviceanrufen, kann keine falsche Bestellung erzeugen und liefert das Argument für alles danach. Voraussetzung: Belegabruf und saubere Kundendaten, sonst nichts.

Phase 2: Selbstverwaltung. Geben Sie dem Kunden die Kontrolle über eigene Kontakte, Rollen, Adressen und Freigabegrenzen pro Kontakt. Kostenstellenlisten und Budgetverfolgung bleiben vorerst im Einkaufssystem des Kunden, und jede über einer Grenze angehaltene Bestellung gibt Ihr Team manuell frei. Sagen Sie das offen, wenn Sie die Phase einführen, denn sie ist teils Prozess und nicht nur Funktion. Diese Phase setzt voraus, dass Phase 1 das Berechtigungsmodell in der Praxis bestätigt hat, und sie macht aus dem Portal ein Werkzeug, auf das sich der Einkauf des Kunden verlässt.

Phase 3: Transaktionen. Nachbestellen aus der Historie, Angebote annehmen, Retouren beantragen. Weil das auf denselben Kunden-, Preis- und Bestandsdaten läuft, ist es ein Konfigurationsschritt und kein zweites Projekt. Es ist aber auch der Punkt, an dem Preisrichtigkeit nicht mehr verhandelbar ist. Ziehen Sie ihn nicht vor, um ehrgeiziger zu wirken.

Typische Fehler

• Mit reiner Online-Historie starten. Die Kunden, für die Sie das gebaut haben, haben telefonisch bestellt. Zeigen Sie ihnen die ganze Beziehung oder gar nichts.
• Geteilte Logins behalten. Ein Passwort für einen ganzen Einkauf macht Rollen, Freigabegrenzen, Nachvollziehbarkeit und Reporting bedeutungslos, und nach dem Start lässt sich das viel schwerer entflechten als davor.
• Belege veröffentlichen, bevor das Berechtigungsmodell steht. Der eine Fehler auf dieser Seite mit rechtlichen Folgen.
• Ein leeres Portal. Ändert sich zwischen zwei Besuchen nichts, gibt es keinen zweiten Besuch. Legen Sie fest, was der wiederkehrende Grund zum Anmelden ist.
• Kein Verantwortlicher nach dem Go-live. Portale scheitern nicht laut. Sie werden nicht mehr gepflegt, und die Nutzung sinkt, bis jemand vorschlägt, sie zu ersetzen.
• Ein neues Passwort erzwingen, ohne Self-Service-Reset, und Kunden, die es erwarten, kein Single Sign-on anbieten. Zugangshürden sind der vermeidbarste Grund, warum ein Portal ungenutzt bleibt.

Woran Sie erkennen, dass es funktioniert

• Verschiedene Kontakte pro Kunde, die sich diesen Monat angemeldet haben. Menschen, nicht Logins. Eine Person beim Kunden ist ein Fürsprecher; fünf sind Akzeptanz.
• Von Kunden abgerufene Belege gegen Beleganfragen, die noch Ihr Team erreichen. Diese beiden Linien sollten sich kreuzen. Kategorisieren Sie vorher eine Woche eingehender Anfragen, damit Sie einen Ausgangswert haben.
• Anteil der Kunden mit mehr als einem aktiven Kontakt. Ein Portal, in dem jeder Kunde noch ein geteiltes Login hat, hat seinen wichtigsten strukturellen Nutzen nicht erreicht.
• Selbstverwaltungsaktionen pro Monat: Kontakte angelegt, Adressen geändert, Rollen neu vergeben. Jede davon ist eine E-Mail, die Ihr Team nicht bekommen hat.
• Wiederholte Logins. Der Anteil der Kontakte, die sich innerhalb eines Monats erneut angemeldet haben, ist das ehrliche Maß dafür, ob es einen Grund zum Zurückkommen gibt.
• Zeit vom ersten Login bis zur ersten Self-Service-Bestellung, sobald Phase 3 live ist. Die Zahl, die zeigt, dass das Portal zum Vertriebskanal wird.

Verwandte Ziele

• Bestandskunden online bringen, das Ziel, in das dieses hier mündet.
• Manuelle Arbeit reduzieren, wo sich der interne Rücklauf des Portals zeigt.
• Ersatzteile online verkaufen, der andere übliche Einstieg mit geringem Risiko.

Was Sie bauen

Einen angemeldeten Bereich Ihrer Storefront, in dem jeder Kontakt beim Kunden die Bestellungen, Lieferscheine und Rechnungen sieht, die seine Rolle erlaubt, aus jedem Kanal, über den Sie verkaufen, dazu eigene Adressen und Kollegen. ERP und Belegarchiv bleiben die Quelle; das Integration Studio holt Bestellstatus und Belege herüber und hängt sie an die richtige Organisation. Bestellen kommt später, auf denselben Daten.

flowchart LR
  ERP["Ihr ERP"]
  DOC["Belegarchiv"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    C["Kunden: Organisationen, Kontakte, Rollen"]
    O["Bestellungen"]
    SHP["Sendungen"]
    PR["Preise"]
    OL["Bestelllisten"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront: Portal"]
    MSG["Messaging"]
  end
  ERP -- "Bestellungen aller Kanäle, Status" --> WF
  DOC -- "Rechnungen, Lieferscheine" --> WF
  WF --> O
  WF --> SHP
  WF -- "Belege angehängt" --> O
  ERP -- "Kundennummern, Zahlungsbedingungen" --> C
  C -- "wer sieht was" --> SF
  O --> SF
  PR -- "aktuelle Preise zum Nachbestellen" --> SF
  SF -- "Nachbestellung" --> OL
  MSG -- "Einladung, Passwort-Reset" --> SF
  classDef planned stroke-dasharray: 5 5

Was Sie brauchen

• Kundenstammdaten bereinigt auf eine Organisation pro Unternehmen, mit einer Entscheidung, wie Standorte abgebildet werden — Organisationen
• Benannte Kontakte pro Kunde mit Rollen, erhoben mit dem Innendienst — Kontakte und Rollen
• Ein schriftliches Berechtigungsmodell: welche Rolle sieht welche Belege, Bestellungen, Preise und Adressen — Sicherheit und Datenschutz
• Bestellhistorie aus allen Kanälen, auch Telefon- und E-Mail-Bestellungen, in der Plattform — Abgleich mit dem ERP
• Eine Verbindung dorthin, wo Rechnungen und Lieferscheine liegen, mit einer Regel, die jeden Beleg einem Kunden zuordnet — Ein System anbinden
• Eine Storefront mit Login und Transaktionsmails für Einladungen und Passwort-Resets — Formulare und Transaktionsmails
• Ein benannter Verantwortlicher für das Portal nach dem Go-live — Benachrichtigungen

So bauen Sie es

1. Eine Woche eingehender Beleg- und Statusanfragen kategorisieren, als Ausgangswert — Kennzahlen, die zählen
2. Entscheiden, wie Niederlassungen abgebildet werden: eine Organisation mit Adressen, mehrere Organisationen oder Segmente — Organisationen
3. Organisationen und Adressen bereinigen und laden — Kundendaten-Hygiene
4. Rollen definieren und aufschreiben, was jede sehen darf — Kontakte und Rollen
5. Benannte Kontakte pro Kunde über den Innendienst erheben und mit Rollen laden — Kontakte
6. Bestellungen aus allen Kanälen mit Status in die Plattform bringen — Ein System anbinden
7. Belegquelle anbinden und Rechnungen und Lieferscheine an Bestellungen hängen — Feldzuordnung
8. Storefront-Login, Einladungs- und Passwort-Reset-Mail einrichten — Formulare und Transaktionsmails
9. Single Sign-on den Kunden anbieten, die danach fragen — Single Sign-on
10. Nur lesend für eine Pilotgruppe starten, dann für alle Kunden — Prüfungen vor dem Start
11. Verwaltung an eine benannte Person je Kunde übergeben: Kontakte, Rollen, Adressen, Freigabegrenzen — Freigaberegeln
12. Nachbestellen aus der Historie zu den aktuellen Preisen des Kunden einschalten — Bestelllisten und Nachbestellung
13. Beleg-Self-Service gegen eingehende Anfragen monatlich beobachten — Synchronisationen überwachen

Entscheidungen, die Sie treffen müssen

Verwandte Produktbereiche

• Commerce Studio — Organisationen · Kontakte · Rollen · Segmente · Adresstypen · Bestellungen · Sendungen · Retouren · Bestelllisten · Preise
• Experience Studio — Sites · Seiten · Formulare · Messaging · Dokumente
• Integration Studio — Zugangsdaten · Workflows · Feldzuordnung · Storage Sync · Läufe