B2B-Portale für Kunden und Vertriebspartner

Der Innendienst tippt jeden Morgen Bestellungen ab, die als Freitext in einer Mail stehen. Zwei Positionen sind falsch verstanden, eine Artikelnummer stammt aus einem Katalog, den es so nicht mehr gibt. Am Nachmittag ruft derselbe Kunde an und fragt, ob die Ware raus ist. Die Antwort steht im ERP. Der Kunde kommt dort nicht hinein.

Einzeln ist jeder dieser Vorgänge klein. In Summe binden sie Ihren Innendienst ans Telefon und begrenzen, wie viele Kunden ein Team überhaupt betreuen kann. Am häufigsten fällt die Entscheidung für ein Portal an einem dieser Punkte:

• Bestellungen erreichen Sie per Mail, Fax, Telefon und Webformular und werden alle von Hand im ERP erfasst.
• Ein Kunde fragt zum dritten Mal in dieser Woche nach dem Liefertermin einer Teillieferung.
• Die aktuelle Preisliste eines Großkunden existiert als Excel-Datei, die zuletzt der Außendienst gepflegt hat.
• Rechnungen und Lieferscheine werden einzeln nachgeschickt, weil der Kunde sie in seiner Buchhaltung nicht wiederfindet.
• Reklamationen laufen über eine Sammel-Mailadresse ohne Bezug zur Lieferscheinposition.
• Ein größerer Kunde verlangt eine elektronische Bestellanbindung, und Sie haben dafür heute keine Antwort.

Entscheidend ist dabei die Anbindung an Ihr ERP. Ein Portal hilft erst, wenn es dieselben Daten zeigt, die Ihr Innendienst am Telefon vorliest: Bestand, Termin, Preis, Beleg. Alles andere ist Oberfläche.

Der Funktionsumfang entscheidet, ob Ihre Kunden das Portal wirklich benutzen oder nach zwei Wochen wieder anrufen. Die folgenden Bereiche decken den Alltag im Kundenkontakt ab.

Bestellung und Wiederbestellung

Die Suche findet Artikel über Ihre Artikelnummer und über die Nummer, die der Kunde intern vergeben hat. Wiederbestellungen entstehen aus der Historie, aus einer gespeicherten Bestellvorlage oder aus einem CSV-Upload, wenn der Einkauf eine Liste aus seinem eigenen System zieht. Verpackungseinheiten, Mindestabnahmen und Staffelsprünge gehören in die Eingabemaske, sonst korrigiert der Innendienst weiterhin von Hand. Die Bestellnummer des Kunden wandert als Feld mit in den Auftrag, damit die spätere Rechnungsprüfung funktioniert.

Preise und Konditionen je Kunde

Angemeldete Nutzer sehen ausschließlich die Konditionen, die für ihre Kundennummer gelten, inklusive Staffeln, befristeten Aktionen und Kundensortimenten. Wer nicht angemeldet ist, sieht keine Preise. Dieser Punkt ist der häufigste Grund, warum ein Standardshop im B2B nicht trägt, und bekommt weiter unten einen eigenen Abschnitt.

Lieferstände und Termine

Der Kunde sieht pro Auftrag den Status, offene und bereits gelieferte Positionen, den avisierten Termin und die Sendungsnummer des Versanddienstleisters. Bei Teillieferungen zeigt die Ansicht, was noch aussteht. Genau diese Auskunft ersetzt die meisten Anrufe.

Belege

Auftragsbestätigungen, Lieferscheine und Rechnungen liegen im Portal zum Abruf bereit, filterbar nach Zeitraum, Bestellnummer und Lieferadresse. Rechnungen können zusätzlich im strukturierten E-Rechnungsformat bereitstehen, damit die Buchhaltung Ihres Kunden sie ohne Abtippen einlesen kann.

Reklamationen

Eine Reklamation startet an der Position eines konkreten Lieferscheins, mit Menge, Grund und Foto. Damit fehlt in der Bearbeitung nichts mehr, und der Kunde kann den Bearbeitungsstand selbst nachsehen, statt nachzufragen.

Ein B2B-Portal ist in erster Linie eine Frage der ERP-Anbindung. Die Oberfläche ist der kleinere Teil der Arbeit. Klären Sie früh, welche Daten in welche Richtung fließen und wie aktuell sie sein müssen.

Hat Ihr ERP eine dokumentierte REST- oder SOAP-Schnittstelle, ist das der direkte Weg. Ältere Systeme bieten oft nur Datenbanksichten, Dateiexporte oder eine proprietäre Middleware. Auch damit lässt sich arbeiten. Der Unterschied liegt im Aufwand und in der Aktualität: Ein nächtlicher Export trägt Artikelstamm und Belege, für Bestände und Preise ist er zu träge.

Die Stammdatenqualität entscheidet über den Erfolg des Portals. Was im ERP unvollständig oder widersprüchlich ist, wird im Portal für Ihre Kunden sichtbar.

• Schnittstellen zu ERP, CRM und Warenwirtschaft
• Software für Handel und Hersteller
• Altsysteme ablösen

Standardshops kennen üblicherweise einen Listenpreis und darauf einen Rabatt pro Kundengruppe. Ein gewachsenes ERP kennt Preislisten pro Kunde, Konditionen pro Artikelgruppe, Mengenstaffeln, befristete Sonderpreise, Aktionsartikel, abweichende Preise je Lieferwerk und Regeln, in welcher Reihenfolge das alles greift. Diese Preisfindung ist über Jahre entstanden und beschreibt Ihre Vertriebsrealität.

Wer diese Logik im Shopsystem nachbaut, pflegt sie ab dann zweimal. Nach der ersten Konditionsänderung, die nur im ERP landet, verlieren Ihre Kunden das Vertrauen in die angezeigten Preise. Zwei Wege tragen in der Praxis.

• Abruf zur Laufzeit: Das Portal fragt den Preis für Kunde, Artikel und Menge beim ERP an. Der Preis stimmt immer. Voraussetzung ist eine Schnittstelle, die schnell genug antwortet, und ein kurzlebiger Zwischenspeicher für Listenansichten.
• Regelmäßige Übernahme: Das ERP liefert die gültigen Konditionssätze in das Portal, dort werden sie ausgewertet. Das entlastet das ERP und funktioniert auch, wenn es nachts im Batch arbeitet. Der Preis kann kurzzeitig veralten.

In beiden Fällen gilt dieselbe Regel: Verbindlich ist der Preis, den das ERP bei der Auftragsanlage zurückgibt. Das Portal zeigt an, das ERP entscheidet. Weicht der bestätigte Preis vom angezeigten ab, sieht der Kunde das vor dem Absenden und nicht erst auf der Rechnung.

Im B2B bestellt selten eine einzelne Person für sich. Ein Portal, das nur einen Login pro Kunde kennt, führt dazu, dass drei Leute dasselbe Passwort benutzen. Damit ist nicht mehr nachvollziehbar, wer was ausgelöst hat.

• Einkäufer legt Warenkörbe an, bestellt bis zu einer Wertgrenze selbst und darüber hinaus zur Freigabe.
• Freigeber sieht die vorgelegten Warenkörbe, gibt frei, kürzt oder lehnt ab, mit Kommentar und Protokoll.
• Standortverantwortlicher bestellt für seine Lieferadresse und sieht nur deren Vorgänge und Belege.
• Buchhaltung sieht Rechnungen und Zahlungsstatus, aber keine Bestellfunktion.
• Außendienst arbeitet im Namen eines Kunden, sieht dessen Konditionen und legt Bestellungen beim Termin direkt an. Jeder Vorgang bleibt als vom Außendienst erfasst gekennzeichnet.

Freigabegrenzen, Kostenstellen und Budgets gehören zur Organisation Ihres Kunden. Deshalb sollte ein Kundenadministrator seine eigenen Nutzer anlegen und Grenzen setzen können, ohne dass Ihr Innendienst dafür Tickets bearbeitet. Diese Selbstverwaltung ist der eigentliche Kern eines Self-Service-Portals.

Technisch hängt daran die Mandantentrennung. Jeder Datensatz muss einer Kundennummer zugeordnet sein, und jede Abfrage muss diese Zuordnung prüfen, nicht nur die Oberfläche. In der Plattform für mexxenergie haben wir dieselbe Trennung über vier Fachmodule hinweg durchgezogen, von den Zählerständen bis zur Kostenauswertung. Der Aufwand steckt in der Konsequenz, nicht in der Idee.

• Kundenportal-Software

Headless Commerce bedeutet, dass Oberfläche und Geschäftslogik getrennt sind und über eine API miteinander sprechen. Für ein B2B-Portal wird das relevant, sobald dieselben Daten an mehreren Stellen gebraucht werden: im Portal, in einer Außendienst-App mit Offline-Fähigkeit, in einem Konfigurator oder in der Bestellanbindung eines Großkunden, der über EDI oder eine eigene API einkauft.

Bei Yido Performance hängen ein 3D-Konfigurator mit 152 Felgen, die Warenwirtschaft, der Onlineshop und eine automatisierte Datenpipeline für Gutachten an derselben Basis. Bei Glanz K laufen vier Systeme auf einem Backend. In beiden Fällen trägt die Trennung, weil mehr als eine Oberfläche denselben Artikelstamm und dieselben Bestände braucht.

Der Ansatz kostet zu Beginn mehr, weil zwei Teile gebaut und versioniert werden. Wenn absehbar nur ein Kanal existiert, ist eine klassische Anwendung der ruhigere Weg: weniger Teile, weniger Abstimmung, schnellerer erster Stand. Welcher Fall bei Ihnen vorliegt, entscheidet sich an der Zahl Ihrer Kanäle, und das lässt sich im ersten Gespräch beantworten.

Unabhängig von der Architektur läuft das Portal in Deutschland oder der EU. Der Quellcode gehört Ihnen ab dem ersten Commit, samt Repository und Deployment-Beschreibung. Sie können damit später zu einem anderen Dienstleister gehen, ohne das System neu zu bauen.

• Projekt Yido Performance
• Projekt Glanz K

Ein Teil der Anfragen zu diesem Thema endet ohne Eigenentwicklung. Ein etabliertes Shopsystem mit B2B-Erweiterung deckt Ihren Bedarf, wenn die folgenden Punkte weitgehend zutreffen:

• Ihre Preise lassen sich über eine überschaubare Zahl von Kundengruppen und Staffeln abbilden.
• Es gibt keine mehrstufigen Freigabeprozesse auf Kundenseite.
• Ihr ERP bringt einen fertigen Konnektor für das Shopsystem mit, den der Hersteller pflegt.
• Das Sortiment ist ohne Varianten- oder Konfigurationslogik beschreibbar.
• Sie verkaufen zusätzlich an Endkunden und wollen beides in einem System halten.

Dann bekommen Sie von uns den Namen eines Standardprodukts, auch wenn Sie mit der Frage nach einer Individualentwicklung gekommen sind. Eigenentwicklung trägt dort, wo Ihre Preisfindung oder Ihre Freigabewege von der Norm abweichen und genau darin Ihr Vertriebsvorteil liegt. Ein Standardsystem zwingt Sie an diesen Stellen zu Kompromissen, die sich später in Handarbeit im Innendienst rächen.

• Individualsoftware oder Standardsoftware
• Onlineshop mit Warenwirtschaftsanbindung

Ein Portal wird nicht an einem Stichtag für alle Kunden freigeschaltet. Sinnvoller ist ein Start mit einer Handvoll Kunden, die viel und regelmäßig bestellen. Deren Rückmeldungen zeigen innerhalb weniger Wochen, welche Felder fehlen, welche Suche nicht findet und an welcher Stelle der Einkauf doch wieder zum Telefon greift.

Vor dem Start steht der Abgleich der Daten. Bei der Migration der Altbestände für mexxenergie ist die Umstellung im laufenden Betrieb gelaufen, mit Abgleichszahlen vor und nach jedem Lauf, sodass jederzeit nachweisbar war, welche Datensätze angekommen sind. Für Kundenstamm, Preise und offene Aufträge in einem Portalprojekt gilt derselbe Maßstab: gezählt wird vorher und nachher.

• Zugänge werden pro Kundenorganisation eingerichtet, ein Administrator auf Kundenseite legt die weiteren Nutzer selbst an.
• Der Innendienst bekommt die Portalansicht seiner Kunden, damit er am Telefon dasselbe sieht wie der Anrufer.
• Alte Kanäle bleiben zunächst offen. Sie schließen sie erst, wenn die Zahl der Portalbestellungen das trägt.
• Nach dem Go-live wird gemessen, welche Anfragen weiterhin telefonisch kommen. Das ist die Liste für den nächsten Ausbauschritt.

Der Preis eines Portals hängt fast vollständig an der Integrationstiefe. Ein Portal mit Bestellung, Belegen und Lieferstatus auf einem ERP mit offener Schnittstelle liegt am unteren Rand. Mehrstufige Freigaben, Preisfindung zur Laufzeit, ein Altsystem ohne API und eine Datenmigration schieben es nach oben.

Das Projekt läuft in Abschnitten mit eigenem Festpreis. Der erste Abschnitt klärt die Schnittstellen und liefert eine lauffähige Anbindung an Ihr ERP, bevor Sie über den vollen Umfang entscheiden. Sie sehen damit früh, ob Ihre Datenlage trägt, und können an dieser Stelle noch abbrechen.

• Ablauf und Kosten
• Festpreis oder Aufwand

Brauchen wir dafür ein neues ERP?

Nein. Das Portal setzt auf das auf, was Sie haben. Entscheidend ist, wie Daten aus dem System herauskommen und Bestellungen hineingelangen. Wenn keine dokumentierte Schnittstelle existiert, prüfen wir Datenbanksichten, Exportdateien oder vorhandene Middleware. Ein ERP-Wechsel parallel zum Portalprojekt macht beide Vorhaben schwerer und ist selten nötig.

Unser ERP ist alt und hat keine API. Geht das trotzdem?

In den meisten Fällen ja. Der Weg führt über eine Zwischenschicht, die aus dem, was verfügbar ist, eine saubere Schnittstelle macht. Das kostet Aufwand und begrenzt die Aktualität mancher Daten. Nach der Analyse bekommen Sie eine Liste, welche Funktionen damit realistisch sind und welche erst nach einer Modernisierung im Altsystem funktionieren.

Können unsere kundenspezifischen Preise wirklich abgebildet werden?

Ja, wenn das ERP sie berechnen kann. Der verlässliche Weg ist, die Preisfindung im ERP zu belassen und sie vom Portal abzufragen. Ein Nachbau im Portal bedeutet doppelte Pflege. Verbindlich bleibt der Preis, den das ERP bei der Auftragsanlage zurückmeldet.

Was ist mit Kunden, die weiterhin per Mail bestellen wollen?

Die behalten Sie. Ein Portal ersetzt keinen Kanal per Anordnung. In der Praxis wandern Wiederbestellungen und Statusanfragen zuerst ab, weil sie im Portal schneller gehen. Beratungsintensive Aufträge bleiben beim Innendienst, und genau dort ist er wertvoll.

Kann der Außendienst im Namen eines Kunden bestellen?

Ja. Der Außendienst meldet sich mit eigenem Konto an, wählt den Kunden und sieht dessen Sortiment und Konditionen. Die Bestellung wird dem Kunden zugeordnet und trägt den Vermerk, wer sie erfasst hat. Für den Kundentermin lässt sich dieselbe Funktion als App mit eingeschränkter Offline-Fähigkeit bauen.

Muss ein B2B-Portal barrierefrei sein?

Die Anforderungen aus dem Barrierefreiheitsstärkungsgesetz richten sich auf Angebote an Verbraucher. Ein Portal, das ausschließlich Geschäftskunden zugänglich ist, fällt in der Regel nicht darunter. Sobald derselbe Shop auch Endkunden bedient, ändert sich die Lage: Den Shop von Glanz K haben wir aus diesem Grund nach WCAG 2.1 AA gebaut. Unabhängig von der Pflicht lohnen sich vollständige Tastaturbedienung und ausreichende Kontraste, weil im Einkauf viel mit der Tastatur gearbeitet wird.

Wie hängt das mit der E-Rechnungspflicht zusammen?

Im inländischen Geschäftsverkehr müssen Unternehmen elektronische Rechnungen in einem strukturierten Format empfangen können, die Pflicht zum Ausstellen greift gestaffelt später. Ein Portal ist ein guter Ort, um Rechnungen zusätzlich zum Versand als strukturierte Datei bereitzustellen. Erfüllt wird die Pflicht aber von Ihrem Rechnungsprozess, das Portal ist nur der Ausgabekanal.

Wem gehört der Code, und was passiert nach dem Go-live?

Der Quellcode gehört Ihnen ab Tag eins, samt Repository und Deployment-Beschreibung. Betrieben wird in Deutschland oder der EU. Nach dem Go-live bleibt derselbe benannte Ansprechpartner zuständig, der das Projekt begleitet hat. Entwickelt wird von festangestellten Entwicklern, ohne Weiterreichen an wechselnde Freelancer. Wartung, Weiterentwicklung und Erreichbarkeit stehen schriftlich fest, bevor das Portal live geht.

• E-Rechnungspflicht
• Vertrauen und Sicherheit

Bringen Sie zum ersten Gespräch mit, welches ERP Sie einsetzen, wie Ihre Preisfindung im Groben funktioniert und über welche Kanäle Bestellungen heute hereinkommen. Damit lässt sich in einem Termin einschätzen, welcher Funktionsumfang zuerst trägt und wo die Integration Arbeit macht. Wenn sich dabei zeigt, dass ein Standardprodukt reicht, sagen wir Ihnen das im selben Termin.

• Projekt Yido Performance
• Produktkonfigurator
• Software für Handel und Hersteller