Digital verkaufen

Ein Kundenportal starten

Ein Ort für Belege, Bestellungen und Self-Service, statt fünf E-Mail-Verläufe.

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.

Ein Portal, das nur Online-Bestellungen zeigt, ist genau für die Kunden nutzlos, für die Sie es gebaut haben. Die bestellen telefonisch. Zeigt ihr Portal zwei Bestellungen und ihre Wirklichkeit sind zweihundert, melden sie sich einmal an und nie wieder. Die vollständige Historie über alle Kanäle ist die Funktion.

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.

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.

Die Menschen und Regeln des Kunden aktuell halten

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 neuer Kollege hat am selben Tag Zugang, wer gegangen ist, verliert ihn am selben Tag, und das neue Ausgabenlimit eines beförderten Einkäufers gilt ab der nächsten Bestellung. Ein benannter Administrator beim Kunden meldet, was sich geändert hat; eine benannte Person auf Ihrer Seite setzt es um.

Wo es gepflegt wird: Kontakte, Rollen und Adressen im CRM; Kostenstellen, Budgets und persönliche Limits unter Kostenstellen; Freigaberegeln unter Procurement › Freigaberegeln. All das pflegen Sie in Ihrem Cockpit, nicht der Kunde. Was ein Einkäufer ausgeben darf, ist das persönliche Limit, das eine Freigaberegel prüft; die Freigabegrenze am Kontakt wird gespeichert und angezeigt, beim Bestellen aber nicht geprüft.

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.

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.

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: die Menschen und Einkaufsregeln des Kunden. Einzelne Kontakte mit Rollen für jedes Konto und, für die Konten, die danach fragen, ihre Kostenstellen, Budgets, persönlichen Limits und Freigaberegeln. Ein benannter Administrator beim Kunden meldet Änderungen; eine benannte Person auf Ihrer Seite setzt sie um. 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, persönliche Ausgabenlimits, 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.
Verwaltungsänderungen pro Monat, und wie lange jede gedauert hat: Kontakte angelegt, Adressen geändert, Rollen neu vergeben. Eine langsame Änderung ist ein Einkäufer, der nicht bestellen konnte.
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.

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.

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

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

Entscheidungen, die Sie treffen müssen

Entscheidung	Die Abwägung	Wohin die meisten Kunden gehen
Wie bilden Sie einen Kunden mit mehreren Standorten ab? Eine Organisation mit mehreren Adressen, eine Organisation pro Standort, oder eine Organisation plus Segmente.	Eine Organisation: die ganze Historie an einem Ort, aber jeder Kontakt sieht die Belege aller Standorte, sofern Rollen das nicht einschränken. Eine pro Standort: saubere Berechtigungen, und die Zentrale hat keinen Überblick, weil es heute keine Eltern-Kind-Hierarchie gibt.	Eine Organisation mit Adressen und Rollen für Kunden, die zentral einkaufen; eine pro Standort, wo die Standorte kaufmännisch getrennt sind. Pro Kundentyp entscheiden, vor dem Laden.
Was zählt als Bestellhistorie? Nur Online-Bestellungen oder jede Bestellung aus dem ERP.	Nur online ist am ersten Tag verfügbar und zeigt dem Kunden zwei von zweihundert Bestellungen. Alles erfordert zuerst die ERP-Anbindung und ist der Grund, warum der Kunde wiederkommt.	Alles, auch wenn das Portal einen Monat später startet.
Wer hält die Menschen beim Kunden aktuell? Ihr Innendienst allein oder im Auftrag eines benannten Administrators beim Kunden.	Allein erfährt Ihr Innendienst als Letzter von Abgängen. Ein benannter Administrator, der Änderungen meldet, hält die Zugänge aktuell und braucht eine Rolle, die der Kunde versteht, und eine Person, die sie übernehmen will.	Ein benannter Administrator bei jedem Konto mit mehr als drei Kontakten; Ihr Innendienst setzt die Änderung um.
Wie werden Ausgaben freigegeben, die eine Unterschrift brauchen? Freigaberegeln in procurement, oder keine Regeln.	Freigaberegeln machen aus einem Warenkorb, der eine Unterschrift braucht, eine Bestellanforderung, über die die Freigeber des Kunden entscheiden, und setzen voraus, dass die Einkaufsrichtlinie des Kunden aufgeschrieben ist. Ohne Regeln läuft jede Bestellung durch, und das Portal kann Einkäufer, die eine Freigabe brauchen, nicht bedienen.	Freigaberegeln für die Konten, die danach fragen; keine für alle anderen.
Passwort-Login oder der Identity Provider des Kunden? Portal-Passwörter für alle, oder SSO, wo der Kunde eines hat.	Passwörter sind sofort verfügbar und erzeugen Reset-Anfragen. SSO beseitigt sie und verlangt, dass die IT des Kunden etwas konfiguriert.	Passwörter mit Self-Service-Reset als Standard, SSO für die größeren Kunden im Angebot.