Wer ein Kundenportal entwickeln möchte, sollte nicht mit einer Funktionsliste beginnen. Der erste Schritt ist die Frage: Welche wiederkehrende Aufgabe soll für Kunden und Mitarbeitende einfacher, schneller oder verlässlicher werden?
Ein B2B-Kundenportal kann Dokumente bereitstellen, Bestellungen zeigen, Servicefälle koordinieren oder Daten zur Selbstpflege anbieten. Es wird aber nur genutzt, wenn es einen konkreten Arbeitsweg verbessert und die Informationen vollständig und aktuell sind.
1. Den Prozess vor den Funktionen beschreiben
Formuliere zuerst zwei Abläufe: den heutigen und den gewünschten. Für jeden Schritt sollten Eingang, Handlung, Ergebnis und Verantwortung feststehen.
Beispiel für einen Servicefall:
| Schritt | Eingang | Handlung | Ergebnis | Verantwortlich |
|---|---|---|---|---|
| Fall anlegen | Kundennummer, Anliegen | Daten prüfen | Vorgangs-ID | Portal |
| Einordnen | Vorgang | Kategorie und Priorität wählen | Zuständigkeit | Regeln/Service |
| Bearbeiten | Aufgabe | Rückfrage oder Lösung | neuer Status | Mitarbeitende |
| Abschließen | gelöster Fall | Ergebnis bestätigen | Dokumentation | Kunde/Service |
Diese Sicht deckt Lücken auf, die eine reine Liste wie „Login, Dashboard, Upload“ verdeckt. Insbesondere wird sichtbar, wo weiterhin eine menschliche Entscheidung nötig ist.
2. Nutzergruppen und Rollen trennen
„Der Kunde“ ist selten eine einzige Rolle. Ein Unternehmen kann mehrere Standorte, Abteilungen und externe Partner haben. Intern greifen Support, Vertrieb, Buchhaltung und Administration auf unterschiedliche Daten zu.
Eine Rollenmatrix sollte mindestens klären:
- Wer darf ein Unternehmen und weitere Nutzer anlegen?
- Wer sieht alle Vorgänge eines Standorts?
- Wer darf Dokumente hochladen, freigeben oder löschen?
- Wer kann Bestellungen auslösen oder verändern?
- Welche Rolle darf sensible Vertrags- oder Abrechnungsdaten sehen?
- Was geschieht bei Rollenwechsel, Austritt oder gesperrtem Konto?
Das OWASP Application Security Verification Standard bietet eine Grundlage, um technische Sicherheitsanforderungen an Webanwendungen prüfbar zu formulieren. Besonders bei Portalen sollten Berechtigungen nicht nur in der Oberfläche, sondern auf der vertrauenswürdigen Serverseite durchgesetzt und getestet werden.
3. Einen fachlichen MVP festlegen
Ein Minimum Viable Product ist nicht die billigste Sammlung halbfertiger Funktionen. Es ist der kleinste vollständige Ablauf, der echten Nutzen erzeugt.
Für ein Dokumentenportal könnte der MVP enthalten:
- sichere Einladung und Anmeldung;
- eindeutige Unternehmens- und Rollenzuordnung;
- vollständige Liste freigegebener Dokumente;
- verständliche Suche und Filterung;
- Download mit protokollierter Berechtigung;
- sichtbarer Ansprechpartner bei Problemen;
- Admin-Prozess für Freigabe und Entzug.
Benachrichtigungen, Favoriten oder detaillierte Dashboards können später folgen. Fehlt dagegen die verlässliche Rechteprüfung, ist der Kern nicht fertig.
4. Die führenden Datenquellen bestimmen
Für jedes Datenobjekt braucht es genau eine führende Quelle. Das Portal zeigt Informationen an, ist aber nicht automatisch das System, in dem diese Informationen gepflegt werden.
| Datenobjekt | Mögliche führende Quelle | Zu klärende Frage |
|---|---|---|
| Kundenstamm | CRM oder ERP | Wie werden Änderungen synchronisiert? |
| Verträge | Vertrags-/DMS-System | Welche Version ist freigegeben? |
| Bestellungen | ERP oder Shop | Wie aktuell muss der Status sein? |
| Servicefälle | Ticketsystem | Welche Kommentare sind extern sichtbar? |
| Nutzer und Rollen | Identity-System/Portal | Wer genehmigt Zugriffe? |
Unklare Datenhoheit führt zu widersprüchlichen Ständen und manuellen Korrekturen. Deshalb gehören Feldzuordnung, Synchronisationsrichtung, Aktualitätsanforderung und Konfliktregel in die Spezifikation.
5. Schnittstellen und Fehlerwege planen
Eine API-Verbindung funktioniert nicht immer. Systeme sind zeitweise nicht erreichbar, Datenformate ändern sich oder ein Datensatz verletzt eine neue Regel. Das Portal braucht deshalb definierte Reaktionen:
- kontrollierte Wiederholungsversuche;
- Schutz vor doppelten Vorgängen;
- verständliche Meldung für Nutzer;
- Protokoll mit eindeutiger Vorgangs-ID;
- Benachrichtigung an eine verantwortliche Stelle;
- manuelle Wiederaufnahme ohne Datenverlust.
„Es ist ein Fehler aufgetreten“ reicht nicht, wenn ein Kunde nicht weiß, ob seine Bestellung oder Meldung angekommen ist.
6. Anmeldung und Kontoverwaltung vollständig denken
Der Login ist nur ein Teil des Lebenszyklus. Zur Planung gehören auch:
- Einladung und erstmalige Aktivierung;
- sichere Anmeldung und gegebenenfalls Mehrfaktor-Authentifizierung;
- Passwort- oder Zugangswiederherstellung;
- Sitzungsdauer und Abmeldung;
- Wechsel zwischen mehreren Unternehmen oder Standorten;
- Sperrung und Löschung;
- Supportprozess bei verlorenem Zugang;
- Protokollierung administrativer Änderungen.
Barrierefreiheit ist auch bei der Authentifizierung relevant. Die WCAG 2.2 des W3C ergänzt unter anderem Anforderungen an zugängliche Authentifizierung, konsistente Hilfe und die Vermeidung unnötiger Mehrfacheingaben.
7. Datenschutz und Aufbewahrung klären
Kundenportale verarbeiten oft personenbezogene und vertrauliche geschäftliche Daten. Die konkrete rechtliche Bewertung gehört in fachkundige Hände. Für die technische Planung sollten zumindest folgende Fragen beantwortet sein:
- Welche Daten werden für welchen Zweck verarbeitet?
- Welche Rollen benötigen tatsächlich Zugriff?
- Wie lange bleiben Dokumente, Protokolle und inaktive Konten erhalten?
- Wie werden Auskunft, Berichtigung und Löschung unterstützt?
- Welche Dienstleister und Hosting-Standorte sind beteiligt?
- Welche Inhalte dürfen in Logs und Backups erscheinen?
- Wie werden Testdaten anonymisiert oder synthetisch erzeugt?
Datensparsamkeit hilft nicht nur rechtlich. Weniger unnötige Daten bedeuten weniger Abhängigkeiten, geringere Angriffsfläche und verständlichere Prozesse.
8. Erfolg nicht an Registrierungen messen
Ein Portal ist wirtschaftlich sinnvoll, wenn es Aufgaben besser erledigt. Gute Kennzahlen hängen deshalb vom Zielprozess ab:
- Anteil vollständig digital abgeschlossener Vorgänge;
- Bearbeitungszeit vom Start bis zum Ergebnis;
- Rückfragen pro Vorgang;
- vermiedene manuelle Übertragungen;
- Fehler- und Abbruchquote;
- aktive Nutzung durch berechtigte Kunden;
- Supportaufwand für Zugang und Bedienung;
- Zufriedenheit nach einer konkreten Aufgabe.
Viele registrierte Konten können wertlos sein, wenn Kunden weiterhin anrufen, weil Daten fehlen oder der Ablauf unverständlich ist.
9. Realistische Projektphasen definieren
Phase 1: Discovery
Prozesse, Rollen, Datenquellen, Risiken und Erfolgskriterien werden gemeinsam geklärt. Das Ergebnis ist kein loses Workshop-Protokoll, sondern eine priorisierte Spezifikation.
Phase 2: Prototyp und technische Klärung
Kritische Nutzerwege werden testbar. Unsichere Integrationen und Berechtigungsmodelle werden früh validiert.
Phase 3: MVP-Entwicklung
Ein vollständiger Kernprozess wird mit Tests, Administration, Monitoring und Dokumentation umgesetzt.
Phase 4: Pilotbetrieb
Eine begrenzte Kundengruppe nutzt das Portal mit echten Fällen. Rückmeldungen, Fehler und Supportbedarf werden ausgewertet.
Phase 5: Ausbau und Betrieb
Weitere Prozesse folgen nach belegtem Nutzen. Updates, Sicherheitsprüfungen, Backups und Zuständigkeiten werden dauerhaft organisiert.
Die kompakte Anforderungscheckliste
Vor dem Entwicklungsstart sollten diese Punkte beantwortet sein:
- Ein konkreter Zielprozess ist vollständig beschrieben.
- Nutzergruppen und Rollen sind voneinander abgegrenzt.
- Der MVP bildet einen vollständigen Nutzenweg ab.
- Für jedes Datenobjekt gibt es eine führende Quelle.
- Schnittstellen und Fehlerwege sind dokumentiert.
- Anmeldung, Wiederherstellung und Sperrung sind geplant.
- Sicherheitsanforderungen sind prüfbar formuliert.
- Barrierefreiheit ist Teil von Design und Tests.
- Datenschutz und Aufbewahrung sind fachlich bewertet.
- Administration und Support haben klare Abläufe.
- Erfolg wird am Prozess, nicht nur an Nutzung gemessen.
- Betrieb, Monitoring und Weiterentwicklung sind zugeordnet.
Wer ein Kundenportal entwickeln lassen möchte, sollte diese Grundlagen vor der Schätzung klären. Dadurch wird aus einer groben Funktionsidee ein testbarer Projektumfang.
