Was kostet ein Kundenportal? Drei Treiber, ein Festpreis

Ein Kundenportal kostet bei uns ab 22.000 € als Festpreis nach Briefing, sprint-basiert, ab zehn Wochen bis zur ersten produktiven Version. Nach oben offen ist die Zahl, weil drei Dinge den Aufwand bestimmen: die Fachlogik hinter dem Login, die Schnittstellen zu den Systemen, die deine Daten heute halten, und der Betrieb danach.

Dieser Beitrag legt die drei Treiber offen. Damit kannst du vor dem ersten Gespräch einschätzen, wo dein Projekt liegt, und ob du überhaupt ein eigenes Portal brauchst. Bei etwa jedem dritten Erstgespräch zu diesem Thema lautet unsere Antwort nämlich: noch nicht.

Was ist ein Kundenportal, und was ist es nicht?

Ein Kundenportal ist ein geschlossener Bereich deiner Website, in dem sich ein Kunde anmeldet und nur seine eigenen Daten sieht: Aufträge, Rechnungen, Verträge, Lieferstatus, Termine, Dokumente. Und in dem er etwas auslösen kann, das bei dir einen Prozess startet: eine Nachbestellung, eine Freigabe, eine Reklamation, einen Terminwunsch.

Der Begriff deckt sehr unterschiedliche Dinge ab, und die Spanne im Preis kommt genau daher:

• Dokumentenportal: Der Kunde lädt Rechnungen, Verträge und Nachweise herunter. Eine Datenquelle, zwei Rollen (Kunde, Verwaltung), kein Schreiben zurück ins System.
• Auftrags- oder Serviceportal: Der Kunde sieht Status und Historie, löst Nachbestellungen oder Serviceanfragen aus, die in deiner Warenwirtschaft oder deinem Ticketsystem landen.
• Händlerportal: Ein B2B-Shop mit Login, kundenspezifischen Preisen, Staffeln, Freigabeketten und Budgetgrenzen je Nutzer. Technisch ein Shop mit Rechtesystem, deshalb steht er bei uns in derselben Preisstufe.
• Mandantenportal: Mehrere Firmen mit jeweils mehreren Nutzern, jede mit eigenen Rechten. Das ist die teuerste Form, weil jede Ansicht dreifach geprüft werden muss: Wer darf das sehen, wer darf das ändern, wer darf das freigeben.

Nicht gemeint ist der Kundenbereich, den ein Onlineshop ohnehin mitbringt. „Mein Konto“ in WooCommerce zeigt Bestellungen, Adressen und Downloads. Wenn das reicht, brauchst du kein Portal, sondern einen gut gebauten Shop.

Warum gibt es keinen Listenpreis?

Weil dieselbe Beschreibung „Kunden sollen ihre Aufträge sehen“ ein Projekt für sechs Wochen oder für sechs Monate sein kann. Der Unterschied liegt nicht im Design und nicht in der Anzahl der Seiten, sondern in drei Treibern:

• Fachlogik. Hält den Preis unten: zwei Rollen, Daten werden nur angezeigt. Treibt ihn nach oben: Freigabeketten, Budgets je Nutzer, Mandanten, Fristen und Erinnerungen, Sonderfälle je Kundengruppe.
• Schnittstellen. Unten: eine Datenquelle mit dokumentierter API. Oben: mehrere Systeme, kein API-Zugang (nur Exporte), Daten in beide Richtungen, Zahlungsabwicklung.
• Betrieb. Unten: Portal für Geschäftskunden, klare Bürozeiten. Oben: Verbraucher als Nutzer, Erreichbarkeit rund um die Uhr, Nachweispflichten, hohe Datenmengen.

Der teuerste Einzelposten sind aus unserer Erfahrung fast immer die Schnittstellen. Ein einzelner Aufruf gegen eine Warenwirtschaft ist an einem Nachmittag geschrieben. Ihn robust zu machen, dauert Wochen: Was passiert, wenn das ERP nachts nicht antwortet? Wenn ein Artikel dort gelöscht wurde, aber im Portal noch in einem offenen Auftrag steht? Wenn die Preise sich ändern, während der Kunde gerade bestellt? Jede dieser Fragen braucht eine Antwort im Code und einen Test, der sie belegt.

Wo liegen die Zahlen?

Unsere Preisstufen stehen offen auf der Webdesign-Seite, und sie zeigen, warum ein Portal nicht in der Mitte liegt:

In der Plattform-Stufe stecken laut Preisseite individuelle Funktionen, die API-Anbindung an CRM oder ERP, Konfiguratoren und Login-Bereich, ein Performance-SLA und ein Wartungsvertrag, sprint-basiert ab zehn Wochen.

Der Sprung von 9.800 € auf 22.000 € ist kein Aufschlag für das Wort „Portal“. Sobald sich jemand anmeldet, ändert sich die Arbeit: Jede Ansicht braucht eine Rechteprüfung, jede Schnittstelle eine Fehlerbehandlung, jede Funktion einen Test mit echten Daten, und das Ganze eine Dokumentation, die auch in drei Jahren noch jemand versteht. Diese Arbeit ist unsichtbar, und sie ist der Grund, warum billige Portale nach dem zweiten Update kaputtgehen.

Innerhalb der Stufe sortieren sich die Projekte grob so:

• Am unteren Ende: ein Dokumentenportal mit einer Datenquelle, zwei Rollen, Lesezugriff.
• In der Mitte: ein Auftragsportal mit ERP-Anbindung, Status, Historie, Nachbestellung, kundenspezifischen Preisen.
• Oben: ein mandantenfähiges Portal mit Freigabe-Workflows, mehreren Schnittstellen und Zahlungsabwicklung.

Was dein Projekt kostet, steht nach dem Briefing als Festpreis im Angebot. Kein offenes Stundenkonto, keine Überraschung auf der Schlussrechnung. Wenn dir jemand vor dem Briefing eine Zahl nennt, hat er entweder deine Systeme nicht gefragt oder plant den Nachtrag schon ein.

Wann reicht Standardsoftware?

Häufiger, als Agenturen zugeben. Prüfe diese vier Punkte, bevor du ein eigenes Portal in Auftrag gibst:

1. Bringt dein ERP oder CRM ein Portalmodul mit? Viele Systeme haben eines, oft gegen Lizenz je Nutzer. Wenn deine Prozesse darin abbildbar sind, ist das der schnellste Weg.
2. Ist dein Fall Standard? Tickets, Dokumente, Abo-Verwaltung, Termine: Dafür gibt es fertige Werkzeuge, die pro Monat kosten, was ein Portal pro Tag kostet.
3. Reicht der Kundenbereich des Shops? Für Bestellungen, Adressen und Rechnungen ja. Für Staffelpreise je Kunde und Freigabeketten gibt es Erweiterungen, die einen Teil eines Händlerportals abdecken.
4. Hängt nur ein System dahinter? Dann ist die teuerste Arbeit, die Schnittstelle, überschaubar, und der Vorteil eines eigenen Baus schrumpft.

Ein eigenes Portal lohnt sich, wenn mindestens zwei der folgenden Punkte zutreffen: Mehrere Systeme müssen zusammenspielen. Deine Preis- oder Prozesslogik ist der Wettbewerbsvorteil und lässt sich in keiner Standardsoftware abbilden. Die Lizenz je Nutzer würde bei deiner Kundenzahl mehr kosten als der Bau. Oder die Daten sollen auf deinem Server in Deutschland bleiben, ohne einen Anbieter dazwischen, der den Dienst einstellen oder den Preis anziehen kann.

Was gehört in die Anfrage, damit ein Festpreis möglich ist?

Je genauer diese sieben Punkte beantwortet sind, desto belastbarer ist das Angebot. Und desto weniger Erstgespräch brauchst du:

1. Nutzergruppen und Anzahl: Wer meldet sich an, wie viele sind es heute, wie viele in zwei Jahren? Geschäftskunden, Verbraucher, beides?
2. Systeme dahinter: Name der Warenwirtschaft, des CRM, der Buchhaltung. Und die entscheidende Frage: Gibt es eine dokumentierte Schnittstelle, oder nur Exporte?
3. Datenobjekte: Was soll der Kunde sehen? Aufträge, Rechnungen, Lieferscheine, Verträge, Zählerstände, Termine.
4. Aktionen: Was soll er auslösen können? Nachbestellen, freigeben, reklamieren, hochladen, kündigen.
5. Rollen und Freigaben: Darf ein Einkäufer bestellen, aber erst ab einer Summe mit Freigabe der Geschäftsführung? Solche Sätze sind Gold für ein Angebot.
6. Rechtlicher Rahmen: Verbraucher als Nutzer, personenbezogene Daten, Rechnungen im Portal. Dazu gleich mehr.
7. Betrieb: Wer hostet, wer beantwortet Supportfragen, welche Reaktionszeit brauchst du?

Wer diese Liste nicht beantworten kann, ist nicht zu früh dran. Dann klären wir sie im Erstgespräch, und das Angebot kommt danach.

Welche Pflichten hängen am Login?

Drei Rechtsbereiche entscheiden mit über Umfang und Preis, und sie gehören ins Briefing, nicht in den Nachtrag:

Datenschutz. Hinter dem Login liegen personenbezogene Daten, oft Vertrags- und Zahlungsdaten. Die DSGVO verlangt dafür technische und organisatorische Maßnahmen nach Art. 32: verschlüsselte Übertragung, Protokollierung von Zugriffen, ein Rechtekonzept, Löschfristen. Wer hostet, braucht einen Vertrag zur Auftragsverarbeitung. Eine gute Nachricht: Der Sitzungs-Cookie eines Logins ist nach § 25 Abs. 2 Nr. 2 TDDDG unbedingt erforderlich und braucht keine Einwilligung. Ein Portal kommt ohne Cookie-Dialog aus, solange kein Tracking dazukommt.

Barrierefreiheit. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 für Dienstleistungen im elektronischen Geschäftsverkehr, die Verbrauchern erbracht werden (§ 1 Abs. 3 Nr. 5 BFSG). Ein Portal nur für Geschäftskunden fällt nicht darunter. Sobald sich Endkunden anmelden, um Verträge zu verwalten oder zu bestellen, schon. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen (§ 3 Abs. 3 BFSG). Wir bauen Portale ohnehin nach WCAG 2.2 AA, weil ein Rechtesystem mit Tastatur bedienbar sein muss, sonst ist es kaputt. Was das im Detail heißt, steht auf unserer Seite zur barrierefreien Website.

E-Rechnung. Wenn das Portal Rechnungen an Unternehmen ausliefert, reicht ein PDF nicht mehr lange. Seit dem 1. Januar 2025 müssen Unternehmen E-Rechnungen empfangen können, die Pflicht zur Ausstellung folgt gestaffelt 2027 und 2028. Ein Portal, das heute gebaut wird, sollte XRechnung oder ZUGFeRD ausgeben können. Die Fristen und Formate haben wir auf der Seite zur E-Rechnung zusammengefasst.

Wie läuft so ein Projekt bei uns?

Sprint-basiert heißt: Alle zwei Wochen gibt es etwas, das du anklicken kannst, und du entscheidest mit, was als Nächstes kommt.

1. Briefing und Datenmodell. Welche Systeme, welche Felder, welche Rollen. Das Ergebnis ist ein Dokument, das auch ein anderer Dienstleister umsetzen könnte. Danach steht der Festpreis.
2. Klick-Prototyp. Die Ansichten je Rolle, ohne echte Daten. Hier fallen die meisten Missverständnisse auf, und hier sind sie billig.
3. Schnittstellen zuerst. Das größte Risiko wird als Erstes gebaut, nicht als Letztes. Wenn das ERP nicht liefert, was der Katalog verspricht, wissen wir es in Woche drei, nicht in Woche neun.
4. Fachlogik und Rechte. Freigaben, Grenzen, Sonderfälle. Jede Regel bekommt einen Test, der sie belegt.
5. Test mit echten Daten. Deine Mitarbeiter arbeiten zwei Wochen im Portal, bevor ein Kunde es sieht.
6. Betrieb. Managed Hosting in Deutschland, Updates auf Staging getestet, Notfall-Erreichbarkeit. Das läuft über unsere Wartungspakete; für geschäftskritische Anwendungen ist die Stufe Premium ab 349 € im Monat die richtige.

Der Code gehört dir. Du bist nicht davon abhängig, dass wir als Agentur weiter existieren, um dein Portal zu betreiben.

Dass wir das nicht nur für Kunden bauen, sondern selbst betreiben, gehört hier offengelegt: Rechnungslotse ist unser eigenes Produkt, ein E-Rechnungs-Dienst mit Assistent und Live-Vorschau, XRechnung 3.0, ZUGFeRD 2.5, Validierung nach EN 16931 und GoBD-Archiv, von der Skizze bis zum Abo. Jede Falle, die in diesem Beitrag steht, haben wir dort selbst gefunden. Für den Onlineshop von Sieslack in Hamburg gilt dasselbe für die Kundenseite eines Shops mit angebundenem Systemhaus.

Kurz zusammengefasst

• Ein Kundenportal kostet bei uns ab 22.000 € als Festpreis nach Briefing, sprint-basiert ab zehn Wochen. Nach oben bestimmen Fachlogik, Schnittstellen und Betrieb den Preis, nicht das Design.
• Die Schnittstellen sind meist der größte Posten: nicht das Anbinden, sondern das Absichern gegen Ausfälle und Widersprüche zwischen den Systemen.
• Prüfe vorher, ob dein ERP ein Portalmodul mitbringt oder der Kundenbereich deines Shops reicht. Ein eigener Bau lohnt sich ab zwei von vier Gründen: mehrere Systeme, eigene Prozesslogik, Lizenzkosten je Nutzer, Datenhoheit.
• Sieben Angaben machen ein Festpreisangebot möglich: Nutzer, Systeme, Datenobjekte, Aktionen, Rollen, Rechtsrahmen, Betrieb.
• Am Login hängen DSGVO (Art. 32), bei Verbrauchern das BFSG (§ 1 Abs. 3 Nr. 5, Ausnahme § 3 Abs. 3) und bei Rechnungen an Unternehmen die E-Rechnung. Der Sitzungs-Cookie selbst braucht keine Einwilligung.
• Preisstufen und Gesetzesstellen: Stand 13. September 2026. Prüfe sie nach, bevor du auf ihrer Grundlage entscheidest.