Kundenportal entwickeln lassen: Funktionen, Kosten, Ablauf

Irgendwann kippt es: Kunden fragen per E-Mail nach dem Auftragsstatus, Dokumente werden zum dritten Mal verschickt, das Team beantwortet dieselben Fragen in Dauerschleife. Ein Kundenportal löst genau das – ein geschützter Bereich, in dem deine Kunden selbst finden, anstoßen und einsehen, wofür sie heute anrufen müssen.

Dieser Artikel beantwortet die drei Fragen, die vor jedem Portalprojekt stehen: Was soll es können, was kostet es, und wie läuft die Entwicklung ab – inklusive der ehrlichen Vorfrage, ob es überhaupt eine Individualentwicklung sein muss.

Kundenportal, Lieferantenportal, Partnerportal – derselbe Bau, andere Nutzer

Bevor es um Funktionen geht, eine Begriffsklärung, die in Angeboten oft untergeht. Wir werden regelmäßig nach einem „Lieferantenportal” oder einem „Partnerportal” gefragt, als wären das andere Projekte. Sind sie technisch nicht. Alle drei bestehen aus denselben Teilen: geschützter Zugang, Konten mit abgestuften Rechten, Vorgänge mit Status, Dokumente, Schnittstellen zu den Systemen, in denen die Daten wirklich liegen.

Was sich unterscheidet, ist die Nutzergruppe – und daraus folgen Rechte und Datenumfang:

• Kundenportal. Kunden sehen ihre Aufträge, Rechnungen, Lieferungen, Tickets.
• Lieferantenportal. Lieferanten sehen Bestellungen, bestätigen Liefertermine, laden Zertifikate und Dokumente hoch. Hier fließen Daten häufiger herein als heraus.
• Partner- oder Händlerportal. Partner sehen Preislisten, Leads, Provisionen, Schulungsmaterial – oft mit eigener Preis- und Rabattlogik.
• Serviceportal. Der Schwerpunkt liegt auf Tickets, Wartungsverträgen, Geräteakten und Dokumentation.

Das ist mehr als eine Begriffsübung, weil es direkt auf die Kosten durchschlägt. Wer Kunden und Lieferanten bedienen will, braucht nicht zwei Portale, sondern eines mit zwei Rollenbereichen. Zwei getrennte Anwendungen bedeuten doppeltes Hosting, doppelte Updates, doppelte Anmeldelogik und zwei Stellen, an denen die ERP-Anbindung brechen kann. Wir haben das ein paar Mal auseinandergebaut, nachdem es getrennt gestartet war – das ist teurer als es einmal richtig zu schneiden.

Was ein Kundenportal leisten kann

„Kundenportal” ist ein Sammelbegriff. In der Praxis setzen sich Portale aus einer Handvoll wiederkehrender Bausteine zusammen – und die Kunst liegt darin, nur die zu bauen, die deinen Engpass treffen:

• Konten und Rollen. Kunden melden sich an und sehen genau das, was sie sehen dürfen – vom Einzelkunden bis zur Kundenfirma mit mehreren Benutzern und abgestuften Rechten.
• Status und Vorgänge. Aufträge, Projekte, Tickets oder Lieferungen mit aktuellem Stand – die häufigste Portalfunktion, weil sie die häufigste Anrufursache ersetzt.
• Dokumente. Rechnungen, Verträge, Berichte, Zertifikate – zentral abgelegt statt per E-Mail verstreut, mit Zugriff nur für den richtigen Kunden.
• Anfragen und Aufträge. Strukturierte Formulare statt Freitext-E-Mails: Neue Bestellung, Support-Fall, Terminwunsch – mit den Pflichtangaben, die dein Team sonst nachfragen müsste.
• Schnittstellen. Der Baustein, der über den Nutzen entscheidet: Das Portal zeigt Daten aus ERP, CRM oder Warenwirtschaft – statt dass jemand sie doppelt pflegt. Ohne Anbindung ist ein Portal nur eine weitere Insel.
• Abrechnung und Verträge. Vom Einsehen offener Posten bis zur Selbstverwaltung von Vertragsdaten – je nach Geschäftsmodell.

Der Engpass-Test: Lohnt sich das Portal überhaupt?

Wir fangen Portalgespräche gern mit der Frage an, die ein Angebot eigentlich verhindern kann: Welchen konkreten Engpass soll das Portal wegnehmen? Wenn darauf keine Antwort kommt, die sich zählen lässt, ist das Projekt noch nicht reif – und ein teures Portal ohne Anwendungsfall nutzt niemandem, uns eingeschlossen.

Zählen lässt es sich mit Zahlen, die in deinem Unternehmen liegen, nicht in einer Branchenstudie. Nimm dir eine normale Woche und notiere:

1. Wie viele Anfragen erreichen dein Team, die reine Statusauskunft sind? („Wo ist meine Lieferung?“, „Ist die Rechnung durch?”, „Habt ihr die Unterlagen?“)
2. Wie lange dauert eine davon im Schnitt, inklusive Nachschauen im ERP und Zurückschreiben?
3. Wie oft wird derselbe Datensatz an zwei Stellen eingegeben, weil zwei Systeme nicht miteinander sprechen?

Aus Punkt 1 und 2 ergibt sich die Zeit pro Woche, die heute in Auskünften steckt. Hochgerechnet auf ein Jahr und bewertet mit dem internen Stundensatz steht dem Portalbudget eine echte Zahl gegenüber – deine, nicht unsere. Wir nennen hier bewusst keinen Prozentsatz an Entlastung, weil der von deiner Kundenstruktur abhängt und jede fremde Zahl an dieser Stelle geraten wäre.

Zwei Dinge sind bei dieser Rechnung wichtig. Erstens: Ein Portal entfernt Statusanfragen nicht vollständig. Es verschiebt sie – ein Teil der Kunden wird weiter anrufen, besonders am Anfang. Realistisch ist, dass die einfachen, wiederholten Auskünfte wegfallen und die inhaltlichen Gespräche bleiben. Zweitens: Punkt 3 ist oft der größere Hebel als Punkt 1, wird aber selten mitgerechnet. Doppelte Dateneingabe kostet nicht nur Zeit, sondern produziert Abweichungen zwischen Systemen, die später jemand aufräumt.

Wenn die Rechnung dünn aussieht, ist das ein gutes Ergebnis. Dann baut man kein Portal, sondern beseitigt den Engpass anders – mit einem besseren Statusmail-Automatismus, einer Suchfunktion im bestehenden System oder einem aufgeräumten Dokumentenversand.

Fertiglösung, Individualentwicklung oder Ausbau des Bestands

Nicht jedes Unternehmen braucht ein individuelles Portal, und wer dir ohne diese Prüfung eines verkauft, berät dich schlecht. Fertige Portal-Baukästen und Branchenlösungen sind schneller live und günstiger im Einstieg – und völlig ausreichend, wenn deine Prozesse dem Standard entsprechen und die Daten nicht tief mit deinen Systemen verzahnt sein müssen.

Individuell wird es aus drei Gründen:

1. Deine Prozesse sind dein Vorteil. Wenn das Portal genau abbilden soll, wie dein Unternehmen tatsächlich arbeitet – nicht, wie ein Softwareanbieter sich Unternehmen vorstellt.
2. Schnittstellen sind Pflicht. Sobald ERP, CRM oder Warenwirtschaft angebunden werden, entscheidet die Integrationstiefe – und da stoßen Baukästen schnell an Grenzen.
3. Datenhoheit. Ein eigenes Portal läuft auf deiner Infrastruktur, mit deinen Daten, ohne Abhängigkeit von Preismodell und Roadmap eines Anbieters.

Die Prüffrage in einem Satz: Passt du dein Unternehmen dem Werkzeug an – oder das Werkzeug deinem Unternehmen? Ersteres spricht für die Fertiglösung, letzteres für die Individualentwicklung.

Es gibt eine dritte Option, die in Vergleichen fast immer fehlt: das Portal im System, das du schon hast. Viele ERP-, CRM- und Shop-Systeme bringen ein Kundenkonto mit, das deutlich mehr kann, als die meisten Unternehmen davon nutzen. Bevor etwas Neues gebaut wird, lohnt der Blick auf das Bestehende – ein freigeschaltetes Kundenkonto im Shop oder ein aktiviertes Serviceportal im ERP kostet einen Bruchteil und ist in Wochen statt Monaten nutzbar. Die Grenze dieser Option ist meist das Design und die Flexibilität der Rechte: Du bekommst, was der Hersteller vorgesehen hat, in dessen Optik, mit dessen Begriffen. Für ein Portal, das reine Auskunft gibt, reicht das oft. Für ein Portal, das Teil deines Angebots ist und wie dein Unternehmen aussehen soll, nicht.

	Fertiglösung	Bestehendes System	Individualentwicklung
Zeit bis live	Wochen	Tage bis Wochen	2–4 Monate (erste Version)
Einstiegskosten	niedrig	sehr niedrig	ab 10.000 €
Laufende Kosten	Lizenz pro Nutzer/Monat	meist enthalten	Hosting + Pflege
Prozesse	du passt dich an	du passt dich an	Abbild deiner Abläufe
Schnittstellen	nach Angebot des Anbieters	nur innerhalb des Systems	frei, aber zu bauen
Optik und Begriffe	Anbieter-Standard	Anbieter-Standard	deine
Datenhoheit	beim Anbieter	beim Anbieter	bei dir
Abhängigkeit	Preismodell und Roadmap	Herstellerentscheidungen	Wartbarkeit des Codes

Die letzte Zeile ist die, die am häufigsten unterschätzt wird. Individualentwicklung tauscht die Abhängigkeit von einem Anbieter gegen die Abhängigkeit von wartbarem Code und einem Team, das ihn pflegt. Das ist in der Regel die bessere Abhängigkeit, aber sie ist keine Freiheit.

Welche Funktion zuerst gebaut wird

Die Reihenfolge ist bei Portalprojekten wichtiger als der Umfang. Unsere Regel: Die erste Version enthält einen Anwendungsfall vollständig, nicht fünf halb.

Für die Priorisierung hilft eine schlichte Gegenüberstellung – wie oft tritt der Fall auf, und wie teuer ist er heute? Statusauskunft landet dabei fast immer oben: hohe Häufigkeit, kleiner Bauaufwand, sofort spürbar. Dokumentenzugriff folgt meist direkt danach, weil er dieselbe Rechtelogik nutzt, die für den Status ohnehin gebaut wird.

Was in die erste Version gehört:

• Anmeldung inklusive Passwort-zurücksetzen (das wird erstaunlich oft vergessen und dann im Livebetrieb nachgeschoben)
• die eine Kernfunktion, die den Engpass löst
• die eine Schnittstelle, die diese Funktion mit echten Daten versorgt
• ein Minimum an Verwaltung für dein Team: Nutzer anlegen, freischalten, sperren

Was bewusst wartet: Benachrichtigungen in jeder Variante, Self-Service für Vertragsdaten, Dashboards mit Auswertungen, mobile App, Mehrsprachigkeit, Einzelrechte pro Feld. Das sind alles sinnvolle Dinge. Sie sind nur nicht sinnvoll, bevor echte Nutzer im Portal waren – weil danach ein Teil dieser Liste anders aussieht. Wir haben noch kein Portal erlebt, bei dem die Prioritäten nach dem ersten Monat Livebetrieb dieselben waren wie im Workshop.

Anmeldung und Rechte: der unterschätzte Teil

In Angeboten steht „Login und Benutzerverwaltung” meist als einzelner Punkt. In der Umsetzung ist es der Bereich, der die Kosten am stärksten streut – zwischen „ein Nachmittag” und „ein Viertel des Projekts”.

Wie sich Nutzer anmelden

Die Entscheidung über das Anmeldeverfahren wirkt sich auf Aufwand, Sicherheit und Akzeptanz aus:

• E-Mail und Passwort, dazu Zwei-Faktor. Der Standardfall. Günstig, verstanden, überall einsetzbar. Für Portale mit Geschäftsdaten gehört der zweite Faktor dazu, nicht als Option.
• Magic Link. Anmeldung per Einmal-Link in der E-Mail, ohne Passwort. Angenehm für Nutzer, die sich selten anmelden – typisch für Portale, in die Kunden viermal im Jahr schauen. Weniger geeignet, wenn täglich gearbeitet wird.
• Single Sign-on über den Firmenzugang des Kunden. Wenn deine Kunden größere Unternehmen sind, wird das irgendwann gefordert: Anmeldung über den Microsoft- oder Google-Account des Kunden, oft über OAuth2 oder SAML. Technisch machbar und sinnvoll – aber jeder angebundene Identitätsanbieter ist eigener Aufwand, und bei SAML kommt Koordination mit der IT-Abteilung deines Kunden dazu. Das gehört in die Kostenplanung, nicht in die Wunschliste.
• Passkeys. Anmeldung über Fingerabdruck oder Geräteschlüssel statt Passwort. Für Portale mit regelmäßigen Nutzern inzwischen eine ernsthafte Option, weil sie Phishing strukturell ausschließt.

Unsere Empfehlung für die erste Version: Passwort plus Zwei-Faktor, sauber gebaut, mit der Architektur so angelegt, dass SSO später ergänzt werden kann. SSO von Anfang an zu bauen, bevor ein Kunde danach gefragt hat, ist in der Regel Geld, das besser in die Kernfunktion geht.

Das Rollenmodell

Hier liegt die größte Kostenfalle des ganzen Projekts, und sie klingt harmlos. „Jeder Kunde sieht seine Daten” ist ein einfacher Satz und eine einfache Implementierung. „Kundenfirmen haben Admin-Benutzer, die ihren Kollegen Rechte geben können” ist ein anderes Projekt.

Der Unterschied: Im ersten Fall gehört ein Datensatz einem Nutzer. Im zweiten Fall gehört er einer Organisation, Nutzer gehören zu Organisationen, Rechte hängen an der Kombination – und jede Abfrage im System muss das korrekt berücksichtigen. Übersieht man eine einzige Stelle, sieht ein Kunde die Daten eines anderen. Das ist der Fehler, der ein Portal nicht langsam oder unschön macht, sondern unbrauchbar.

Deshalb zwei Dinge, die wir nicht verhandeln: Zugriffsregeln werden zentral definiert, nicht pro Seite neu – in Laravel über Policies. Und sie werden getestet, mit automatisierten Tests, die genau das prüfen: Nutzer A ruft die Daten von Nutzer B auf und bekommt eine Absage. Diese Tests sind ein Teil dessen, was Testabdeckung im Angebot kostet, und sie sind der Posten, bei dem Sparen am teuersten wird.

Die Fragen, die das Rollenmodell festlegen, sind unspektakulär und sollten vor dem Angebot geklärt sein: Kann ein Nutzer zu mehreren Kundenfirmen gehören? Was passiert mit seinen Vorgängen, wenn er das Unternehmen verlässt? Darf ein Kunde Kollegen selbst einladen oder macht das dein Team? Gibt es Nutzer, die nur lesen dürfen? Und braucht dein Support die Möglichkeit, die Portalansicht eines Kunden einzunehmen, um bei Rückfragen dasselbe zu sehen? Die letzte Frage wird fast immer erst nach dem Livegang gestellt – und ist nachträglich teurer als vorher.

Schnittstellen: hier entscheidet sich das Projekt

Die Anbindung an ERP oder CRM ist erfahrungsgemäß der Teil mit den meisten Überraschungen – veraltete APIs, fehlende Dokumentation, Datenqualität. Deshalb gehört sie an den Anfang des Projekts, nicht ans Ende: Erst wenn klar ist, welche Daten zuverlässig fließen, lohnt sich der Ausbau der Oberfläche darüber.

Wie das konkret aussieht, zeigt ein Projekt aus unserer Arbeit, das kein Portal ist, aber dasselbe Problem hatte: Für Tekath Headhunting haben wir eine Website an das Branchensystem HR4You angebunden. Das Zielsystem war der Website von Haus aus unbekannt, also haben wir eine eigene Integration gebaut, die regelmäßig Daten zieht, auf das eigene Datenmodell abbildet, zwischenspeichert und den Cache synchron hält. Tekath pflegt Stellen nur noch in HR4You; auf der Website erscheinen sie automatisch. Genau dieser Dreischritt – ziehen, abbilden, synchron halten – ist auch die Arbeit hinter jeder Portal-Schnittstelle. Der Aufwand steckt nicht im Abrufen der Daten. Er steckt im Abbilden und im Synchronhalten.

Drei Muster gibt es, und sie unterscheiden sich stark im Aufwand:

• Das Portal fragt live beim System nach. Immer aktuell, keine doppelte Datenhaltung. Setzt voraus, dass das Zielsystem schnell und verfügbar genug ist – fällt das ERP aus, zeigt das Portal nichts. Für Mittagspausen-Wartungsfenster im ERP ein Problem.
• Das Portal holt sich die Daten regelmäßig und speichert sie. Robust, schnell, funktioniert auch wenn das ERP kurz weg ist. Dafür sind die Daten so aktuell wie der letzte Abgleich, und du brauchst eine Antwort auf die Frage, was bei Konflikten gilt.
• Das System meldet Änderungen aktiv ans Portal. Die sauberste Variante, wenn das Zielsystem sie anbietet. Viele mittelständische ERP-Systeme tun das nicht.

Fast alle Portale, die wir gebaut oder angesehen haben, laufen auf einer Mischung: Stammdaten regelmäßig abgleichen, Status live abfragen. Diese Entscheidung ist keine Geschmacksfrage, sie hängt am Zielsystem – und deswegen steht sie vor dem Angebot, nicht darin.

Die Fragen, die du deinem Systemanbieter stellst

Dieser Teil lässt sich gut vorbereiten, bevor überhaupt eine Agentur im Raum ist. Je mehr davon beantwortet ist, desto belastbarer wird jedes Angebot, das du bekommst – unser eigenes eingeschlossen:

1. Gibt es eine dokumentierte Programmierschnittstelle, und bekomme ich die Dokumentation vorab zu sehen?
2. Kostet der Zugang extra – als Lizenz, Modul oder pro Abfrage?
3. Gibt es ein Testsystem, oder wird gegen die Produktivdaten entwickelt?
4. Welche Felder liefert die Schnittstelle wirklich? (Nicht: welche gibt es im System.)
5. Gibt es eine Begrenzung, wie oft abgefragt werden darf?
6. Werden Änderungen aktiv gemeldet, oder muss regelmäßig nachgefragt werden?
7. Wer ist beim Systemanbieter technischer Ansprechpartner, und wie schnell antwortet er?

Frage 4 und Frage 7 sind die, die am meisten Geld bewegen. Dass eine Schnittstelle existiert, sagt wenig darüber, ob sie die Felder herausgibt, die dein Portal zeigen soll. Und ein Projekt, das auf Antworten eines externen Anbieters wartet, steht still – unabhängig davon, wie gut das Entwicklungsteam ist. „Das ERP hat doch eine API” ist der teuerste Satz im Portalgeschäft, weil er eine Prüfung ersetzt, die niemand gemacht hat.

Rechne außerdem damit, dass die Datenqualität im Zielsystem schlechter ist als angenommen. Kundennummern, die doppelt vorkommen, Adressen in einem Freitextfeld, Status, die historisch gewachsen sind und von zwei Abteilungen unterschiedlich benutzt werden – das ist der Normalfall, nicht die Ausnahme. Ein Portal legt diese Dinge offen, weil es Daten erstmals den Kunden zeigt, über die sie handeln. Diese Aufräumarbeit gehört ins Budget.

Die Technik dahinter: warum wir Portale mit Laravel bauen

Ein Kundenportal ist im Kern eine Webanwendung aus Authentifizierung, Rechteverwaltung, Datenzugriff und Schnittstellen. Genau diese Bausteine bringt Laravel als ausgereiftes PHP-Framework mit: Login samt Zwei-Faktor, Policies für feingranulare Zugriffsregeln, Queues für Hintergrundjobs wie PDF-Erzeugung oder Datenabgleich, und ein sauberes Fundament für API-Anbindungen in beide Richtungen. Warum das gerade für Unternehmen die wirtschaftlich vernünftige Wahl ist, haben wir in Warum Laravel für Unternehmen? ausführlich begründet.

Zwei Architekturfragen entscheiden früh über Kosten und Tragfähigkeit:

Mandantenfähigkeit. Bedient das Portal mehrere Kundenfirmen, die jeweils eigene Benutzer und strikt getrennte Daten haben, ist das eine Multi-Tenancy-Architektur – und die will von Anfang an mitgedacht sein, nicht nachgerüstet. Welche Varianten es gibt und wann welche passt, steht in unserem Grundlagenartikel zu Laravel Multi-Tenancy.

Schnittstellen zuerst. Siehe oben: Erst wenn klar ist, welche Daten zuverlässig fließen, lohnt sich der Ausbau der Oberfläche darüber.

Ein Teil, der in Portalangeboten regelmäßig fehlt, ist die Innenseite. Jedes Portal braucht eine Verwaltung für dein Team: Nutzer freischalten, Vorgänge nachschauen, Dokumente hochladen, Daten korrigieren, wenn die Schnittstelle Unsinn geliefert hat. Diese Innenseite ist Aufwand, den man sehen muss, und sie wird gern vergessen, weil sie im Verkaufsgespräch niemandem gezeigt wird. Wir bauen sie, wo es passt, mit Filament – einem Admin-Baukasten für Laravel, der Listen, Formulare und Rechte aus dem Datenmodell erzeugt, statt sie von Hand zu bauen. Das spart an einer Stelle Geld, an der individuelle Gestaltung keinen Nutzen bringt: Dein Team braucht eine schnelle, zuverlässige Verwaltungsoberfläche, kein Designstück.

Wie ein mandantenfähiges System real aussieht, zeigt unser eigenes Produkt Rentlytics: eine Laravel-Plattform, die Mietspiegelrechner für mehrere Kommunen und Wohnungsunternehmen aus einer Codebase bedient, als gehostete Lösung oder als einbettbare Web-Component. Dabei haben wir uns bewusst gegen ein fertiges Tenancy-Package entschieden – die Begründung, und wann diese Entscheidung andersherum ausfällt, steht in wann ein Tenancy-Package die falsche Abstraktion ist.

Sicherheit und Datenschutz

Ein Portal verschiebt Geschäftsdaten aus internen Systemen ins öffentliche Netz. Das ist der Zweck, und es ist der Grund, warum Sicherheit hier kein Zusatzpunkt ist. Die Dinge, die wir für nicht verhandelbar halten:

• Zugriffsregeln zentral und getestet. Siehe das Rollenmodell weiter oben. Die häufigste schwere Lücke in Portalen ist nicht ein Einbruch von außen, sondern ein Kunde, der durch Ändern einer Nummer in der Adresszeile Daten eines anderen Kunden sieht.
• Zwei-Faktor-Anmeldung, mindestens für Konten mit erweiterten Rechten.
• Verschlüsselte Übertragung durchgehend, auch zwischen Portal und angebundenen Systemen – nicht nur zum Browser.
• Protokollierung. Wer hat welches Dokument wann abgerufen? Das braucht man seltener für die Technik als für Rückfragen aus dem Geschäft, und man hat es nur, wenn es von Anfang an mitläuft.
• Getestete Backups. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Das gilt doppelt, wenn Kundendaten darin liegen.
• Updates als Prozess, nicht als Aktion. Ein Portal aus dem Jahr 2026, das 2029 noch Kundendaten trägt, braucht in diesen drei Jahren regelmäßig Aktualisierungen von Framework, Sprache und Abhängigkeiten.

Zum Datenschutz die übliche und ernst gemeinte Grenze: Wir sind Entwickler, keine Anwälte. Was wir liefern, sind die technischen Voraussetzungen – Datenminimierung im Datenmodell, Löschkonzepte, die tatsächlich löschen, Auftragsverarbeitung dort, wo wir Zugang haben, nachvollziehbare Zugriffe. Die verbindliche Bewertung deines Falls gehört zu deinem Datenschutzbeauftragten.

Eine Frage stellt sich bei Portalen früher als bei Websites: wo die Daten liegen. Ein Portal mit Kundendaten in einer US-Cloud ist eine Entscheidung mit Folgen, und sie sollte bewusst fallen, nicht als Nebenprodukt der Hosting-Auswahl. Wir handhaben das aus Prinzip so: Hosting beim Kunden, nicht bei uns – und nicht ungefragt außerhalb der EU. Was dahintersteckt und welche Optionen es gibt, steht in EU-Hosting und digitale Souveränität.

Barrierefreiheit: wann das BFSG dein Portal betrifft

Dieser Punkt fehlt in den meisten Portalangeboten komplett, und das ist seit 2025 ein Risiko. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 für Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern. Für Portale heißt das konkret:

• Ein Portal, in dem Privatkunden bestellen, Verträge abschließen oder Termine buchen, fällt in der Regel darunter.
• Ein reines B2B-Portal für Geschäftskunden ist grundsätzlich nicht erfasst – das Gesetz schützt Verbraucher.
• Für Kleinstunternehmen gibt es bei Dienstleistungen eine Ausnahme: unter 10 Beschäftigte und unter 2 Millionen Euro Jahresumsatz.

Maßstab ist technisch WCAG 2.1 AA. Auch hier gilt: Wir sind keine Anwälte, die Bewertung deines Einzelfalls gehört zu einer Anwältin oder einem Anwalt. Die Details, die Fristen und was technisch dahintersteckt, haben wir in Barrierefreie Website: Was das BFSG verlangt aufgeschrieben.

Zwei praktische Hinweise aus der Portalperspektive. Erstens: Prüfe die Einordnung, bevor gebaut wird, nicht danach. Barrierefreiheit nachträglich in eine fertige Anwendung einzuziehen – Tastaturbedienung, Fokusreihenfolge, Kontraste, Formularfehler, die auch ein Screenreader mitbekommt – ist deutlich teurer als sie von Anfang an mitzubauen. Zweitens: Auch wenn dein Portal rein geschäftlich ist und damit nicht unter das Gesetz fällt, lohnt sich ein Großteil der Maßnahmen trotzdem. Deine Geschäftskunden sind Menschen, von denen manche mit Tastatur arbeiten, schlecht sehen oder einen Screenreader nutzen. Ein Portal, das sie aussperrt, erzeugt genau die Anrufe, die es abschaffen sollte.

Was ein Kundenportal kostet

Ehrliche Zahlen statt „kommt drauf an”: Bei uns starten individuelle Webanwendungen bei 10.000 €. Typische Portalprojekte liegen zwischen 15.000 und 60.000 € – wo genau, bestimmen vor allem drei Treiber:

• Schnittstellen. Jedes angebundene System bringt eigenen Analyse-, Entwicklungs- und Testaufwand mit. Eine saubere ERP-Anbindung kann so viel kosten wie das restliche Portal.
• Rollen- und Rechtemodell. „Jeder Kunde sieht seine Aufträge” ist einfach. „Kundenfirmen mit Admin-Benutzern, die Rechte an Kollegen vergeben” ist ein Vielfaches davon.
• Mandantenfähigkeit. Portale für mehrere Kundenfirmen mit harter Datentrennung beginnen bei uns bei 25.000 € – die Trennung zieht sich durch Datenmodell, Tests und Betrieb.

Was diese Spanne in der Praxis bedeutet, lässt sich am Umfang festmachen. Am unteren Ende steht ein Portal mit Anmeldung, einer Kernfunktion und einer Schnittstelle – Statusauskunft aus einem System, Rechte auf Nutzerebene, eine schlanke Verwaltung für dein Team. In der Mitte kommen mehrere Vorgangsarten dazu, Dokumente mit Rechten, zwei oder drei angebundene Systeme und ein Rollenmodell mit Kundenfirmen und Admin-Benutzern. Am oberen Ende steht Mandantenfähigkeit, Single Sign-on, eigene Preis- oder Rabattlogik und eine Verwaltungsoberfläche, die selbst ein kleines Produkt ist.

Was nicht preistreibend ist, obwohl es oft so wirkt: die Zahl der Seiten und die Zahl der Nutzer. Ein Portal für 50 Kunden kostet dasselbe wie eines für 5.000, solange das Rechtemodell gleich bleibt – die Last ist eine Hosting-Frage, keine Entwicklungsfrage. Preistreibend ist die Zahl der Regeln: wie viele Rollen, wie viele Ausnahmen, wie viele Systeme, wie viele Sonderfälle in deinen Abläufen.

Dazu kommt der laufende Betrieb, der im nächsten Abschnitt steht. Ein Portal, das Kundendaten trägt, ist kein „einmal bauen, nie wieder anfassen”-Projekt – diesen Posten von Anfang an einzuplanen ist ehrlicher, als ihn im Angebot wegzulassen.

Den genauen Preis nennen wir nach einem Konzept-Workshop. Vorher wäre jede Zahl geraten – und geratene Zahlen sind die Hauptursache gescheiterter Portalprojekte. Jede Aufwandsangabe, die du von uns vor dem Workshop bekommst, ist eine Einschätzung und kein Festpreis; wir sagen das deutlich, weil der Unterschied später Geld bedeutet.

Was der Betrieb kostet – und was er umfasst

Der häufigste Fehler in Portalbudgets ist nicht eine zu niedrige Entwicklungssumme. Es ist eine Betriebssumme von null. Ein Portal besteht nach dem Livegang aus drei laufenden Posten:

Hosting. Hängt von Anbieter und Last ab und läuft direkt über dich. Wir hosten Kundenanwendungen aus Prinzip nicht selbst – damit bleiben Daten und Vertragsverhältnis bei dir und du bist nicht an uns gebunden, wenn du irgendwann woanders weiterarbeiten willst. Für ein Portal brauchst du etwas mehr als Website-Hosting: Datenbank, Hintergrundprozesse für Abgleiche und E-Mails, Speicher für Dokumente, Backups.

Pflege. Updates von Framework, PHP und Abhängigkeiten, Überwachung, Backup-Prüfung, kleine Korrekturen. Das ist der Posten, der ein Portal in drei Jahren noch tragfähig hält, und der erste, der gestrichen wird. Unsere WordPress-Wartungspakete passen hier bewusst nicht: Ein CMS mit Plugins braucht andere Pflege als eine individuelle Anwendung. Für Portale vereinbaren wir deshalb entweder Aufwand nach Bedarf zum Stundensatz von 120 € oder ein festes Monatsbudget, das sich an der Größe des Portals orientiert.

Weiterentwicklung. Der Posten, den du dir wünschen solltest. Ein Portal, das genutzt wird, erzeugt Änderungswünsche – das ist ein Erfolgssignal, kein Mangel in der Planung. Ein kleines, festes Budget dafür ist der Unterschied zwischen einem Portal, das mit dem Unternehmen mitwächst, und einem, das nach zwei Jahren umgangen wird, weil es einen Schritt nicht mitgemacht hat.

Was wir dabei zusagen und was nicht, halten wir bewusst eng: Unsere Servicezeiten sind Montag bis Freitag von 8 bis 18 Uhr. Wir versprechen keinen 24/7-Betrieb und keine feste Reaktionszeit ohne entsprechenden Vertrag. Außerhalb der Servicezeiten sind wir meistens erreichbar – wir sagen es nur nicht zu, weil eine Zusage, die wir nicht jederzeit halten können, nichts wert ist.

So läuft die Entwicklung ab

1. Konzept-Workshop. Welcher Engpass soll weg, wer nutzt das Portal, welche Systeme müssen angebunden werden? Ergebnis: ein geschnittener Funktionsumfang und ein belastbarer Preis.
2. Schnittstellen-Analyse. Die angebundenen Systeme werden früh technisch geprüft – hier entscheidet sich, was zuverlässig machbar ist.
3. Erste nutzbare Version. Login, Kernfunktion, eine Schnittstelle – bewusst schmal geschnitten und in zwei bis vier Monaten live, statt ein Jahr auf den großen Wurf zu warten.
4. Iterativer Ausbau. Weitere Funktionen in kurzen Zyklen, priorisiert nach dem, was Nutzer tatsächlich verwenden – nicht nach der ursprünglichen Wunschliste.
5. Betrieb und Weiterentwicklung. Monitoring, Updates, Backups und ein fester Ansprechpartner – damit das Portal in drei Jahren noch trägt.

Zum Workshop lohnt es sich, vorbereitet zu kommen – nicht mit einem Lastenheft, sondern mit Material aus dem Alltag. Am meisten hilft uns: eine Liste der Anfragen, die dein Team in einer normalen Woche beantwortet hat, inklusive der Formulierungen deiner Kunden. Die Namen der Systeme, die im Spiel sind, und wer sie betreut. Ein Beispiel-Vorgang von Anfang bis Ende, einmal durchgesprochen. Und die Antwort auf die Frage, wer im Unternehmen entscheidet, wenn im Projekt zwei Wünsche nicht zusammenpassen – diese Rolle ist wichtiger als jedes Dokument.

Ein Punkt zum Livegang, der selten im Ablauf steht: Kunden müssen ins Portal gebracht werden. Ein funktionierendes Portal, von dem niemand weiß, ändert nichts an der Anzahl der Anrufe. Was funktioniert, ist eine kleine Gruppe zuerst – ein paar Kunden, die ohnehin regelmäßig Kontakt haben, mit persönlicher Einladung und der ausdrücklichen Bitte um Rückmeldung. Deren Rückfragen in den ersten zwei Wochen sind die beste Vorlage für den weiteren Ausbau, die man bekommen kann. Danach die Breite, mit einem Hinweis in der Signatur, auf der Rechnung, in der Auftragsbestätigung – an den Stellen, wo heute die Statusfrage entsteht.

Wenn schon ein Portal existiert: Migration

Ein Teil der Portalprojekte, die zu uns kommen, sind keine Neubauten. Es gibt schon etwas: ein in die Jahre gekommenes Kundenkonto, eine Insellösung aus einem früheren Projekt, ein Portal, dessen Hersteller den Support eingestellt hat. Das ändert den Ablauf an drei Stellen.

Die Bestandsanalyse kommt vor dem Konzept. Was wird tatsächlich benutzt? Diese Frage lässt sich nicht im Gespräch klären, sondern nur an den Nutzungsdaten des bestehenden Portals. Unsere Erfahrung aus Relaunch-Projekten ist ziemlich eindeutig: Ein erheblicher Teil der Funktionen, die in der Anforderungsliste „natürlich wieder dabei” stehen, wird von fast niemandem benutzt. Diese Funktionen nicht zu übernehmen, ist der günstigste Weg, ein Migrationsprojekt zu verkleinern.

Datenübernahme ist ein eigener Posten. Konten, Vorgangshistorien, hochgeladene Dokumente – was davon mit muss, ist eine Geschäfts- und keine Technikfrage. Historische Vorgänge mitzunehmen ist oft teurer als es klingt, weil das alte Datenmodell selten zum neuen passt. Eine gangbare Abkürzung: Das alte Portal bleibt eine Zeit lang lesend erreichbar, das neue startet mit den aktiven Vorgängen.

Zugänge sind der heikle Teil. Bestehende Nutzer haben Passwörter, die nicht übernommen werden können und auch nicht sollen. Der Umstieg bedeutet für jeden Kunden eine Neuanmeldung – das ist der Moment, an dem Portale Nutzer verlieren. Das gehört vorbereitet: Ankündigung, ein Weg zum Zurücksetzen, der ohne Rückfrage funktioniert, und für die ersten Wochen jemand, der erreichbar ist. Bei Portalen, die bestehende Kunden begleiten, planen wir diesen Umstieg inzwischen so ernsthaft wie eine Schnittstelle.

Woran du eine passende Agentur erkennst

Weil das die Frage ist, die nach den Kosten kommt, hier die Kriterien, die wir selbst anlegen würden – auch wenn uns einige davon nicht immer gut aussehen lassen:

• Es wird nach dem Engpass gefragt, nicht nach dem Funktionsumfang. Wer im ersten Gespräch eine Feature-Liste abhakt, verkauft Umfang. Wer fragt, welche Anrufe weniger werden sollen, baut ein Portal, das etwas ändert.
• Die Schnittstellen werden vor dem Angebot geprüft. Ein Festpreis für eine ERP-Anbindung, die niemand angesehen hat, ist entweder mit großem Risikoaufschlag kalkuliert oder er wird nicht halten.
• Die Fertiglösung wird ernsthaft erwogen. Eine Agentur, die bei jedem Portalgespräch zur Individualentwicklung kommt, hat nicht zugehört.
• Testabdeckung ist Teil des Angebots, nicht eine Option. Bei einem System mit Kundendaten und Rechtelogik sind automatisierte Tests kein Luxus.
• Du bekommst den Code und das Hosting liegt bei dir. Beides ist die Absicherung dafür, dass du weiterarbeiten kannst, falls die Zusammenarbeit endet.
• Zusagen sind konkret eingegrenzt. Servicezeiten, Reaktionszeiten, was im Preis ist und was nicht. „Wir sind immer für dich da” ist keine Zusage, sondern eine Floskel.
• Es gibt vergleichbare Arbeit zum Ansehen. Nicht zwingend ein Portal in deiner Branche, aber eine Anwendung mit Anmeldung, Rechten und einer echten Systemanbindung.

Dazu zwei Punkte, an denen du uns absagen solltest: Wenn du eine Lösung von der Stange zum Stangenpreis brauchst, sind wir die falsche Adresse – dann ist ein Baukasten günstiger und schneller. Und wenn du einen Anbieter suchst, der Hosting, Betrieb und Datenhaltung komplett übernimmt und du damit nichts zu tun haben willst, passt unser Modell nicht, weil wir Kundenanwendungen bewusst nicht selbst hosten.

Die häufigsten Fehler bei Portalprojekten

1. Alles auf einmal wollen. Der Vollausbau als erste Version verdoppelt nicht die Dauer – er verhindert oft den Livegang. Der größte Engpass zuerst, der Rest iterativ.
2. Schnittstellen unterschätzen. „Das ERP hat doch eine API” ist der teuerste Satz im Portalgeschäft. Anbindungen früh prüfen, nicht am Ende einbauen.
3. Den Betrieb vergessen. Ein Portal mit Kundendaten braucht Pflege, Sicherheit und einen Verantwortlichen – wer nur das Bauen budgetiert, bezahlt den Rest später teurer.
4. Das Rollenmodell zu spät festlegen. Ob Rechte an Nutzern oder an Kundenfirmen hängen, entscheidet über das Datenmodell. Diese Frage nach dem Start zu drehen, ist eine der teuersten Änderungen, die ein Portalprojekt kennt.
5. Den Livegang für das Ende halten. Kunden kommen nicht von selbst ins Portal. Ohne Einladung, ohne Hinweis an der Stelle, wo heute die Statusfrage entsteht, und ohne Ansprechpartner in den ersten Wochen bleibt das Portal leer – und das Telefon klingelt weiter.

Ehrliches Fazit

Ein Kundenportal lohnt sich, wenn es einen echten Engpass ersetzt – die tägliche Statusanfrage, das Dokumenten-Pingpong, die Doppeleingabe zwischen Systemen. Es lohnt sich nicht als Prestige-Projekt ohne klaren Anwendungsfall. Die Reihenfolge für eine gute Entscheidung: erst der Engpass, dann die Fertig-oder-individuell-Frage, dann der Schnitt der ersten Version – und erst danach die Technik.

Wenn du aus diesem Artikel eine Sache mitnimmst, dann die Reihenfolge der Prüfungen. Zähle den Engpass, bevor du ein Budget suchst. Prüfe das System, das du schon hast, bevor du etwas Neues baust. Lass die Schnittstelle ansehen, bevor du ein Angebot unterschreibst. Und kläre das Rollenmodell, bevor die erste Zeile Code entsteht. Die Portalprojekte, die wir scheitern gesehen haben, sind nicht an der Technik gescheitert, sondern daran, dass eine dieser vier Prüfungen übersprungen wurde.

---

Du überlegst, ein Kundenportal entwickeln zu lassen? Erzähl uns, welcher Engpass weg soll und welche Systeme dranhängen – wir sagen dir ehrlich, ob sich Individualentwicklung für deinen Fall lohnt und was sie kostet: Schreib uns kurz. Mehr zu unserer Arbeitsweise: Individualsoftware und Laravel-Agentur.