Kundenportal entwickeln lassen: Rollen, Dokumente, Datenschutz und Einführung

Eine Kundin schreibt zum dritten Mal in dieser Woche, wie weit ihr Auftrag ist. Die Antwort steht irgendwo: im Postfach einer Kollegin, in einem Ordner auf dem Dateiserver, in einer Notiz nach einem Telefonat. Niemand ist nachlässig, aber niemand kann die Frage in dreißig Sekunden beantworten. Dieses Bild ist der häufigste Anlass, über ein Kundenportal nachzudenken.

Angenommen, es geht um ein Unternehmen mit etwa zwanzig Beschäftigten, das laufende Aufträge für gewerbliche Kunden abwickelt: Beratung, Planung, Betreuung, Abrechnung. Pro Kunde existieren Angebote, Verträge, Berichte, Rechnungen und viele kleine Abstimmungen. Die Dokumente wandern als Anhänge hin und her, manche vertrauliche Datei wird an einen größeren Verteiler geschickt, weil das schneller geht als die Suche nach dem richtigen Ansprechpartner.

Ein Portal ist die Antwort auf zwei Fragen zugleich: Wo liegt der aktuelle Stand, und wer darf ihn sehen? Es ist weniger ein Technikprojekt als eine Entscheidung darüber, wie Zusammenarbeit mit Kunden künftig aussehen soll. Die Software bildet diese Entscheidung nur ab. Wer das Projekt als reine Programmieraufgabe behandelt, liefert am Ende ein hübsches Login, das niemand benutzt.

Nützlich ist ein kleines Gedankenexperiment: Wenn morgen die Hauptansprechpartnerin eines Kunden fragt, welche Unterlagen aus dem letzten Quartal vorliegen, wie lange braucht Ihr Team für eine belastbare Antwort? Liegt sie bei Minuten, brauchen Sie vermutlich kein Portal. Liegt sie bei einem halben Tag und drei Rückfragen im Haus, haben Sie ein Strukturproblem, das mit mehr Disziplin allein nicht verschwindet, weil Disziplin bei zwanzig Personen und hunderten Vorgängen nicht skaliert.

Die technischen Risiken sind real, aber beherrschbar: Anmeldung, Rechte, Dateispeicher, Benachrichtigungen. Häufiger scheitern Portale an Menschen und Prozessen. Kunden registrieren sich einmal, vergessen das Passwort und schreiben danach wieder eine E-Mail. Mitarbeiter pflegen den Status nicht, weil er in der Praxis niemanden interessiert, bis er plötzlich falsch ist. Ein Portal mit veralteten Angaben ist schlimmer als gar keines.

Hinzu kommt das Vertrauensproblem. Sobald Kunden eigene Zugänge haben, darf nie ein Dokument beim falschen Kunden auftauchen. Ein einziger solcher Vorfall beschädigt die Beziehung nachhaltig und kann meldepflichtig sein. Diese Anforderung ist unscheinbar im Lastenheft und gewaltig in der Architektur, weil sie jede Abfrage, jede Datei und jede Benachrichtigung betrifft.

Ein dritter Punkt ist der Umfang. Wer einmal anfängt, sammelt Wünsche: Zeiterfassung einsehen, Angebote online annehmen, Rechnungen bezahlen, Chat, Kalender, Wissensdatenbank. Jeder Wunsch ist für sich vernünftig, zusammen ergeben sie ein Produkt, das ein Jahr dauert und dessen Nutzen erst am Ende sichtbar wird. Die eigentliche Herausforderung besteht darin, den ersten Nutzen früh zu liefern und den Rest an echter Nutzung auszurichten.

Ein typisches Fehlerbild zeigt sich nach wenigen Wochen: Der Status steht noch auf „in Bearbeitung“, obwohl der Auftrag längst wartet, weil der Kunde eine Unterlage schuldet. Der Kunde sieht den falschen Stand, ruft an und fühlt sich bestätigt, dass das Portal nichts bringt. Dagegen helfen Statuswechsel, die als Nebenprodukt der Arbeit entstehen, etwa beim Hochladen eines Berichts oder beim Anfordern einer Unterlage, statt als zusätzliche Pflegeaufgabe.

Bevor Funktionen festgelegt werden, lohnt ein nüchterner Blick auf die Anfragen der letzten Monate. Sortieren Sie eingegangene Kundenmails und Anrufe nach Anlass: Wo steht mein Auftrag, wo ist die Rechnung, welche Unterlagen fehlen noch, wer ist mein Ansprechpartner, kann ich etwas nachreichen. Meist verteilt sich ein großer Teil auf wenige wiederkehrende Fragen, und genau diese rechtfertigen ein Portal.

Aus dieser Auswertung entsteht eine Gewichtung der Funktionen, die sich von der Wunschliste deutlich unterscheiden kann. Dokumente und Status stehen oft ganz oben, weil sie täglich gebraucht werden. Nachrichten sind wichtig, aber sie konkurrieren mit der E-Mail, die jeder sowieso offen hat. Freigaben und Unterschriften bringen großen Nutzen, ziehen jedoch rechtliche Fragen nach sich und gehören eher in eine zweite Stufe.

Zugleich gilt es, die Seite der Mitarbeiter zu betrachten. Wer bearbeitet eingehende Portalnachrichten, wer lädt Dokumente hoch, wer hat Vertretung bei Urlaub? Ein Portal verschiebt Arbeit, es schafft sie nicht ab. Wenn die Einführung scheitert, liegt es häufig daran, dass diese Verschiebung nicht ehrlich besprochen wurde. Wir schlagen deshalb vor, beide Seiten gleichzeitig zu analysieren und die Prozesse vor der Software zu klären.

Ein eigenes Portal ist nicht automatisch richtig. Für viele Betriebe genügt eine fertige Lösung: ein Dokumentenraum eines etablierten Anbieters, ein Ticketsystem mit Kundenzugang oder die Portalfunktion einer bestehenden Branchensoftware. Sie sind schnell eingerichtet, werden vom Hersteller gepflegt und lösen Sicherheitsfragen, die man sonst selbst beantworten muss. Der Preis sind Kompromisse: fremde Begriffe, feste Abläufe, Lizenzkosten pro Nutzer und oft ein Erscheinungsbild, das nicht zur Marke passt.

Eine Zwischenlösung sind Baukästen und Low-Code-Plattformen. Sie erlauben eigene Oberflächen und Abläufe, binden aber an die Plattform, ihre Preisstruktur und ihre Grenzen bei Rechten und Datenmodell. Gerade die Mandantentrennung ist dort manchmal nur eingeschränkt steuerbar. Prüfen Sie vor der Entscheidung, wo die Daten liegen, ob sich Rechte pro Kunde und pro Rolle abbilden lassen und wie ein Wechsel aussähe.

Eigene Entwicklung lohnt sich dort, wo der Ablauf mit den Kunden Teil des Leistungsversprechens ist und Standardprodukte ihn verbiegen würden. Typisch sind Fachprozesse mit mehreren Beteiligten, besondere Rollen oder die Verknüpfung mit internen Systemen. Der Preis ist Verantwortung: Sie besitzen die Software und müssen sie betreiben und aktualisieren. Wir raten deshalb zu einem Start mit minimalem Umfang, der sich später erweitern lässt, statt zu einer vollständigen Plattform im ersten Anlauf.

Ein weiterer Gesichtspunkt ist die Abhängigkeit vom Anbieter. Bei einem Fremdprodukt liegen Ihre Kundendaten in dessen System, und ein Wechsel hängt davon ab, ob sich Dokumente und Verläufe vollständig exportieren lassen. Fragen Sie das vor Vertragsabschluss konkret ab, mit einem Testexport. Bei Eigenentwicklung kehrt sich das Problem um: Sie sind unabhängig vom Anbieter, aber abhängig von denen, die den Code verstehen. Dokumentation und ein klar geregelter Betrieb sind dann kein Beiwerk.

Die ehrliche Reihenfolge der Fragen lautet daher: Reicht ein Standardprodukt, wenn wir den Prozess leicht anpassen? Wenn nein, was genau fehlt? Erst die Antwort darauf rechtfertigt Eigenentwicklung, und sie legt zugleich fest, was das erste Release enthalten muss.

Im Zentrum steht die Frage, wer was sehen darf. Wir unterscheiden zwei Ebenen. Der Mandant ist das Kundenunternehmen, dessen Daten streng von allen anderen getrennt sind. Die Rolle beschreibt, was eine Person innerhalb ihres Mandanten tun darf. Beide Ebenen werden getrennt modelliert, weil sie sich unterschiedlich ändern: Neue Rollen kommen vor, neue Mandanten ständig.

Auf Kundenseite genügen meist wenige Rollen: ein Hauptansprechpartner, der Personen einladen und Rechte vergeben darf, Mitarbeiter mit Lesezugriff auf Aufträge und Dokumente, und gegebenenfalls eine Finanzrolle, die nur Rechnungen sieht. Auf Betreiberseite kommen Betreuer, die ihnen zugewiesene Kunden bearbeiten, und Administratoren hinzu. Je weniger Rollen, desto verständlicher bleibt die Pflege, und desto seltener entstehen Ausnahmen.

Berechtigungen sollten nicht an Personen, sondern an Rollen und Zuordnungen hängen. Verlässt ein Betreuer das Unternehmen, wird seine Zuordnung neu vergeben, ohne dass einzelne Dokumente angefasst werden. Entscheidend ist zudem, dass die Prüfung zentral im Backend erfolgt. Eine Schaltfläche auszublenden schützt nichts, solange die zugehörige Abfrage jedem angemeldeten Nutzer antwortet.

Zur Mandantentrennung gibt es mehrere Bauweisen. Alle Kunden in einer gemeinsamen Datenbank mit durchgängiger Mandantenkennung ist die schlankste Variante und für die meisten Dienstleister angemessen, verlangt aber Disziplin bei jeder Abfrage. Getrennte Schemata oder eigene Datenbanken pro Kunde isolieren stärker, kosten jedoch Betrieb und Aktualisierungsaufwand. Wir würden mit der gemeinsamen Datenbank beginnen und die Trennung zusätzlich auf Datenbankebene absichern, etwa durch zeilenbasierte Sicherheitsregeln, damit ein vergessener Filter im Code nicht genügt, um Daten zu vermischen.

Das Rechtekonzept gehört vor die Programmierung in eine Tabelle, die Fachleute lesen können: Zeilen sind Rollen, Spalten sind Aktionen wie ansehen, hochladen, löschen, einladen. Dieses einfache Dokument verhindert die meisten späteren Missverständnisse und dient später als Grundlage für Tests.

Bei der Anmeldung hat sich für Geschäftskunden die Einladung bewährt: Ein Betreuer lädt eine Person per E-Mail ein, sie legt selbst ein Passwort fest und bestätigt die Adresse. Eine offene Selbstregistrierung ist bequem, öffnet aber die Tür für Fremde. Eine zweite Bestätigung per Authenticator-App oder Einmalcode erhöht den Schutz deutlich, verlangt von Kunden aber etwas Geduld. Wir würden sie für sensible Dokumente vorsehen und anbieten, nicht erzwingen, wo der Aufwand nicht zum Schutzbedarf passt.

Dokumente gehören nicht in die Datenbank selbst, sondern in einen Objektspeicher, mit Metadaten in der Datenbank: Besitzer-Mandant, Auftrag, Version, Prüfsumme, Zeitpunkt. Abgerufen wird nur über kurzlebige, signierte Links, die erst nach der Rechteprüfung ausgestellt werden. So gibt es keine dauerhaft öffentliche Adresse, die weitergereicht werden kann. Beim Hochladen werden Dateityp und Größe geprüft, und bei Bedarf läuft eine Virenprüfung, bevor die Datei sichtbar wird.

Prüfen lässt sich das Zusammenspiel mit einem einfachen Test: Zwei Testkunden, jeweils mit eigenen Dokumenten und Nutzern, und ein Skript, das mit dem Zugang des einen systematisch Adressen des anderen aufruft. Jeder Treffer ist ein Fehler. Dieser Test sollte bei jeder Änderung automatisch laufen, nicht nur einmal vor dem Start, denn Trennung geht meist bei späteren Erweiterungen verloren.

Der Status eines Auftrags sollte nicht frei beschreibbar sein, sondern aus wenigen, klar benannten Stufen bestehen, zum Beispiel Eingang, in Bearbeitung, wartet auf Kunde, abgeschlossen. Der Wechsel erzeugt ein Ereignis. Aus diesem Ereignis speisen sich Verlauf, Benachrichtigung und Protokoll, sodass es nur eine Quelle gibt. Freier Text bleibt für Erläuterungen, damit die Stufen vergleichbar bleiben.

Benachrichtigungen sind die Stelle, an der Portale lästig werden. Eine Mail pro Ereignis führt dazu, dass Kunden sie stummschalten. Wir würden Ereignisse bündeln, nur bei echten Handlungsbedarfen sofort melden und in der Mail selbst keine vertraulichen Inhalte versenden, sondern nur den Hinweis und den Link ins Portal. Wer nach der Anmeldung die Sache sieht, hat auch die Rechte dazu.

Reale Kundenbeziehungen passen selten in ein sauberes Rollenschema. Ein Steuerberater des Kunden braucht für drei Wochen Zugriff auf einzelne Unterlagen, danach nicht mehr. Eine Mitarbeiterin des Kunden verlässt das Unternehmen, behält aber ihre Zugangsdaten. Ein Betreuer ist im Urlaub, und Anfragen bleiben liegen. Solche Fälle sollten im Konzept stehen, bevor sie auftreten, weil sie sonst als Notlösung mit Sonderrechten enden.

Für zeitlich begrenzte Zugriffe helfen Ablaufdaten auf Zuordnungen, sodass der Zugang von selbst endet. Für Ausscheidende hilft eine einfache Regel: Der Hauptansprechpartner des Kunden kann Zugänge sperren, und der Betreiber erinnert in regelmäßigen Abständen an eine Überprüfung der Nutzerliste. Konten werden deaktiviert statt gelöscht, damit Verlauf und Protokolle erhalten bleiben und Zuordnungen zu Dokumenten nicht ins Leere laufen.

Datenschutz stellt weitere Fragen. Kunden dürfen Auskunft verlangen, und nach Vertragsende stellt sich die Frage der Löschung, während gesetzliche Aufbewahrungsfristen für Rechnungen und Verträge Löschungen begrenzen können. Das Portal braucht deshalb Löschkonzepte pro Dokumentart, nicht pauschal. Welche Fristen für Sie gelten, klärt Ihre Datenschutzbeauftragte oder Ihr Rechtsbeistand. Die Software muss die Entscheidung dann technisch umsetzen können, etwa durch Sperrvermerke und fristgesteuerte Löschung.

Protokolle sind hier ein Werkzeug, aber auch eine Datenschutzfrage. Wer festhält, wer wann welches Dokument geöffnet hat, schafft Nachvollziehbarkeit und zugleich Daten über Personen. Wir halten das Protokoll deshalb knapp: ausreichend für Aufklärung bei Vorfällen, mit begrenzter Aufbewahrungszeit und klarem Zweck. Das ist eine Orientierung, keine Rechtsberatung. Die konkrete Ausgestaltung gehört mit Ihrer Datenschutzstelle abgestimmt.

Ein Portal soll Rückfragen reduzieren, Dokumente auffindbar machen und den Stand transparent halten. Ob das gelingt, lässt sich messen, und zwar im eigenen Betrieb statt an Branchenwerten. Bevor das Portal startet, sollten Sie festhalten, wie viele Statusanfragen per Mail und Telefon pro Woche eingehen und wie viel Zeit die Suche nach Dokumenten im Alltag kostet. Eine grobe Strichliste über vier Wochen reicht dafür aus.

Nach dem Start sind drei Größen aussagekräftig: der Anteil der aktiven Kunden, die sich innerhalb eines Monats anmelden, die Zahl der verbleibenden Statusanfragen außerhalb des Portals und die Zeit bis zur Beantwortung von Anfragen. Dazu kommt ein qualitatives Urteil der Betreuer, ob die Arbeit planbarer geworden ist. Ein Portal, das viele Registrierungen, aber wenige Rückkehrer hat, wird nicht angenommen, egal wie gut die Technik ist.

Versprechen lassen sich bestimmte Effekte nicht. Wie schnell Kunden das Angebot annehmen, hängt von deren Gewohnheiten, von Ansprechpartnern und von der Einführung ab. Eine Zeitersparnis stellt sich nur ein, wenn die alten Wege tatsächlich zurückgehen und das Team konsequent im Portal arbeitet. Wer parallel jede Anfrage auch per Mail beantwortet, hat doppelte Arbeit und kein Ergebnis.

Realistisch ist ein Zeitraum von mehreren Monaten, bis sich Gewohnheiten verschoben haben. Rechnen Sie in dieser Zeit mit Nacharbeit: Texte, die Kunden missverstehen, Rollen, die zu eng oder zu weit geschnitten waren, Benachrichtigungen, die zu häufig kommen. Das ist kein Scheitern, sondern der Normalfall einer Einführung, und das Konzept sollte Zeit für diese Anpassung vorsehen.

Der beste Weg, Kunden zu gewinnen, ist ein kleiner Kreis von Pilotkunden, die das Portal vor dem allgemeinen Start nutzen. Wählen Sie Kunden mit engem Kontakt und regelmäßigem Austausch, nicht die lautesten Kritiker. Deren Rückmeldungen zeigen die Hürden im echten Gebrauch: unverständliche Einladungs-Mails, ein Dokument, das nicht auffindbar ist, ein Status, dessen Wort anders verstanden wird als gemeint.

Danach hilft eine klare Linie bei der Umstellung. Neue Dokumente gehen ab einem Stichtag nur noch über das Portal, per Mail kommt höchstens ein Hinweis mit Link. Wenn Mitarbeiter bei Bedarf Ausnahmen machen, lernen Kunden schnell, dass die alte Gewohnheit weiterhin funktioniert. Freundlichkeit und Konsequenz schließen sich nicht aus, wenn das Portal wirklich einfacher ist als das, was es ersetzt.

Im Betrieb zählen die unscheinbaren Dinge: Sicherheitsupdates, Sicherungen mit geprüfter Wiederherstellung, Überwachung von Fehlern und Speicherplatz, ein Ansprechpartner für Kunden mit Anmeldeproblemen. Passwortrücksetzungen sind nach dem Start der häufigste Supportfall und sollten selbst bedienbar sein. Planen Sie außerdem einen festen Termin im Quartal, an dem Nutzerlisten, Rollen und Löschfristen überprüft werden.

Ein häufig unterschätzter Teil sind die Texte. Einladung, Fehlermeldung und Statusbezeichnung sprechen Menschen an, die das Portal nur gelegentlich öffnen. Begriffe aus dem internen Sprachgebrauch verwirren sie. Prüfen Sie Texte mit jemandem, der Ihre Abläufe nicht kennt, und halten Sie die Wege kurz: Ein Kunde, der nach der Einladung drei Minuten bis zum ersten Dokument braucht, kommt wieder, einer, der fünfzehn Minuten sucht, schreibt eine Mail.

Zuletzt gehört dazu, den Funktionsumfang bewusst wachsen zu lassen. Zeigt die Nutzung, dass Kunden vor allem Dokumente und Status brauchen, wäre ein Chat überflüssig. Fragen sie dagegen ständig nach Rechnungen, wandert die Rechnungsansicht nach vorn. Die Nutzungsdaten steuern den Fahrplan, nicht die ursprüngliche Wunschliste.

Ein Kundenportal lohnt sich, wenn dieselben Fragen und Dokumente immer wieder zwischen den gleichen Beteiligten wandern und Sie dafür eine verlässliche Adresse schaffen wollen. Es lohnt sich weniger, wenn nur das Gefühl besteht, ein Dienstleister müsse so etwas haben. Der Maßstab ist die Entlastung im Alltag, nicht der Eindruck von Modernität.

Technisch kommt es auf Sorgfalt an einer Stelle an: Mandantentrennung, Rechte und Protokolle gehören in die Grundlage. Organisatorisch kommt es auf die Einführung an, die Kunden mitnimmt und Mitarbeiter nicht allein lässt. Wer beides ernst nimmt, braucht für das erste Release erstaunlich wenig Funktionsumfang.

Aus dieser Betrachtung ergeben sich drei Grundsätze, die über das einzelne Projekt hinaus tragen. Erstens beginnt ein Portal mit den Anfragen der Kunden, nicht mit einer Funktionsliste. Zweitens ist ein Status nur so gut wie der Prozess, der ihn erzeugt. Drittens bleibt Vertrauen das eigentliche Kapital: Es entsteht durch korrekte Trennung, nachvollziehbare Protokolle und ein Betriebskonzept, das auch in zwei Jahren noch trägt.

Der nächste Schritt ist klein: Zählen Sie vier Wochen lang, welche Anfragen Ihrer Kunden wiederkehren, und schreiben Sie auf, wer in Ihrem Haus darauf antwortet. Wenn Sie uns dieses Bild schicken, schätzen wir ehrlich ein, ob ein Standardprodukt genügt oder ein eigenes Portal sinnvoll ist, und nennen einen Rahmen für Umfang und Aufwand, bevor Sie sich festlegen.