Kundenportal

Technisch sitzt es als eigene Anwendung vor den bestehenden Systemen, meist vor dem ERP, und greift über Schnittstellen auf deren Daten zu.

Welches Problem ein Kundenportal löst

In vielen mittelständischen Unternehmen ist der Kundenservice im Kern eine Nachschlagetätigkeit. Die häufigsten Anfragen lauten: Wo ist meine Bestellung? Schick mir noch einmal die Rechnung von März. Wie war mein Rabatt? Welche Artikelnummer hatte das Ersatzteil von letztem Jahr? Jede dieser Anfragen kostet im Innendienst wenige Minuten, und fast jede ließe sich vom Kunden selbst beantworten, wenn er Zugang zu seinen eigenen Daten hätte.

Der Hebel liegt deshalb nicht in der Kommunikation, sondern im Zugang. Ein Portal, das die zehn häufigsten Fragen abdeckt, ersetzt in der Praxis einen großen Teil des Mailvolumens. Das ist der Grund, warum ein Kundenportal in B2B-Konstellationen mit wiederkehrenden Bestellungen und individuellen Konditionen fast immer das Projekt mit der kürzesten Amortisationszeit ist.

Die Rechnung, die ein Portal tragen muss

Eine belastbare Schätzung braucht drei Größen: Anzahl der Serviceanfragen pro Monat, durchschnittliche Bearbeitungszeit und der Anteil, der tatsächlich durch Self-Service ersetzbar ist. Ein Betrieb mit 800 Serviceanfragen im Monat, fünf Minuten pro Anfrage und einem ersetzbaren Anteil von 60 Prozent spart rund 40 Arbeitsstunden monatlich. Dazu kommen Effekte, die schwerer zu messen, aber real sind: weniger Rückfragen wegen falscher Artikelnummern, weniger Mahnungen, weil Rechnungen auffindbar sind, und ein messbarer Anteil an Wiederbestellungen, die nachts und am Wochenende entstehen.

Wichtig ist die Gegenrechnung. Ein Portal erzeugt dauerhaft Aufwand: Hosting, Updates, Support für Zugänge, Pflege der Inhalte. Wer die Einsparung nur gegen die Projektkosten rechnet und den Betrieb vergisst, rechnet sich das Projekt schöner, als es ist. Die ehrliche Betrachtung ist eine Rechnung über fünf Jahre, also über die Total Cost of Ownership.

Funktionsumfang: die zehn Dinge, die 80 Prozent ersetzen

• Login mit Rollen. Einkäufer, Buchhaltung und Techniker brauchen unterschiedliche Sichten auf dasselbe Kundenkonto.
• Bestellübersicht mit offenen und abgeschlossenen Vorgängen, suchbar und filterbar.
• Lieferstatus inklusive Tracking-Link des Dienstleisters.
• Rechnungsarchiv mit Download, idealerweise im Format der gesetzlichen E-Rechnung zusätzlich zum PDF.
• Stammdaten zur Selbstpflege: Lieferadressen, Ansprechpartner, Zahlungsdaten.
• Konditionen und Preislisten kundenindividuell, inklusive Staffelpreisen.
• Wiederbestellung aus der Historie, in B2B der am stärksten genutzte Button.
• Retouren und Reklamationen als geführtes Formular statt als Freitextmail.
• Dokumente wie Datenblätter, Zertifikate und Zeichnungen, auf das Kundenkonto bezogen.
• Serviceanfragen mit Status, damit der Kunde nicht nachfragen muss, ob die Anfrage angekommen ist.

Alles darüber hinaus ist Ausbaustufe zwei. Der häufigste Projektfehler ist nicht ein zu schmaler, sondern ein zu breiter erster Wurf: Angebotskonfiguration, Chat, Dashboards und Kundenbewertungen im ersten Release verlängern die Laufzeit und verschieben den Nutzen nach hinten.

Architektur: Portal vor System, nicht Portal im System

Technisch ist ein Kundenportal eine eigenständige Webanwendung, die über Schnittstellen auf die führenden Systeme zugreift. Die Daten bleiben dort, wo sie hingehören: Aufträge im ERP, Dokumente im Dokumentenmanagement, Artikeldaten im Produktdatenmanagement. Das Portal hält möglichst keine eigene Wahrheit, sondern liest und schreibt über eine API.

Die drei Entscheidungen, die die Kosten bestimmen

1. Schnittstelle zum ERP. Bringt das ERP eine dokumentierte REST- oder GraphQL-Schnittstelle mit, ist das Portal ein überschaubares Projekt. Muss die Schnittstelle erst gebaut werden, etwa über eine Middleware oder einen nächtlichen Datenabgleich, verdoppelt sich der Aufwand leicht. Diese Frage gehört an den Anfang, nicht in die Umsetzungsphase.
2. Identität und Zugänge. Eigene Benutzerverwaltung oder ein bestehender Identitätsanbieter? Für B2B-Portale mit Firmenkunden lohnt ein Anbieter mit Rollen- und Mandantenkonzept, weil Einkäuferwechsel und Berechtigungen sonst im Support landen. Ein Single Sign-on ist bei größeren Kunden ein echtes Verkaufsargument.
3. Echtzeit oder Abgleich. Bestände und Preise in Echtzeit aus dem ERP zu lesen ist sauber, belastet aber das System. Ein Abgleich im Minutentakt ist meist ausreichend und deutlich robuster. Diese Entscheidung sollte man bewusst treffen und dokumentieren, nicht dem Zufall der Implementierung überlassen.

Datenschutz und Sicherheit

Ein Kundenportal verarbeitet personenbezogene Daten und ist von außen erreichbar. Daraus folgen drei Pflichten, die nicht verhandelbar sind: ein Berechtigungskonzept, das sicherstellt, dass ein Nutzer ausschließlich Daten des eigenen Kundenkontos sieht; eine Protokollierung von Zugriffen und Änderungen; und ein Auftragsverarbeitungsvertrag mit jedem Dienstleister, der Zugriff hat, inklusive Hoster. Der häufigste schwere Fehler in der Praxis ist die unsichere direkte Objektreferenz: Eine Rechnungs-URL mit einer hochzählenden Nummer, die ohne Prüfung ausgeliefert wird, legt in Minuten das Rechnungsarchiv aller Kunden offen. Ein Portal gehört deshalb vor dem Livegang einem Test unterzogen, der genau solche Zugriffe versucht.

Beispiel aus der Praxis

Ein technischer Händler mit rund 1.200 B2B-Kunden hatte einen Innendienst, der zwei Drittel seiner Zeit mit Statusauskünften und dem Nachsenden von Rechnungen verbrachte. Das Portal wurde in der ersten Stufe auf fünf Funktionen begrenzt: Bestellübersicht, Lieferstatus, Rechnungsdownload, Wiederbestellung und Stammdatenpflege. Angebunden wurde das bestehende ERP über eine REST-Schnittstelle, Preise und Bestände im Fünf-Minuten-Abgleich. Die Laufzeit lag bei zehn Wochen bis zum Livegang mit einer Pilotgruppe von 40 Kunden, danach eine Woche Nachschärfen und dann der Rollout.

Zwei Beobachtungen aus solchen Projekten sind übertragbar. Erstens: Die Wiederbestellung aus der Historie ist fast immer die am stärksten genutzte Funktion und wird im Anforderungsgespräch regelmäßig unterschätzt. Zweitens: Die Nutzung steigt nicht von selbst. Ohne eine aktive Einführung, also eine Mail an die Kunden, einen Hinweis auf jeder Rechnung und einen Innendienst, der bei Anfragen auf das Portal verweist, bleibt die Quote niedrig und die Mails kommen weiter.

Wirtschaftliche Einordnung und Förderung

Ein schlankes B2B-Kundenportal auf Basis einer bestehenden ERP-Schnittstelle liegt in der Umsetzung typischerweise bei einer Laufzeit von acht bis sechzehn Wochen. Der Aufwand verteilt sich erfahrungsgemäß ungleich: Ein knappes Drittel geht in die Anbindung der führenden Systeme, ein weiteres in Berechtigungen und Identität, und nur der Rest in die Oberfläche, die der Kunde am Ende sieht. Wer die Kostenschätzung an der Oberfläche festmacht, unterschätzt das Projekt systematisch.

Für die Finanzierung solcher Vorhaben ist in Deutschland weniger der klassische Zuschuss das Instrument als der Förderkredit. Der ERP-Förderkredit Digitalisierung der KfW finanziert bis zu 100 Prozent der förderfähigen Kosten, mit Laufzeiten von fünf bis zehn Jahren und bis zu zwei tilgungsfreien Anlaufjahren. In den höheren Förderstufen kommt ein nicht zurückzuzahlender Zuschuss hinzu. Beantragt wird über die Hausbank, und zwar vor Vorhabensbeginn. Daneben existieren Länderprogramme, deren Bedingungen sich häufig ändern; die aktuelle Lage gehört vor jedem Antrag geprüft.

Betrieb: was nach dem Livegang kommt

Ein Portal ist kein Projekt mit Endtermin, sondern ein Produkt. Nach dem Livegang entstehen vier laufende Aufgaben. Erstens der Support für Zugänge: Einkäuferwechsel, vergessene Passwörter, neue Standorte eines Kunden. Zweitens die Pflege der Inhalte, insbesondere der Dokumente und Datenblätter, die schnell veralten. Drittens Sicherheitsupdates für Framework und Abhängigkeiten, die bei einer von außen erreichbaren Anwendung keine Option sind. Viertens die Weiterentwicklung auf Basis der Nutzung.

Für den vierten Punkt lohnt es, von Anfang an zu messen, welche Funktionen tatsächlich genutzt werden, und zwar anonymisiert und einwilligungskonform. Die Praxis zeigt regelmäßig, dass eine mühsam gebaute Funktion kaum genutzt wird, während eine Nebenfunktion zum Haupteinstieg geworden ist. Diese Information ist die Grundlage der zweiten Ausbaustufe und ersetzt die Diskussion darüber, was Kunden wollen könnten, durch die Beobachtung, was sie tun.

Ein letzter Punkt zur Erwartungshaltung: Ein Kundenportal senkt Anfragen, es beseitigt sie nicht. Komplexe Fälle, Verhandlungen und Beschwerden landen weiter beim Menschen, und das ist richtig. Der Gewinn liegt darin, dass die Routine wegfällt und die Zeit für genau diese Fälle frei wird.

Abgrenzung: Portal, Shop, Extranet

Ein Onlineshop dient dem Verkauf an potenziell unbekannte Käufer, ein Kundenportal dem Self-Service bestehender Kunden mit individuellen Konditionen. In der Praxis verschwimmt die Grenze, weil moderne Shopsysteme B2B-Funktionen wie Kundenpreise, Budgets und Freigabeworkflows mitbringen und damit ein Portal mit abdecken können. Das ist oft die wirtschaftlichere Variante, wenn ohnehin ein Shop betrieben wird. Ein Extranet ist der ältere Begriff für einen geschützten Partnerbereich, meist dokumentenlastig und ohne Transaktionen. Wer heute ein Extranet betreibt und über ein Portal nachdenkt, prüft zuerst, ob der bestehende Bereich erweitert werden kann.

Wann sich ein Kundenportal nicht lohnt

Drei Konstellationen sprechen gegen das Projekt, jedenfalls als erstes Vorhaben. Erstens eine kleine Kundenzahl mit sehr individuellen Vorgängen: Bei dreißig Großkunden, die ohnehin persönlich betreut werden, ersetzt ein Portal keine Arbeit, sondern erzeugt eine zusätzliche Oberfläche, die niemand nutzt. Zweitens ein Geschäft ohne wiederkehrende Transaktionen: Wer einmalige Projekte verkauft, hat keine Bestellhistorie, aus der ein Kunde etwas ziehen könnte. Drittens eine Datenlage, die den Blick von außen nicht erlaubt: Wenn Preise und Konditionen nicht im System, sondern in Köpfen und Excel-Dateien liegen, ist die Bereinigung das eigentliche Projekt, und das Portal kommt danach.

In diesen Fällen bringt häufig ein anderes Vorhaben mehr, etwa die automatisierte Angebotserstellung oder die Ablösung der Papierablage durch ein Dokumentenmanagement. Die Reihenfolge entscheidet über den Erfolg, nicht die Technik.

Woran Portalprojekte scheitern

Drei Muster wiederholen sich. Das erste ist der zu große Umfang: Ein Portal, das alles können soll, geht nach achtzehn Monaten in Betrieb und löst Probleme, die inzwischen anders aussehen. Das zweite ist der ungeklärte Prozess: Wer den Auftragsprozess nicht vorher saubergezogen hat, baut die Unklarheit in Software nach und macht sie teurer. Das dritte ist die fehlende Datenqualität: Ein Portal legt Stammdaten offen, die intern jahrelang als Notiz im Freitextfeld lebten. Das ist unangenehm, aber heilsam, und es gehört vor den Livegang terminiert, nicht danach.

Die Gegenmaßnahme ist in allen drei Fällen dieselbe: einen schmalen Funktionsumfang festlegen, den zugrunde liegenden Prozess vorher beobachten und messen, und mit einer Pilotgruppe starten, bevor alle Kunden eingeladen werden.