Kundenportale gehören zu den Projekten, die auf dem Papier immer überzeugen. Die Kundschaft bedient sich selbst, der Support wird entlastet, Anfragen per Telefon und E-Mail gehen zurück. Die Rechnung stimmt — bis zum Launch. Danach loggt sich ein Bruchteil der Erwarteten ein, und der Support beantwortet weiterhin dieselben Fragen wie vorher.
Wir bauen solche Portale seit Jahren, überwiegend für Mittelstand und soziale Träger. Dieser Artikel beschreibt, was tatsächlich hineingehört, wie sich Kaufen und Bauen unterscheiden, welche Budgets realistisch sind — und was die Portale, die funktionieren, von denen unterscheidet, die leer bleiben.
Was ein Kundenportal ist — und was nicht
Ein Kundenportal ist ein geschützter Bereich, in dem eure Kundschaft Dinge selbst erledigt, für die sie sonst bei euch anruft. Das ist bewusst weit gefasst, denn der Inhalt unterscheidet sich stark je nach Geschäft:
- Im B2B-Handel: Bestellhistorie, Nachbestellung, Lieferstatus, Rechnungen, individuelle Preise
- Bei Dienstleistern: Projektstände, Dokumente, Freigaben, Ansprechpartner, Termine
- Bei Versicherungen und Verbänden: Vertragsdaten, Änderungsanträge, Bescheinigungen, Beitragsübersichten
- Bei Software-Anbietern: Lizenzen, Nutzerverwaltung, Verbrauch, Tickets
Was ein Kundenportal nicht ist: ein Shop, ein CRM oder ein Ticketsystem. Es greift auf all das zu, ersetzt es aber nicht. Wer das vermischt, baut aus einem Portal ein Systemersatzprojekt — und aus sechs Monaten werden zwei Jahre.
Kaufen oder bauen?
Es gibt fertige Portallösungen, und für manche Fälle sind sie die richtige Wahl. Die ehrliche Abgrenzung:
| Kriterium | Fertiglösung | Eigenentwicklung |
|---|---|---|
| Startzeit | Wochen | 3–6 Monate |
| Anfangskosten | Niedrig | Höher |
| Laufende Kosten | Pro Nutzer, dauerhaft | Betrieb und Wartung |
| Passt zu euren Prozessen | Ihr passt euch an | Es passt sich euch an |
| Anbindung ans ERP | Nur was vorgesehen ist | Beliebig |
| Eigenes Erscheinungsbild | Begrenzt | Vollständig |
| Datenhoheit | Beim Anbieter | Bei euch |
Die Entscheidung hängt an einer einzigen Frage: Ist das, was eure Kundschaft im Portal sehen soll, in einem Standardsystem überhaupt abbildbar? Wer Bestellungen, Rechnungen und Lieferstatus zeigt, findet dafür Standardlösungen. Wer branchenspezifische Daten aus einem gewachsenen ERP zeigt, mit eigenen Rollen und eigenen Freigabewegen, wird bei jeder Fertiglösung an dieselbe Wand laufen — und baut dann teure Umwege um Grenzen herum, die er sich selbst eingekauft hat.
Bei den laufenden Kosten lohnt das Nachrechnen. Eine Lizenz pro Nutzer und Monat ist bei fünfzig Kunden unauffällig und bei zweitausend ein erheblicher Posten — der genau dann steigt, wenn das Portal erfolgreich ist.
Was in die erste Ausbaustufe gehört
Der teuerste Fehler ist, in Version eins alles zu bauen, was jemandem eingefallen ist. Unsere Empfehlung ist das Gegenteil: die zwei bis drei Dinge, nach denen euer Support am häufigsten gefragt wird — und sonst nichts.
Vorher: eine Woche Support-Statistik
Zählt mit, worum es bei eingehenden Anfragen tatsächlich geht. Fast immer entfallen 60 bis 80 Prozent auf drei bis vier Themen. Die sind der Umfang von Version eins — nicht das, was in der Leitungsrunde vorgeschlagen wurde.
Version 1: Anmeldung plus die Top-3
Typisch: Belege ansehen und herunterladen, Status einer laufenden Sache, Stammdaten ändern. Wenig, dafür funktionierend und schnell.
Version 2: nach Nutzungsdaten
Was wird tatsächlich aufgerufen, wo brechen Leute ab, wonach wird weiterhin angerufen. Erst danach entscheiden, was als Nächstes gebaut wird.
Version 3: Schreibvorgänge
Bestellen, beauftragen, ändern. Alles, was Daten in euren Systemen verändert, kommt zuletzt — weil es die höchsten Anforderungen an Berechtigungen, Protokollierung und Fehlerbehandlung hat.
Anmeldung und Berechtigungen
Hier steckt regelmäßig mehr Aufwand als erwartet, und zwar nicht in der Anmeldemaske, sondern in der Frage dahinter: Wer darf was sehen?
Im B2B ist das selten trivial. Ein Kunde ist meist ein Unternehmen mit mehreren Personen, die unterschiedlich viel sehen dürfen. Die Einkaufsleitung sieht alle Bestellungen, die Sachbearbeitung nur die eigenen. Der Steuerberater sieht Rechnungen, aber keine Preise. Und wenn jemand das Unternehmen verlässt, muss der Zugang zuverlässig erlöschen.
Praktische Empfehlungen aus unseren Projekten:
- Nutzerverwaltung an die Kundschaft delegieren. Eine Administratorin pro Kundenunternehmen legt eigene Kolleginnen und Kollegen an. Das entlastet euren Support genau dort, wo er sonst am stärksten belastet wird.
- Berechtigungen am Datenmodell, nicht an der Oberfläche. Wenn die Prüfung nur beim Rendern der Seite stattfindet, ist sie über die API umgehbar. Sie gehört dorthin, wo die Daten geholt werden.
- Kein Selbstregistrierungsformular ohne Prüfung. Bei geschäftlichen Portalen muss eine Zuordnung zum Kundenkonto stattfinden — sonst legt sich der Wettbewerb einen Zugang an.
- Zwei-Faktor anbieten, nicht erzwingen. Erzwingen kostet in gemischter Kundschaft messbar Nutzung. Für administrative Rollen ist es dagegen richtig.
Die Schnittstelle ist das Projekt
Ein Kundenportal ist technisch selten anspruchsvoll. Anspruchsvoll ist, an die Daten zu kommen. In fast jedem Projekt entfällt der größte Aufwandsblock auf die Anbindung an ERP, Warenwirtschaft oder Buchhaltung.
| Situation im Altsystem | Realistischer Aufwand |
|---|---|
| Dokumentierte REST- oder SOAP-API | 1–3 Wochen |
| Datenbankzugriff, lesend möglich | 2–4 Wochen |
| Nächtlicher Dateiexport (CSV, XML) | 2–5 Wochen, aber Daten nicht aktuell |
| Keine Schnittstelle, Anbieter muss liefern | Unkalkulierbar — zuerst klären |
Die letzte Zeile ist der Grund, warum wir in Angeboten für Kundenportale immer eine kurze technische Vorabklärung vorschlagen. Ob euer ERP-Anbieter eine Schnittstelle bereitstellt, wie lange er dafür braucht und was er dafür verlangt, entscheidet über Zeitplan und Budget stärker als alles andere im Projekt.
Ein Zwischenweg, der oft gut funktioniert: Das Portal bekommt eine eigene Datenbank und wird regelmäßig aus dem Altsystem befüllt. Damit sind die Daten nicht sekundenaktuell, aber das Portal ist schnell, unabhängig von der Verfügbarkeit des Altsystems und belastet es nicht. Für Bestellhistorien und Belege ist das fast immer ausreichend.
Was ein Portal kostet
Grobe Größenordnungen aus unseren Projekten, für eine Eigenentwicklung auf Django-Basis:
Version 1, lesend
35–60k €
Anmeldung, Rollen, 2–3 Ansichten, eine saubere Schnittstelle, Design im eigenen Erscheinungsbild
Mit Schreibvorgängen
60–120k €
Zusätzlich Bestellungen oder Anträge, Freigabewege, Protokollierung, Rückschreiben ins Altsystem
Betrieb pro Jahr
15–25 %
Der Entwicklungskosten, für Hosting, Wartung, Sicherheitsaktualisierungen und kleine Anpassungen
Der Betriebsposten wird regelmäßig vergessen und ist der häufigste Grund, warum Portale nach zwei Jahren veraltet aussehen. Ein Portal ist kein Projekt mit Ende, sondern ein System mit Lebensdauer.
Warum die meisten Portale kaum genutzt werden
Und damit zum eigentlichen Thema. Wenn ein Kundenportal nach dem Launch leer bleibt, liegt es fast nie an der Technik. Es liegt an einem von vier Dingen:
- Anrufen ist bequemer. Wenn die Sachbearbeiterin am Telefon in dreißig Sekunden hilft, gewinnt sie gegen jede Anmeldemaske. Das Portal muss schneller sein als der bisherige Weg, nicht nur verfügbar.
- Niemand hat es angekündigt. Ein Portal braucht eine Einführung wie ein Produkt: E-Mail an alle Kunden, Hinweis in der Auftragsbestätigung, Verweis in der Signatur des Supports, Erinnerung nach vier Wochen.
- Der Support kennt es nicht. Wenn eure Leute bei jeder Anfrage weiterhin selbst nachschauen, statt auf das Portal zu verweisen, ändert sich nichts. Der Support ist der wichtigste Vertriebsweg für das Portal.
- Es bietet zu wenig. Wer sich anmeldet und nur seine Adresse ändern kann, kommt nicht wieder. Deshalb: die häufigsten Support-Themen zuerst, nicht die einfachsten.
Messt die Nutzung von Anfang an — angemeldete Nutzer, wiederkehrende Nutzer, Aufrufe je Funktion, und parallel das Anfragevolumen im Support. Ohne diese Zahlen lässt sich nach einem Jahr nicht beantworten, ob sich die Investition gelohnt hat.
Kundenportal geplant?
Wir bauen Portale auf Django-Basis, inklusive Anbindung an gewachsene ERP- und Warenwirtschaftssysteme. Als Django Agentur aus Berlin mit über 100 Backend-Projekten — und wir sagen ehrlich, wenn eine Fertiglösung für euch die bessere Wahl ist.
Erstgespräch vereinbaren →Fazit
Ein Kundenportal ist ein gutes Projekt, wenn es aus einem konkreten Schmerz entsteht — messbar viele Anfragen zu wenigen Themen — und schlecht, wenn es aus dem Wunsch entsteht, digitaler zu wirken.
Der Weg, der bei uns zuverlässig funktioniert: eine Woche Support-Anfragen zählen, die drei häufigsten Themen bauen, früh live gehen, Nutzung messen und danach entscheiden, was folgt. Das ist unspektakulär und deutlich erfolgreicher als der große Wurf, der achtzehn Monate braucht und dann an Gewohnheiten scheitert.
Und die Frage, die vor allem anderen geklärt gehört: Kommt ihr überhaupt an die Daten, die ihr zeigen wollt? Alles andere im Projekt ist planbar. Das ist es oft nicht.