Kundenportal entwickeln lassen — was du wissen musst, bevor du anfängst

Ein Kundenportal ist die Schicht zwischen deinem Geschäft und deinen Endkunden, in der die Endkunden selbst arbeiten. Sie sehen Verträge, lösen Tickets, buchen, melden Status, laden Dokumente hoch. CRM, SaaS-Tool und Self-Service-Frontend werden in dem Begriff oft vermischt — sind aber drei verschiedene Dinge. Dieser Guide ordnet ein, wofür ein Portal steht, wann es sich aus einem CRM herauslöst und wann ein Eigenbau die einzige tragfähige Option ist.

Was ein Kundenportal ist — und was nicht

Drei Abgrenzungen, die in der Praxis regelmäßig durcheinandergehen:

• CRM (Salesforce, HubSpot, Pipedrive). Interne Sicht. Vertrieb, Marketing und Support arbeiten dort, du bist die Nutzergruppe — nicht deine Endkunden. Daten zum Endkunden sind dort, der Endkunde selbst hat keinen direkten Zugriff.
• Kundenportal. Externe Sicht. Deine Endkunden loggen sich ein und arbeiten selbst — Bestellungen, Tickets, Dokumente, Buchungen, Status. Du bist Betreiber, nicht Nutzer:in.
• SaaS-Anwendung. Ein Standardprodukt, das ein Hersteller an viele Kund:innen verkauft (z. B. Notion, Slack, Asana). Hat Portal-Charakter, ist aber kein „dein Portal” — es ist die Plattform eines Drittanbieters.

Ein Kundenportal kann auf einem SaaS-Tool aufsitzen (Salesforce-Community, HubSpot-Customer-Portal), als eigene Plattform laufen oder als App im Store. Die Wahl hängt nicht am Begriff — sie hängt an Workflow-Tiefe, Daten-Hoheit und Branding-Anspruch.

CRM und Portal — wie sie zusammenarbeiten

Ein CRM bleibt das CRM, auch wenn ein Portal danebensteht. Die Frage ist nicht „CRM oder Portal”, sondern „wann braucht der Endkunde eine eigene Schicht”. Drei Schwellen, ab denen es soweit ist:

1. Endkunden fragen wiederholt nach Status. Wenn Support, Vertrieb oder Account-Management mehr Zeit damit verbringt, „Wo steht mein Auftrag?” zu beantworten als an Inhalt zu arbeiten, fehlt eine Self-Service-Schicht.
2. Endkunden müssen selbst Daten pflegen. Stammdaten, Adressen, Verträge, Vollmachten — wenn das per Mail hin- und hergeschickt wird, brennt Zeit auf beiden Seiten.
3. Endkunden brauchen eigene Sicht auf gemeinsame Daten. Reportings, Auswertungen, Vertrags-Übersichten. Im CRM sind die Daten da — aber der Endkunde sieht sie nicht.

In allen drei Fällen ergänzt das Portal das CRM, statt es abzulösen. Daten fließen weiter ins CRM, der Endkunde bekommt einen eigenen Eingang. Komplette Ablösung passiert seltener — und nur in zwei klar umrissenen Konstellationen, die wir im Sub-Guide Wann löst ein Portal ein CRM ab? auflösen, zusammen mit den fünf operativen Signalen, an denen die Schwelle erkennbar wird.

Die typischen Portal-Bausteine

Ein Portal ist kein Feature-Wettbewerb gegen SaaS-Anbieter. Es ist eine Service-Schicht mit klar abgegrenztem Funktionsumfang:

• Auth und Rollen. Login, Passwort-Reset, Mehrbenutzer-Konten, Berechtigungsstufen. Nichts Spezielles, aber muss tragen — DSGVO-konform, sicher, nutzbar auf mobilen Endgeräten.
• Dashboard mit Status. Verträge, offene Aufträge, ausstehende Aktionen. „Was muss ich heute tun?” als zentrale Frage.
• Self-Service-Aktionen. Adresse ändern, Dokument hochladen, Termin buchen, Auftrag freigeben — die Aktionen, die in deinem Geschäft am häufigsten zwischen dir und Endkunden hin- und herwandern.
• Datei-Austausch. Verträge, Rechnungen, Berichte. Mit Versionierung, Audit-Log und einer für DSGVO tragfähigen Speicherung.
• Kommunikation. Tickets, Nachrichten, Status-Updates. Häufig integriert mit dem internen CRM oder Support-Tool.

Was nicht in jedes Portal gehört: Feature-Bloat aus dem internen Tool. Ein Portal ist gut, wenn es die fünf wichtigsten Aktionen sauber löst — nicht, wenn es jede CRM-Funktion nochmal in einer Endkunden-Sicht abbildet.

Eigenbau, SaaS oder Hybrid

Die Default-Option für die meisten Portale ist heute SaaS — Salesforce-Community, HubSpot-Customer-Portal, branchenspezifische Plattformen. Sie decken die Standard-Schicht ab. Wann ein Eigenbau die richtige Wahl ist und wann Hybrid-Setups tragen, steht im Sub-Guide Eigene Plattform bauen vs. SaaS mieten.

Die kurzen Trigger, ab wann SaaS reißt:

• Domänen-Workflow strukturell unpassend → Eigenbau prüfen.
• Daten-Hoheit oder Self-Host gefordert (regulierte Branche, Großkunde mit harter Anforderung) → Eigenbau wahrscheinlich.
• Multi-Tenant mit echtem Whitelabel (Franchise, Reseller, mehrere Standorte mit eigener Sicht) → SaaS klemmt fast immer.
• Drei oder mehr Pflicht-Integrationen über Standard-API hinaus → SaaS wird zur teuersten Komponente im Stack.

Wenn keiner der Trigger zutrifft, gewinnt SaaS. Custom-Dev gegen einen passenden SaaS-Anbieter zu stemmen, ist meist Verschwendung.

Was ein Portal kostet

Die Spanne ist breit. Eine schlanke Self-Service-Erweiterung über einer bestehenden Datenbank — Login, Dashboard, drei Self-Service-Aktionen, Datei-Up- und Download — liegt in DACH typisch im Bereich 25.000–60.000 €. Ein vollwertiges Portal mit Multi-Tenant-Logik, Reseller-Sicht, eigenem Reporting und Hardware- oder ERP-Integration landet schnell jenseits von 100.000 €.

Hinzu kommt: ein Portal ist kein „einmal bauen” — es lebt mit dem Geschäft mit. Hosting, Wartung, DSGVO-Pflege und neue Self-Service-Aktionen über die Jahre verteilt machen einen Posten aus, der dem CRM-Lizenzbudget oft nahekommt. Über drei Jahre rechnet sich der Eigenbau in unserer Praxis ab etwa 30–50 aktiven Plattform-Nutzer:innen mit nicht-trivialer Workflow-Tiefe — der TCO-Vergleich steht im Detail im Sub-Guide Eigene Plattform bauen vs. SaaS mieten.

Was häufig schiefgeht

Drei Anti-Pattern, die wir in Portal-Projekten regelmäßig sehen:

• Das Portal soll alles können. Sobald ein Portal versucht, das CRM nachzubauen, wird es schwerfällig und teuer. Bleib bei der Service-Schicht — die fünf Self-Service-Aktionen, die heute zwischen dir und Endkunden brennen.
• Daten-Modell wird vom CRM dupliziert. Ohne klare Single-Source-of-Truth landest du in Sync-Problemen: Endkunde ändert Adresse im Portal, im CRM steht die alte. Daten-Hoheit muss vor dem ersten Feature geregelt sein.
• Endkunden wurden im Konzept nicht befragt. Portale werden gerne intern entworfen — und Endkunden nutzen sie dann nicht, weil die fünf wichtigsten Aktionen aus deren Sicht nicht abgedeckt sind. Drei Endkunden-Interviews vor dem Build sparen drei Iterationen nach dem Launch.

Wann der Bau Sinn ergibt

Ein eigenes Portal lohnt sich nicht prophylaktisch — es lohnt sich, wenn drei Bedingungen zusammenkommen:

1. Endkunden-Selbstbedienung würde im aktuellen Geschäft messbar Last sparen (Support-Tickets, Mail-Volumen, manuelle Daten-Pflege).
2. Standard-SaaS bildet den eigenen Workflow nicht ab — entweder strukturell oder bei kritischen Punkten nur über teure Workarounds.
3. Die Lösung soll länger als drei Jahre tragen. Unter dieser Schwelle gewinnt SaaS in der TCO-Rechnung fast immer.

Wenn du gerade prüfst, ob ein Portal in deinem Geschäft sinnvoll ist: beschreib uns die Situation in drei Sätzen — wie viele Endkunden, welche Top-3-Anliegen kommen heute manuell an dich, was läuft schon in einem CRM oder SaaS — über das Kontaktformular. Wir antworten in 24 Stunden mit einer ehrlichen Einschätzung, ob ein Eigenbau, eine SaaS-Erweiterung oder ein Hybrid der bessere Pfad ist. Mehr Service-Kontext auf Lösungen. Wer das Portal später als App ausspielen will, findet die Stack-Logik unter Native vs. Cross-Plattform vs. PWA.