Alle Abbildungen in diesem Beitrag sind KI-generierte Symbolbilder. Sie zeigen keine realen Kunden, Projekte oder Benutzeroberflächen.
Transparenzhinweis: Die Preisangaben sind H-Studio-Erfahrungswerte und unverbindliche Richtwerte für B2B-Projekte im DACH-Markt, keine Marktstatistik und kein Angebot. Alle Beträge verstehen sich netto zzgl. gesetzlicher Umsatzsteuer, sofern nicht anders angegeben.
Kurze Antwort
Ein individuelles B2B-Kundenportal kostet nach H-Studio-Erfahrung 2026 typischerweise 20.000–40.000 € für eine fokussierte erste Version mit Login, Dokumenten, Status und Basis-Admin. Mit mehreren Rollen, CRM-Synchronisation, Benachrichtigungen und erweiterten Workflows liegt der Rahmen häufig bei 35.000–80.000 €. SSO, komplexe Berechtigungen, Audit-Anforderungen und tiefe Integrationen können 60.000–120.000 € oder mehr erfordern.
Die Spanne entsteht nicht durch das sichtbare Dashboard, sondern durch die Systemlogik dahinter. Ein Portal hat mindestens zwei Seiten: die Oberfläche für Kunden oder Partner und das Backoffice, mit dem das interne Team Zugänge, Dokumente, Freigaben, Status und Ausnahmen verwaltet. Dazu kommen Datenmodell, Integrationen, Betrieb und Übergabe.
Wer nur „Login plus einige Seiten“ bepreist, kalkuliert oft nicht dasselbe Produkt wie ein Anbieter, der Rollen, Admin, Fehlerfälle, Synchronisation und Löschung einschließt. Deshalb zeigt dieser Guide nicht nur Gesamtpreise, sondern die Komponenten, die ein Angebot nach oben oder unten bewegen.
Preisrahmen nach Portal-Stufe
| Portal-Stufe | Typischer Umfang | H-Studio-Richtwert | Typische Dauer |
|---|---|---|---|
| Architektur- und Scope-Phase | Rollen, Workflows, Daten, Integrationen, Risiken, Roadmap | 3.500–7.500 € | etwa 5 Arbeitstage |
| Basis-Portal | Login, Dokumente, Status, Basis-Admin, Deployment | 20.000–40.000 € | 6–10 Wochen |
| Mittlere Stufe | RBAC, CRM-Sync, Notifications, mehrere Workflows, Reporting | 35.000–80.000 € | 10–16 Wochen |
| Erweiterter Ausbau | SSO, komplexe Rechte, Audit-History, tiefe Integrationen, Migration | 60.000–120.000 €+ | 14–20 Wochen+ |
Die Stufen sind keine Pakete mit garantiertem Endpreis. Der konkrete Rahmen hängt von Rollen, Datenmigration, Integrationen, Qualitätsanforderungen, Betriebsverantwortung und dem erforderlichen Prüf- oder Nachweisniveau ab.
Welche Komponenten treiben die Kundenportal-Kosten?
| Komponente | Was tatsächlich gebaut wird | Preiseinfluss |
|---|---|---|
| Authentifizierung | Login, Passwort-Reset, Einladungen, MFA oder SSO, Session-Sicherheit | niedrig bis hoch — SSO und mehrere Identitätsquellen erhöhen Scope |
| Rollen und Berechtigungen | Wer darf welche Organisation, Fälle, Dateien und Aktionen sehen? | hoch, besonders bei vielen Rollen oder Ausnahmen |
| Tenant-Isolation | Trennung der Daten mehrerer Kundenorganisationen | hoch, weil jede Query und jeder Export Grenzen respektieren muss |
| Dokumente | Upload, Download, Versionen, Metadaten, Freigaben, Scan/Preview, Löschung | mittel bis hoch |
| Anfragen und Workflows | Tickets, Anträge, Status, Freigaben, Eskalationen, Fristen | mittel bis hoch je nach Zustandslogik |
| Admin-Backoffice | Nutzerverwaltung, Queues, Suche, Korrekturen, Support- und Ausnahmefälle | häufig unterschätzt, aber zentral |
| CRM-/ERP-Integration | Synchronisation, Quelle der Wahrheit, Fehlerbehandlung, Reconciliation | hoch; API-Qualität und Datenmodell entscheiden |
| Benachrichtigungen | E-Mail, In-App, Vorlagen, Präferenzen, Zustellung und Wiederholung | niedrig bis mittel |
| Reporting und Exporte | Dashboards, CSV/PDF/XLS, geplante Reports, Berechtigungen | mittel bis hoch |
| Mehrsprachigkeit | UI-Texte, Content, E-Mails, Dokumentvorlagen, Supportprozesse | mittel; mehr als ein Übersetzungsbutton |
| Datenschutz und Aufbewahrung | Datenminimierung, Zugriffe, Lösch- und Aufbewahrungswege | abhängig von Daten und Verantwortlichkeiten |
| Betrieb und Handover | Monitoring, Backups, Deployment, Runbooks, Umgebungen, Wissenstransfer | muss im Gesamtpreis sichtbar sein |
Die Tabelle zeigt, warum zwei Portale mit ähnlicher Oberfläche völlig unterschiedliche Kosten haben können. Ein Status-Dashboard mit einer Rolle ist etwas anderes als ein Mandantenportal, in dem Kunde, Sachbearbeitung, Partner und Administrator unterschiedliche Dokumente und Aktionen sehen.
„Website mit Login“ oder echtes Kundenportal?
Eine geschützte Website ist sinnvoll, wenn alle Nutzer dieselben statischen Informationen erhalten und das interne Team kaum etwas verwalten muss. Sie wird zum Portal, sobald individuelle Daten, Rollen und laufende Prozesse hinzukommen.
Ein echtes Kundenportal beantwortet mindestens vier Systemfragen:
- Identität: Wer ist der Nutzer und zu welcher Organisation gehört er?
- Berechtigung: Welche Daten und Aktionen sind für diese Person erlaubt?
- Workflow: Was passiert nach Upload, Anfrage, Freigabe oder Statuswechsel?
- Betrieb: Wie korrigiert, unterstützt und überwacht das interne Team den Prozess?
Wenn ein Angebot nur die externe Oberfläche beschreibt, fehlt möglicherweise die Hälfte des Produkts. Ohne Admin-Backoffice landen Freigaben, Ausnahmen und Korrekturen wieder in E-Mail und Tabellen. Das Portal zeigt dann einen Prozess, steuert ihn aber nicht.
Rollen und Tenant-Isolation: der unsichtbare Kostentreiber
Rollenbasierter Zugriff ist nicht mit einer Liste aus „Admin“ und „User“ erledigt. In B2B-Portalen kommen häufig Organisation, Standort, Projekt, Fall oder Vertrag als zusätzliche Grenzen hinzu. Ein Partner darf vielleicht mehrere Kunden sehen, ein Kunde nur eigene Projekte und ein interner Support-Mitarbeiter bestimmte Aktionen ausführen, aber keine Finanzdaten exportieren.
Diese Regeln beeinflussen Datenmodell, APIs, UI, Tests, Exporte und Protokollierung. Sie später nachzurüsten ist riskanter als eine zunächst einfache, aber klare Rechtearchitektur. Deshalb sollte die erste Phase keine vollständige Rollenmatrix bauen, wohl aber die absehbaren Grenzen kennen.
Bei mehreren Kundenorganisationen ist Tenant-Isolation eine strukturelle Eigenschaft. Jede Abfrage, Suche, Datei und Hintergrundaufgabe muss den richtigen Kontext beachten. „Wir filtern später nach customer_id“ ist ohne zentrale Zugriffsschicht und Tests kein belastbares Sicherheitsmodell.
Dokumenten-Management kostet mehr als ein Upload-Feld
Ein einfacher Upload in einen Storage Bucket ist schnell gebaut. Ein betriebsfähiger Dokumentenprozess benötigt zusätzliche Entscheidungen:
- erlaubte Dateitypen und Größen;
- Malware- oder Inhaltsprüfung, wenn der Risikokontext sie verlangt;
- Metadaten, Kategorien und Zuordnung zu Fall oder Organisation;
- Sichtbarkeit und Freigabezustand;
- Versionierung oder Ersetzung;
- Download-, Export- und Löschwege;
- Aufbewahrungsbedarf und Verantwortlichkeit;
- Fehlerfälle bei unvollständigen oder abgebrochenen Uploads.
Nicht jedes Portal braucht jede Funktion. Die Kosten sinken, wenn die erste Version einen klaren Dokumenttyp und einen geraden Austausch-Workflow abbildet, statt sofort ein allgemeines Document Management System nachzubauen.
Integrationen: nicht der API-Call, sondern die Zuständigkeit kostet
„CRM anbinden“ klingt wie ein einzelner technischer Task. Tatsächlich müssen beide Seiten dieselben Fragen beantworten: Welches System ist die Quelle der Wahrheit? Was passiert bei widersprüchlichen Daten? Werden Änderungen sofort, geplant oder manuell synchronisiert? Wie werden Fehler sichtbar und wiederholt? Wer darf einen Datensatz zusammenführen oder löschen?
Eine gut dokumentierte API mit stabilen Identifikatoren ist günstiger anzubinden als ein Altsystem mit manuellen Exporten und wechselnden Feldern. Vor dem Angebot sollte die Agentur deshalb API-Dokumentation, Testzugang, Rate Limits und relevante Datenobjekte prüfen. Ohne diese Informationen ist ein Integrationspreis eine Annahme.
Datenschutz: technischer Scope statt pauschales „DSGVO-konform“
Portale verarbeiten häufig Account-, Kontakt-, Vertrags- oder Dokumentdaten. Die konkrete rechtliche Bewertung liegt bei den Verantwortlichen und gegebenenfalls deren Datenschutzberatung. Das Engineering muss die vereinbarten Anforderungen jedoch umsetzbar machen: Datenminimierung und Zweckbindung aus Art. 5 DSGVO, geeignete technische und organisatorische Maßnahmen, Auftragsverarbeitung nach Art. 28 sowie Datenschutz durch Technikgestaltung nach Art. 25 sind typische Prüffelder.
Ein Kostenangebot sollte deshalb nicht pauschal einen „Compliance-Aufschlag“ enthalten. Besser ist ein benannter Scope: Rollenmodell, Löschweg, Audit-History, Verschlüsselung, Backups, Unterauftragnehmer, Datenregionen und Incident-Prozess. Formale Zertifizierung, Rechtsauslegung und Datenschutz-Folgenabschätzung sind getrennte Verantwortlichkeiten und nicht automatisch Teil eines Software-Builds.
So wird ein Portal phasenweise lieferbar
Der beste Hebel für ein kleineres Budget ist nicht ein niedrigerer Qualitätsstandard, sondern eine engere erste Prozessgrenze. Ein sinnvoller Ablauf kann so aussehen:
Phase 0: Scope und Architektur
Nutzergruppen, Kern-Workflow, Datenobjekte, Integrationen und Betriebsverantwortung werden sichtbar. Das Ergebnis ist kein monatelanges Lastenheft, sondern eine priorisierte Systemkarte mit Risiken und Schätzung.
Phase 1: Ein durchgängiger Portalpfad
Ein externer Nutzer wird eingeladen, meldet sich an, sieht den richtigen Status, übermittelt ein Dokument oder eine Anfrage und das interne Team bearbeitet den Vorgang im Basis-Admin. Deployment, Monitoring und Zugriffsgrenzen gehören bereits dazu.
Phase 2: Automatisierung und Integrationen
CRM-Synchronisation, Benachrichtigungen, zusätzliche Rollen, Reporting oder weitere Dokumenttypen werden ergänzt, nachdem der Kernprozess mit echten Nutzern funktioniert.
Phase 3: Enterprise-Anforderungen
SSO, erweiterte Audit-Ansichten, komplexere Tenant-Strukturen, zusätzliche Regionen oder formalisierte Prüfanforderungen kommen hinzu, wenn reale Kunden oder Procurement sie benötigen.
Diese Reihenfolge ist kein Dogma. Sie verhindert aber, dass ein Team ein umfassendes Rollen- und Integrationssystem finanziert, bevor feststeht, welcher Workflow wirklich genutzt wird.
Drei reale Systeme — und warum sie unterschiedlich scoped wurden
Forschungsmittel.com ist das direkteste Portalbeispiel: öffentliche Akquisition, Kunden-Dashboard, interner Team-Workspace, Dokumentanfragen und Status-History greifen auf ein gemeinsames Produktmodell zu. Die relevante Komplexität liegt nicht in einer einzelnen Seite, sondern in der Verbindung von Kunden- und Operations-Workflow. Details stehen in der Case Study Forschungsmittel.com.
Vulken FM ist kein klassisches Kundenportal, zeigt aber denselben Architekturpunkt aus einer anderen Richtung: Mobile Field App und Web-Admin müssen Sites, Assets, Inspektionslogik, Offline-Erfassung und Reporting konsistent verbinden. Das Beispiel zeigt, warum „eine App plus Dashboard“ ohne Daten- und Workflow-Modell keine belastbare Schätzung ist. Mehr dazu in der Vulken FM Case Study.
My Office Asia ist eine Public-Site mit strukturiertem Katalog und individuellem Admin-CMS — ebenfalls kein Kundenportal. Der Vergleich ist nützlich, weil er die Kostengrenze sichtbar macht: Sobald ein internes Team Daten, Listings und Inhalte in einem Backoffice betreibt, ist der sichtbare Web-Auftritt nur eine Oberfläche des Systems. Die Case Study My Office Asia beschreibt Scope und Handover transparent.
Kaufen oder individuell entwickeln?
Ein Standardportal ist wirtschaftlich, wenn Ihre Prozesse weitgehend dem Produktmodell entsprechen und Integrationen verfügbar sind. Prüfen Sie zuerst CRM-, ERP-, Helpdesk-, DMS- oder Branchenlösungen. Individuelle Entwicklung wird sinnvoll, wenn Rollen, Daten oder Workflows ein echter Differenzierungsfaktor sind oder mehrere bestehende Systeme in einer kontrollierten Oberfläche verbunden werden müssen.
Eine ehrliche Entscheidung berücksichtigt nicht nur Lizenz und Build, sondern auch Konfiguration, Migration, interne Prozessänderung, Betrieb und Exit. Custom Software ist nicht automatisch besser. Sie verschiebt Kontrolle und Verantwortung zum Auftraggeber und benötigt langfristige Produktpflege.
Wann H-Studio nicht der richtige Partner ist
H-Studio ist nicht der richtige Fit, wenn ein vorhandenes SaaS-Portal mit Standardkonfiguration bereits 90 % der Aufgabe löst, das Budget nur für einen klickbaren Prototyp reicht oder dauerhaft ein großes Enterprise-Programm mit vielen parallelen Teams besetzt werden muss. In diesen Fällen sind Implementierungspartner des Standardprodukts, ein No-Code-Spezialist oder eine größere Beratung meist passender.
Wir passen zu Vorhaben, bei denen externe Nutzeroberfläche und internes Backoffice als ein System entworfen werden müssen. Unsere Kundenportal-Entwicklung beginnt mit Rollen, Workflows, Daten und Integrationen. Breitere Systeme mit mehreren Oberflächen gehören eher zu Custom Platforms.
Häufige Fragen
Was kostet ein einfaches Kundenportal?
Eine fokussierte erste Version mit Login, einem klaren Rollenmodell, Dokumenten oder Status, Basis-Admin, Deployment und Handover liegt nach H-Studio-Erfahrung häufig bei 20.000–40.000 € netto. Ein reiner geschützter Contentbereich kann günstiger sein, ist aber kein individuelles Prozessportal.
Was treibt die Kosten eines B2B-Portals am stärksten?
Die größten Treiber sind Anzahl und Komplexität der Rollen, Tenant-Isolation, Dokumentenlogik, Zustands-Workflows, Datenmigration und Integrationen. SSO, Audit-Anforderungen und mehrere Datenquellen erhöhen Test- und Betriebsaufwand. Das visuelle Dashboard ist selten der wichtigste Kostentreiber.
Wie lange dauert die Entwicklung?
Ein Basis-Portal kann in etwa 6–10 Wochen entstehen, wenn Scope und Integrationen klar sind. Mehrere Rollen, CRM-Synchronisation und komplexe Workflows liegen häufig bei 10–16 Wochen. Datenmigration, SSO, externe Freigaben oder unklare Altsysteme können den Zeitrahmen verlängern.
Sollte man ein Kundenportal kaufen oder bauen lassen?
Kaufen oder konfigurieren ist meist richtig, wenn ein Standardprodukt den Prozess weitgehend abbildet. Individuelle Entwicklung lohnt sich, wenn das Portal proprietäre Workflows, mehrere Systeme oder ein differenziertes Kundenmodell verbinden muss. Vor dem Build sollten mindestens zwei passende Standardlösungen gegen den Custom-Scope geprüft werden.
Gehört ein Admin-Bereich immer zum Portal?
Fast jedes operative Portal braucht eine interne Oberfläche, auch wenn sie in der ersten Version klein ist. Mitarbeitende müssen Nutzer freigeben, Status korrigieren, Dokumente prüfen und Ausnahmefälle bearbeiten können. Ohne Admin-Layer wandert diese Arbeit zurück in E-Mail, Tabellen oder direkte Datenbankeingriffe.
Ist EU-Hosting für ein Kundenportal Pflicht?
Nicht pauschal. Relevant sind die verarbeiteten Daten, Verantwortlichkeiten, Auftragsverarbeiter und mögliche Drittlandübermittlungen. EU-/EWR-Hosting kann Datenflüsse und Procurement vereinfachen. Die konkrete rechtliche Bewertung und Verträge müssen zum tatsächlichen Setup passen.
— Anna
Lektoriert und auf technische Plausibilität geprüft von Anna Hartung. Die Preisrahmen sind unverbindliche H-Studio-Erfahrungswerte für B2B-Projekte, keine verbindlichen Angebote. Datenschutz-Hinweise sind keine Rechtsberatung.