Ein individuelles Kundenportal amortisiert sich in dem Moment, in dem Projektstandards nicht mehr im Posteingang landen. Der klassische Fehler bei der Entwicklung eines Kundenportals: es als Plattform-Projekt anzugehen. Besser ist, die kleinste Version zu liefern, die die drei häufigsten E-Mails überflüssig macht, und es danach auszubauen, sobald Kunden tatsächlich einloggen.
Im Moment sind Sie die Statusschnittstelle für jedes Projekt. Ein Kunde schreibt 'Gibt es Neuigkeiten?' und echte Arbeit stoppt, damit Sie einen Ordner abfotografieren, einen Link einfügen und versichern können, dass alles im Plan liegt.
Wahrscheinlich haben Sie das bereits mit geteilten Drive-Ordnern, einem WeTransfer-Link, einem Calendly und einer Tabelle geflickt, die nur Sie lesen können. Dieses Konstrukt hält bis zu einer Handvoll Kunden. Dieser Leitfaden zeigt, wann ein Portal besser ist als ein weiterer SaaS-Login, welches v1 sich zu bauen lohnt, welcher Stack die laufenden Kosten niedrig hält und ab wann sich die Investition rechnet.
- Bauen Sie für drei Aufgaben: Status, Dokumente und die eine Aktion, um die Kunden immer wieder bitten. Alles andere ist v2.
- SaaS kaufen, wenn der Prozess generisch ist; bauen, wenn der Prozess Ihr Geschäft ist. Ein Portal, das Ihre tatsächliche Arbeitsweise abbildet, ist genau das, was kein SaaS verkauft.
- Ein erstes Portal kostet 20.000 € bis 50.000 € und wird in Wochen ausgeliefert. Der größte Teil des Budgets fließt in Authentifizierung, Berechtigungen und Zuverlässigkeit. Die Screens sind der günstige Teil.
- Der Nutzen ist operativer Natur: weniger Statusanfragen, schnellere Übergaben und eine Durchlaufzeit, die sich beziffern lässt.
Was ein Kundenportal tatsächlich ersetzt
Ein Kundenportal ist ein einziger authentifizierter Ort, an dem Kunden ihre laufenden Projekte sehen und handeln können. Ohne Buzzwords gesagt: Es ersetzt einen Stapel von Tools, für die Sie bereits bezahlen.
Der typische Pre-Portal-Stack besteht aus einem geteilten Google Drive-Ordner, einem E-Mail-Thread pro Kunde, einem WeTransfer-Link für größere Dateien, einem Calendly für Terminbuchungen und einer Tabelle, die nur Sie verstehen. Jedes Tool funktioniert für sich. Zusammen entstehen Lücken: Links laufen ab, die falsche Version wird verschickt, und keine Statusfrage beantwortet sich ohne Ihr Zutun.
Ein Portal fasst das in drei Aufgaben zusammen, um die Kunden immer wieder bitten.
- Status. Der Kunde sieht den aktuellen Stand, ohne nachzufragen, und die 'Gibt es Neuigkeiten?'-Mail bleibt aus.
- Dokumente. Hochladen und herunterladen an einem versionierten Ort hinter einem Login, sodass die richtige Datei die einzige Datei ist.
- Aktion. Die eine Sache, um die Kunden immer wieder bitten: einen Entwurf freigeben, eine Phase bestätigen oder die nächste Information einreichen.
Die meisten Betriebe überschreiten diese Schwelle, ohne es zu bemerken. Sobald geteilte Ordner und eine Statustabelle abrechenbare Stunden kosten, ist der richtige Moment, den Umfang eines Portals zu definieren. webvise entwickelt individuelle Kundenportale auf einem Stack, der auf niedrige Betriebskosten ausgelegt ist, und das Discovery-Gespräch definiert das v1, bevor eine Zeile Code geschrieben wird.
Wann ein individuelles Portal besser ist als ein weiterer SaaS-Login
Es gibt genügend Kundenportal-SaaS. HubSpot hat Portale, SuiteDash und Copilot verkaufen Kundenportal-Produkte, und Notion oder Google Sites können eines simulieren. Kaufen Sie eines davon, wenn Ihre Kundenkommunikation generisch ist: ein Dokument teilen, eine Datei entgegennehmen, eine Rechnung anzeigen.
Ein individuelles Portal lohnt sich, wenn der Prozess das Produkt ist. Sind die Schritte, die ein Kunde durchläuft, spezifisch für Ihre Arbeitsweise, bildet ein generisches Tool sie nur mit Workarounds ab, und genau diese Workarounds spüren Kunden bei jedem Login.
Das ist die Build-vs.-Buy-Entscheidung auf ein konkretes Tool angewendet. Das vollständige Build-vs.-Buy-Framework behandelt den allgemeinen Fall. Hier ist die Entscheidung nach Situation.
| Ihre Situation | Günstigste Lösung | Begründung |
|---|---|---|
| Dateien teilen und Rechnungen anzeigen, nichts Spezifisches | Kundenportal-SaaS kaufen oder HubSpot nutzen | Generischer Bedarf, generisches Tool, geringste Einstiegskosten |
| Ein fester mehrstufiger Prozess, den Kunden durchlaufen | Individuelles Portal bauen | Die Schritte sind Ihr Geschäft, ein generisches Tool erzwingt Kompromisse, die Kunden bemerken |
| Wenige Kunden, geringes Volumen, gelegentliche Dateien | Noch nichts bauen, Drive und E-Mail bereinigen | Bei diesem Volumen rechnet sich ein Portal nicht |
| Dieselben Daten werden in zwei Systeme eingetippt | Bauen und Systeme per API verbinden | Das Portal eliminiert die Doppelerfassung, und dort gehen die Stunden verloren |
Was zuerst gebaut wird: das v1, das sich rechnet
Der schnellste Weg, ein Portal-Budget zu verbrennen, ist eine Plattform zu liefern. Die Version, die sich rechnet, ist klein und fokussiert, zugeschnitten auf einen Prozess, der jede Woche läuft.
Bauen Sie ein Objekt und die Schleife darum herum. Bei einer Agentur ist dieses Objekt ein Projekt, bei einem Kreditgeber eine Anfrage, bei einer Klinik ein Fall. Geben Sie ihm einen Login, einen Status, einen Ort für Dokumente und eine Benachrichtigung bei Statusänderung. Das ist das vollständige v1.
- Authentifizierung und Rollen. Der Kunde sieht nur seine Daten, das Team sieht alles. Das ist der Teil, der stimmen muss.
- Ein Objekt mit Status-Timeline. Der Kunde verfolgt den Fortschritt, ohne eine einzige E-Mail zu schreiben.
- Dokumente hochladen und herunterladen. Versioniert, hinter dem Login, mit einem Protokoll, wer wann was getan hat.
- E-Mail-Benachrichtigungen. Eine Statusänderung schickt eine E-Mail, damit niemand einloggt, um festzustellen, dass sich nichts geändert hat.
Die Features, die im Kickoff-Meeting unverzichtbar wirken, sind meist die, die man verschieben sollte. Hier ist, was auf später warten kann und warum das Warten nichts kostet.
| Verlockend für v1 | Liefern in | Warum warten |
|---|---|---|
| Chat im Portal | v2 oder nie | E-Mail funktioniert bereits, und Chat fügt Moderations- und Benachrichtigungsaufwand hinzu |
| Abrechnung und Zahlungen | v2 | Zahlungen liegen außerhalb der v1-Statusschleife, und Stripe lässt sich ergänzen, sobald Kunden einloggen |
| Native Mobile App | Vielleicht nie | Ein schnelles responsives Webportal deckt rund 95 % der Nutzung durch Kunden ab |
| SSO und Enterprise-Berechtigungen | Wenn ein Enterprise-Kunde es verlangt | Kein Nutzen, bis jemand es tatsächlich verlangt |
Der Stack, der ein Portal günstig im Betrieb hält
Ein Portal läuft jahrelang, sodass die Baukosten kleiner sind als die Betriebskosten. Der Stack entscheidet über diese zweite Zahl, und ein Portal auf Basis von Workarounds wird teuer, sobald etwas zum ersten Mal bricht.
Bei webvise entstehen Portale auf Next.js und React, sodass Frontend und Backend eine gemeinsame Codebasis teilen. tRPC liefert typsichere APIs, ein umbenanntes Feld bricht den Build statt die Produktion. PostgreSQL mit Drizzle hält die Daten, Better Auth übernimmt Login und Rollen. Stripe kommt für Zahlungen hinzu, wenn Abrechnung relevant wird, Resend verschickt Benachrichtigungen, und das gesamte System deployt über einen Commit zu Vercel.
Für ein Kundentool zählen zwei Zahlen. Ladezeit unter 1,2 Sekunden bei einer normalen Verbindung und ein Lighthouse-Score über 90, weil ein langsames Tool nicht genutzt wird und Kunden wieder per E-Mail fragen. Jeder Build wird an diesem Standard gemessen, und zur Übergabe gibt es einen Performance-Bericht, der am Live-System gemessen wurde.
Wann es sich rechnet und wann nicht
Ein erstes Kundenportal kostet grob 20.000 € bis 50.000 €, dieselbe Bandbreite wie die Kundenportal-Kategorie im Leitfaden zu den Kosten individueller Webanwendungen. Der Nutzen ist operativer Natur.
Zählen Sie die Stunden, die pro Woche für 'Gibt es Neuigkeiten?'-Anfragen, das erneute Versenden von Dateien und das manuelle Übertragen von Daten zwischen Systemen aufgewendet werden. Ein Portal eliminiert den Großteil davon, einschließlich des verpassten Übergabemoments, der still einen Kunden kostet. Wenn diese Stunden real sind, rechnet sich ein Portal in dieser Preisklasse innerhalb eines Jahres.
Bei geringem Volumen rechnet es sich nicht. Mit einer Handvoll Kunden und gelegentlichen Dateien schlägt ein aufgeräumter Drive mit einer klaren E-Mail-Vorlage jeden individuellen Aufbau. Die Zeichen, dass Sie dieses Setup überwachsen haben, sind operativer Natur und zeigen sich in den Zahlen, bevor sie in einem Meeting auftauchen.
Wenn Kundenstatus noch im Posteingang lebt, benennen Sie das eine Objekt und die drei Aufgaben, die Ihr Portal abdecken würde, und prüfen Sie das v1 gegen das tatsächliche Volumen. webvise entwickelt individuelle Kundenportale auf dem beschriebenen Stack und definiert dieses v1 in einem kurzen Discovery-Gespräch. Starten Sie bei webvise.