Kundenportal-Frontend über CRM und Billing: Self-Service ohne Rewrite

Ein Kundenportal-Frontend über CRM und Billing bedeutet, dass die Anmelde- und Self-Service-Oberfläche als eigenständige Frontend-Schicht vor CRM-, Billing- und Kernsystemen liegt. Das Kundenkonto, die Rechnung und der Vertragsstatus bleiben, wo sie sind. Nur die Oberfläche wird neu gebaut, ohne dass ihr CRM oder Billing anfassen müsst.

Das Problem: Kundenportale altern schneller als das Backend darunter

Viele Kundenportale sind über Jahre gewachsen: ein CRM für Kontodaten, ein Billing-System für Rechnungen und Abos, dazu vielleicht ein Ticketing-Tool für den Support. Jedes System bringt sein eigenes UI mit, und irgendwann klickt sich ein Kunde durch drei verschiedene Optiken, nur um seinen Vertrag zu ändern.

Das Frontend ist meist das älteste Teil der Kette. Es wurde einmal an das damalige CRM angebunden und seitdem kaum modernisiert, weil ein Rewrite bedeutet: neue Login-Logik, neue Rechnungsdarstellung, neue Rollen- und Rechteverwaltung, alles gleichzeitig. Das Risiko eines kompletten Neubaus hält viele Teams davon ab, das Portal überhaupt anzufassen, selbst wenn die Oberfläche längst hinter dem Rest der Marke zurückliegt.

Was ein Kundenportal-Frontend eigentlich ist

Ein Kundenportal-Frontend ist die Präsentationsschicht, die Kunden sehen und bedienen: Login, Account-Übersicht, Rechnungsverlauf, Vertragsänderungen, Support-Tickets. Es ist bewusst getrennt von den Systemen, die die Daten halten: CRM für Kundendaten, Billing für Abrechnung, ein OMS oder Ticketing-Tool für Prozesse.

Diese Trennung ist keine akademische Übung. Sie entscheidet, ob ihr eine Rebranding-Anforderung in Tagen umsetzt oder auf den nächsten CRM-Release warten müsst, weil die UI direkt im CRM-Template liegt.

Architektur: Frontend über CRM und Billing, nicht ersetzt

Der pragmatische Weg ist nicht "CRM raus, neues System rein", sondern eine composable Frontend-Schicht, die mit den bestehenden APIs von CRM und Billing spricht. Bei Laioutr übernimmt das Orchestr, unsere GraphQL-Schicht, die heute mehr als 50 Backend-Systeme normalisiert (siehe Composable Headless Frontend). Kontodaten kommen aus dem CRM, Rechnungen und Zahlungsstatus aus dem Billing-System, beides landet in einem einheitlichen Datenmodell, das die Portal-Komponenten konsumieren.

Für den Login-Fluss bedeutet das: Die bestehende Session beziehungsweise der Auth-Token aus CRM oder Billing wird durchgereicht, nicht neu erfunden. Das Frontend prüft, zeigt an, leitet um, aber die Autorisierungshoheit bleibt im System, das sie heute schon hat. Genau das unterscheidet ein Frontend-Projekt von einem Identity-Migrationsprojekt, und Letzteres wolltet ihr ohnehin nicht anfassen.

Self-Service ohne Rewrite: Was sich ändert und was nicht

Was sich ändert: Die Oberfläche wird schneller, konsistenter und pflegbar. Layout, Formulare und Microcopy im Portal lassen sich über das Content Management der Plattform anpassen, ohne dass Marketing oder Support jedes Mal ein Entwickler-Ticket aufmachen muss (siehe Content Management). Ein neues Self-Service-Formular für Adressänderungen ist eine Komponenten-Konfiguration, kein Sprint.

Was sich nicht ändert: eure Datenhoheit. CRM bleibt Single Source of Truth für Kundendaten, Billing bleibt es für Rechnungen und Zahlungsläufe. Compliance-Teams müssen keine neue Datenbank absegnen, weil keine entsteht. Das Frontend liest und schreibt über die bestehenden APIs.

Blueprint: Vier Schritte zum Frontend-Layer

1. Inventar. Welche Systeme liefern heute welche Daten ins Portal: CRM, Billing, Ticketing, vielleicht ein separates Login-System? Das ist die Landkarte für die API-Anbindung.
2. Datenmodell. Normalisiert Konto-, Rechnungs- und Vertragsdaten in ein Frontend-Schema, unabhängig davon, wie das CRM sie intern benennt.
3. Auth-Übergabe. Definiert, wie Session oder Token vom bestehenden System ins neue Frontend wandern, ohne eigene Identity-Logik zu bauen.
4. Rollout in Schritten. Startet mit einem Bereich, etwa Rechnungsübersicht, und migriert Bereich für Bereich, während das alte Portal für den Rest weiterläuft.

Dieser Blueprint funktioniert für B2B-Self-Service-Portale genauso wie für klassische B2C-Kundenkonten. Siehe auch unsere Patterns zu B2B-Self-Service-Frontends und zu Punchout und Staffelpreisen im B2B-Portal, beide Ausgangspunkt für den gleichen Frontend-über-Backend-Ansatz.

Wann sich das lohnt, und wann nicht

Der Ansatz lohnt sich, wenn CRM und Billing funktional passen, aber die Oberfläche das Wachstum bremst, oder wenn ihr mehrere Systeme unter einer Login-Erfahrung zusammenführen wollt. Er lohnt sich nicht, wenn das eigentliche Problem im CRM selbst liegt: veraltete Datenstruktur, fehlende API. Laioutr ist auf die Frontend-Ebene spezialisiert, nicht auf CRM- oder Billing-Ersatz. Wenn euer CRM grundsätzlich ausgetauscht werden muss, ist das ein anderes Projekt, das zuerst gelöst werden sollte.

Für B2B-lastige Self-Service-Szenarien mit Punchout, Staffelpreisen oder Schnellerfassung lohnt sich zusätzlich ein Blick auf unser B2B Growth Kit, das genau diese Muster als produktionsreife Komponenten mitbringt.

FAQ

Muss unser CRM oder Billing-System ausgetauscht werden? Nein. Der Ansatz setzt bewusst darauf, CRM und Billing als Backend zu behalten und nur die Frontend-Schicht zu erneuern.

Wie läuft die Anmeldung, wenn CRM und Billing unterschiedliche Logins haben? Das Frontend reicht die bestehende Session oder den Token weiter, statt eine eigene Identity-Lösung zu bauen. Wo zwei Systeme getrennte Logins haben, entscheidet der Rollout, welches System führend ist.

Wie schnell lässt sich ein erster Bereich live schalten? Das hängt vom API-Zustand von CRM und Billing ab. Realistisch ist ein erster Self-Service-Bereich, etwa Rechnungen, deutlich vor einem vollständigen Portal-Rewrite, weil kein Backend-Wechsel im Zeitplan steckt.

Mehr zum Kundenportal-Frontend

Die vollständige Lösungs-Übersicht für Self-Service-Portale über CRM und Billing findet ihr auf unserer Solution-Seite Portale und Self-Service.