Kundenportal entwickeln: Funktionen, Daten und Integrationen planen

Der Anruf kommt immer zur gleichen Zeit: kurz vor Feierabend, kurz vor dem Wochenende, kurz vor einem Termin. „Wo steht mein Auftrag?” „Können Sie mir die Rechnung noch mal schicken?” Wenn diese Fragen nicht selten, sondern täglich mehrfach im Postfach oder am Telefon landen, ist das kein Kommunikationsproblem – es ist ein fehlendes Self-Service-Angebot. Ein Kundenportal löst genau das: einen Ort, an dem Kunden selbst nachsehen können, statt nachzufragen.

Dieser Artikel gehört zu unserer Übersicht KI-Softwareentwicklung, Tools und MVPs und beantwortet die Fragen, die vor dem ersten Klick auf „Projekt starten” geklärt sein sollten: welche Funktionen ein Portal wirklich braucht, wie du Rollen und Mandanten trennst, welche Systeme du anbindest, wie du Dokumente schützt und wie du klein startest, ohne dich zu verzetteln. Er richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die ein Kundenportal planen oder gerade beauftragen wollen.

Das Problem: Self-Service fehlt, also übernimmt der Mensch

Ohne Portal läuft jede Statusanfrage über einen Menschen – Vertrieb, Support oder Buchhaltung tippt in ein System, sucht die Information zusammen und schreibt zurück. Bei fünf Anfragen die Woche ist das Kulanz. Bei fünfzig ist es ein stiller Vollzeitjob, der nirgends im Organigramm steht. Drei Muster sehe ich dabei immer wieder:

• Die Anfrage ist unnötig. Die Information liegt längst in einem System – ERP, Ticket-Tool, Projektmanagement –, nur eben nicht dort, wo der Kunde hinschaut.
• Die Antwort dauert, weil ein Mensch dazwischen sitzt. Zwischen Frage und Antwort liegt oft nicht die Zeit, die Information zu finden, sondern die Zeit, bis überhaupt jemand dazu kommt.
• Dokumente wandern per E-Mail-Anhang. Rechnungen, Lieferscheine, Verträge werden auf Zuruf verschickt – ohne Protokoll, wer wann was bekommen hat, und ohne dass alte Anhänge je wieder gelöscht werden.

Ein Kundenportal verschiebt diese Arbeit von „auf Zuruf” zu „auf Abruf”: Der Kunde sieht selbst nach, wenn er will, und das Team wird nur noch bei echten Ausnahmen gebraucht. Das ist kein Nice-to-have für Konzerne – gerade in KMU mit knappem Backoffice ist der Hebel oft größer, weil eine einzelne Person heute mehrere Rollen gleichzeitig bedient.

Begriffe kurz geklärt

• Kundenportal: Ein passwortgeschützter Bereich, in dem externe Nutzer – Kunden, manchmal auch Partner oder Lieferanten – selbst auf für sie relevante Informationen und Dokumente zugreifen, ohne dass jemand aus deinem Team sie manuell zusammenstellt.
• Mandant: Eine Kundenorganisation oder Kundeneinheit, deren Daten strikt von denen anderer Mandanten getrennt bleiben müssen. Ein Portal mit mehreren Kunden ist fast immer ein Mehrmandanten-System, auch wenn dieses Wort im Projekt nie fällt.
• Rolle: Ein Bündel von Rechten, das definiert, was eine Nutzerin innerhalb ihres Mandanten sehen und tun darf – etwa „liest nur” gegenüber „lädt Dokumente hoch und bestätigt Bestellungen”.
• Self-Service-Funktion: Jede Funktion, die eine Anfrage überflüssig macht, weil der Kunde die Antwort selbst findet – Status, Download, einfache Formulare.

Abgrenzung: Ein Kundenportal ist kein CRM und kein Ticketsystem – es ist die nach außen gerichtete, stark vereinfachte Sicht auf Ausschnitte dieser Systeme. Es ersetzt sie nicht, es spricht mit ihnen.

Welche Funktionen braucht ein Portal?

Die Versuchung bei jedem Portal-Projekt ist dieselbe: eine Wunschliste, die von Rechnungsanzeige bis Online-Zahlung, Chat, Umfragen und persönlichem Dashboard reicht. Das ist der sicherste Weg zu einem Projekt, das nie live geht. Sinnvoller ist, Funktionen nach Nähe zum eigentlichen Problem – den unnötigen Anfragen – zu ordnen.

Funktion	Löst das Problem?	Aufwand	Für die erste Version?
Statusanzeige (Auftrag, Ticket, Lieferung)	Direkt – häufigste Anfrageart	Mittel, hängt an Quellsystem	Ja
Dokumentenbereich (Rechnungen, Verträge, Lieferscheine)	Direkt – zweithäufigste Anfrageart	Mittel	Ja
Login mit Rollen- und Mandantentrennung	Voraussetzung für alles andere	Mittel bis hoch	Ja
Einfache Nachrichtenfunktion für Rückfragen	Reduziert Anfragen außerhalb des Portals	Niedrig	Ja, minimal
Self-Service-Formulare (Adressänderung, Nachbestellung)	Indirekt – ersetzt weitere Anfragearten	Niedrig bis mittel	Später
Online-Zahlung	Kein Anfrageproblem, eigenes Vorhaben	Hoch (PSD2, Zahlungsdienstleister)	Später
KI-gestützte Suche oder Chat-Assistent	Kann Navigation erleichtern, ersetzt keine Kernfunktion	Hoch, plus Risikoprüfung	Später, mit Prüfschritt

Eigene Priorisierungsmatrix Philogic Labs, aus Portal-Projekten mit KMU-Kunden.

Die Regel dahinter: Jede Funktion, die nicht direkt eine der häufigsten drei bis fünf Anfragearten ersetzt, gehört auf die Später-Liste – auch wenn sie im Meeting gut klingt. Willst du KI-Funktionen ergänzen, etwa eine Suche über Dokumente oder einen Assistenten für häufige Fragen, gilt dieselbe Zurückhaltung: Das BSI empfiehlt vor dem produktiven Einsatz generativer KI eine systematische Risikoanalyse, weil solche Systeme plausibel klingende, aber falsche Antworten liefern können – im Kundenkontakt ein Vertrauensrisiko, das man nicht unterschätzen sollte.

Wie trennt man Rollen und Mandanten?

Sobald mehr als ein Kunde im Portal aktiv ist, ist Mandantentrennung keine Nebensache mehr, sondern die zentrale Sicherheitsanforderung. Der IT-Grundschutz-Baustein ORP.4 des BSI formuliert dafür zwei Prinzipien, die sich direkt auf ein Kundenportal übertragen lassen: das Prinzip der geringsten Berechtigung – Nutzer erhalten nur die Rechte, die sie für ihre Aufgabe tatsächlich brauchen – und die Forderung nach Standard-Rechteprofilen statt Einzelfall-Regelungen pro Nutzer.

Für die Mandantentrennung selbst reicht eine rein oberflächliche Lösung nicht: Wenn zwei Kunden im selben Portal nie gegenseitig Daten sehen dürfen, muss das mindestens auf Ebene der Datenhaltung sichergestellt sein – nicht nur durch einen Filter in der Oberfläche, den ein Programmierfehler oder eine falsch konfigurierte Abfrage aushebeln kann. Praktisch heißt das: Jede Datenbankabfrage bekommt den Mandantenbezug fest eingebaut, nicht optional dazugeschrieben.

Eine einfache Matrix, mit der ich Rollen vor dem Bau kläre:

Rolle	Sieht eigene Daten	Sieht Daten anderer Mandanten	Darf Dokumente hochladen	Darf Rollen verwalten
Kunde – Standard	Ja	Nein	Nein (nur Download)	Nein
Kunde – Admin (z. B. Einkaufsleitung)	Ja	Nein	Ja	Ja, nur eigener Mandant
Internes Team – Support	Ja, je nach Freigabe	Nein, außer bei aktivem Vorgang	Ja	Nein
Internes Team – Administration	Ja	Ja (systemweit)	Ja	Ja

Eigenes Rollenraster Philogic Labs. Ausgangspunkt für die technische Umsetzung, kein Ersatz für eine mandantenspezifische Detailprüfung.

Zwei Fehler sehe ich in der Praxis am häufigsten: Erstens, eine einzige „Admin”-Rolle für alles – bequem beim Bauen, riskant im Betrieb, weil jeder Fehler maximale Reichweite hat. Zweitens, Rollen, die nie wieder überprüft werden: Jemand wechselt die Abteilung oder verlässt das Kundenunternehmen, die Zugänge bleiben aktiv. Nachvollziehbarkeit – wer hat wann worauf zugegriffen – gehört laut BSI-Baustein ORP.4 ebenso zur Grundausstattung wie die Rechtevergabe selbst.

Welche Systeme bindet man an?

Die Versuchung, ein Portal als isolierte neue Insel zu bauen, ist groß – und die falsche Richtung. Ein Portal ohne Anbindung an das führende System wird schnell selbst zur Quelle veralteter Daten, die es eigentlich vermeiden sollte. Die Leitfrage für jede mögliche Integration: Entsteht ohne sie doppelte Datenpflege oder eine veraltete Anzeige?

Typische Kandidaten, in der Reihenfolge, in der ich sie in Projekten prüfe:

1. Das System, das den Status führt – ERP, Auftragsverwaltung, Ticketsystem oder Projekttool. Das ist fast immer die wichtigste und erste Anbindung, weil sie die häufigste Anfrageart bedient.
2. Die Dokumentenablage – ob DMS, Cloud-Speicher oder ein Ordner im ERP-Modul. Wichtig ist eine dokumentierte Schnittstelle (API), über die sich Berechtigungen sauber abbilden lassen; ein reiner Dateizugriff ohne Rechteprüfung ist keine Option.
3. Das CRM, wenn Ansprechpartner, Verträge oder Kontaktdaten im Portal auftauchen sollen.
4. Buchhaltungssoftware, falls Rechnungen direkt aus der Finanzbuchhaltung statt aus einer Zwischenablage kommen sollen.

Alles, was darüber hinausgeht, sollte einen konkreten, benennbaren Nutzen haben – nicht „könnte später praktisch sein”. Jede zusätzliche Integration bedeutet zusätzliche Fehlerquellen, zusätzliche Wartung und zusätzliche Angriffsfläche, weil ein weiteres System Zugriff auf Kundendaten erhält oder gewährt. Bei der Anbindung selbst zählt vor allem, ob eine dokumentierte, stabile Schnittstelle existiert; Systeme ohne API oder mit ausschließlich manuellem Export lassen sich zwar anbinden, aber selten wartungsarm – das ist ein guter Grund, den Umfang der ersten Version klein zu halten.

Wie schützt man Dokumente?

Rechnungen, Verträge, Lieferscheine – die Dokumente in einem Kundenportal enthalten fast immer personenbezogene oder geschäftskritische Daten. Damit greift Artikel 32 DSGVO: Verantwortliche müssen unter Berücksichtigung von Stand der Technik, Kosten und Risiko geeignete technische und organisatorische Maßnahmen treffen, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitung sicherstellen – ausdrücklich genannt werden dabei Pseudonymisierung und Verschlüsselung sowie ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit dieser Maßnahmen.

Für ein Kundenportal übersetzt sich das in vier konkrete Bausteine:

• Zugriffskontrolle nach Rolle und Mandant. Siehe oben – ohne sauberes Rollenmodell ist jede weitere Schutzmaßnahme wirkungslos.
• Verschlüsselung bei Übertragung und Speicherung. Verbindungen ausschließlich verschlüsselt (HTTPS), Dokumente verschlüsselt abgelegt – Standard, aber in älteren oder schnell zusammengeklickten Portal-Lösungen nicht immer gegeben.
• Protokollierung. Wer hat wann auf welches Dokument zugegriffen? Diese Nachvollziehbarkeit ist sowohl für die eigene Fehlersuche als auch im Streitfall wichtig – und wird sowohl vom BSI-Berechtigungsmanagement als auch implizit von der Nachweispflicht aus Artikel 32 DSGVO gefordert.
• Löschregeln. Dokumente, die nicht mehr benötigt werden, sollten nach einer festgelegten Frist entfernt werden – nicht unbegrenzt „für alle Fälle” liegen bleiben. Das reduziert Angriffsfläche und Aufwand gleichermaßen.

Eine Einschränkung gehört hier ausdrücklich dazu: Dieser Abschnitt beschreibt technische und organisatorische Bausteine, keine Rechtsberatung. Ob eine konkrete Umsetzung im Einzelfall den Anforderungen aus DSGVO oder branchenspezifischen Vorgaben genügt, klärt eine Datenschutzbeauftragte oder Rechtsberatung – Stand Juli 2026, ohne Anspruch auf rechtliche Vollständigkeit.

Wie startet man klein?

Der häufigste Grund, warum Portal-Projekte scheitern oder ewig dauern, ist nicht Technik – es ist Scope. Sobald ein Portal „für alle Kunden alles” können soll, wächst die Liste der Anforderungen schneller als das Projektbudget. Der Ausweg: eine erste Version für eine begrenzte Kundengruppe und die zwei bis drei am häufigsten nachgefragten Informationen.

So gehe ich in eigenen Projekten vor: Zuerst zähle ich mit dem Kunden gemeinsam, welche Anfragearten tatsächlich das Support- oder Vertriebspostfach füllen – meist reichen zwei Wochen Beobachtung, um ein klares Bild zu bekommen. Häufig sind es Status und Dokumente, manchmal auch Liefertermine oder offene Rechnungen. Diese ein bis zwei Anfragearten werden zur ersten Version, mit einer einzigen, klar abgegrenzten Kundengruppe als Pilot – nicht alle Kunden gleichzeitig. Erst wenn diese Version läuft und echte Nutzung zeigt, was fehlt oder überflüssig ist, kommt die nächste Ausbaustufe.

Der Grund für diese Reihenfolge ist einfach: Ein Portal ohne echte Nutzung sagt dir nichts darüber, was als Nächstes wichtig ist. Ein Portal mit fünfzig Funktionen und fünf aktiven Nutzern ist teurer zu betreiben als eines mit fünf Funktionen und fünfzig aktiven Nutzern – und die zweite Variante lässt sich gezielt ausbauen, während die erste vor allem gepflegt werden muss.

Umsetzung: vom Scope zum ersten Release

Ein realistischer Ablauf für ein Kundenportal-Projekt in einem KMU sieht in etwa so aus:

1. Anfragen analysieren. Welche Fragen kommen wie oft – aus Postfach, Ticketsystem oder Telefonnotizen, nicht aus dem Bauchgefühl.
2. Systeme und Schnittstellen prüfen. Welches System führt die relevanten Daten, gibt es eine dokumentierte API, wie ist der aktuelle Berechtigungsstand dort?
3. Rollen- und Mandantenmodell entwerfen. Bevor eine Zeile Code geschrieben wird – siehe Matrix oben. Nachträglich ein Berechtigungskonzept einzuziehen ist deutlich aufwändiger als von Anfang an.
4. Ersten Funktionsumfang festlegen und schriftlich begrenzen. Ein Nicht-Ziel-Dokument – was diese Version explizit nicht kann – verhindert schleichenden Umfangzuwachs während des Baus.
5. Pilot mit einer Kundengruppe. Live-Betrieb, echtes Feedback, Messung: Sinken die Anfragen tatsächlich?
6. Auswerten und nächste Ausbaustufe entscheiden. Auf Basis von Nutzung, nicht von Wünschen, die während des Pilots aufkamen.

Wichtig für den Betrieb danach: eine benannte Zuständigkeit für Wartung, Sicherheitsupdates und die Pflege der Rollen – ein Kundenportal ohne Owner verwaist genauso wie jedes andere interne Tool, nur dass hier externe Nutzer die Folgen zuerst bemerken.

Was kostet ein Kundenportal?

Auch hier gilt: nur Bandbreiten mit Annahmen, keine pauschale Zusage – der tatsächliche Aufwand hängt stark von der Integrationstiefe ab. Drei Faktoren treiben die Kosten in meiner Erfahrung am stärksten:

• Integrationstiefe. Ein Portal, das ausschließlich auf eine einzige, gut dokumentierte API zugreift, ist deutlich günstiger als eines, das mehrere ältere Systeme ohne saubere Schnittstelle anbinden muss. Dieser Unterschied ist oft der größte Kostentreiber überhaupt – größer als die Portal-Oberfläche selbst.
• Anzahl und Komplexität der Rollen. Ein einfaches Zwei-Rollen-Modell (Kunde liest, Team verwaltet) ist schnell umgesetzt; ein differenziertes Modell mit mehreren Mandanten-Admin-Ebenen braucht mehr Planung und Testaufwand.
• Sicherheits- und Protokollierungsanforderungen. Je sensibler die Dokumente, desto mehr Aufwand für Verschlüsselung, Protokollierung und Löschregeln – das ist kein optionaler Zusatz, sondern Teil der Grundausstattung, sobald personenbezogene Daten im Spiel sind.

Zur internen Zeit: Neben der externen oder internen Entwicklung braucht ein Portal-Projekt spürbare Zeit von der Fachseite – für die Anforderungsklärung, das Testen mit echten Daten und die Pilotphase mit echten Kunden. Wer diesen Aufwand nicht einplant, verzögert das Projekt eher an dieser Stelle als an der Technik. Eine seriöse Kostenschätzung ist erst nach Klärung von Integrationstiefe und Rollenmodell möglich – vorher lässt sich höchstens eine grobe Größenordnung nennen, kein Festpreis.

Risiken & Grenzen

• Mandantentrennung ist kein Nice-to-have, das man „später” nachrüstet. Ein Fehler hier bedeutet im schlimmsten Fall, dass ein Kunde die Daten eines anderen sieht – das beschädigt Vertrauen dauerhaft und kann melde- und haftungsrechtliche Folgen haben.
• Ein Portal ersetzt keine schlechte Datenqualität im Quellsystem. Wenn die Statusdaten im ERP schon falsch oder veraltet sind, zeigt das Portal genau diese falschen Daten nur schneller und öffentlicher an.
• KI-Funktionen im Portal brauchen eine eigene Risikoprüfung. Ein Such- oder Chat-Assistent, der auf Kundendokumenten arbeitet, kann falsche oder unpassende Antworten liefern – und tut das im direkten Kundenkontakt, wo Fehler stärker auffallen als intern.
• Ohne Betriebsverantwortung verfällt jedes Portal. Rollen, denen niemand mehr entzogen wird, veraltete Statusanzeigen, ungepatchte Sicherheitslücken – ein Kundenportal braucht dauerhafte Pflege, kein einmaliges Projektende.
• Nicht jede Anfrage lässt sich durch ein Portal lösen. Komplexe, individuelle Rückfragen bleiben ein Gespräch. Das Portal reduziert die Routineanfragen, es ersetzt nicht den persönlichen Kontakt, wo er gebraucht wird.

Checkliste: Kundenportal entwickeln

1. Wir wissen, welche zwei bis drei Anfragearten tatsächlich das Postfach oder Telefon füllen – gemessen, nicht geschätzt.
2. Wir haben ein Rollenmodell nach dem Prinzip der geringsten Berechtigung entworfen, bevor wir gebaut haben.
3. Die Mandantentrennung ist mindestens auf Ebene der Datenhaltung sichergestellt, nicht nur über einen Filter in der Oberfläche.
4. Wir haben geprüft, welches System den Status führt und ob es eine dokumentierte Schnittstelle gibt.
5. Jede geplante Integration hat einen konkreten, benennbaren Nutzen – nicht „könnte praktisch sein”.
6. Dokumente sind verschlüsselt gespeichert und übertragen, Zugriffe werden protokolliert, es gibt eine Löschregel.
7. Die erste Version läuft mit einer begrenzten Kundengruppe, nicht mit allen Kunden gleichzeitig.
8. Es gibt ein schriftliches Nicht-Ziel-Dokument, das den Umfang der ersten Version begrenzt.
9. KI-Funktionen im Portal, falls geplant, durchlaufen eine eigene Risikoprüfung vor dem produktiven Einsatz.
10. Es gibt eine benannte Zuständigkeit für Betrieb, Sicherheitsupdates und Rollenpflege nach dem Livegang.

Wenn du Funktionsumfang oder Architektur deines geplanten Kundenportals von außen gegenprüfen lassen willst, bevor die erste Zeile Code entsteht: Unser Beratungsangebot für Scope- und Architektur-Checks findest du auf der Startseite, und ein kostenloses Erstgespräch klärt in kurzer Zeit, welche Fragen zuerst zu beantworten sind.