Kurzantwort: Beginnen Sie die Planung eines Kundenportals mit einem wiederkehrenden Kundenanliegen. Legen Sie fest, welche Information der Kunde braucht, was er entscheiden darf und wie Ihr Team seine Rückmeldung weiterbearbeitet. Erst danach wählen Sie die Funktionen und vergleichen eine Standardlösung mit einem individuellen Build.
Wenn Kunden regelmäßig nach dem Projektstand fragen, Dateien anfordern oder Freigaben per E-Mail geben, lässt sich daraus ein klarer erster Vorgang ableiten. Eine lange Funktionsliste hilft erst, wenn dieser Ablauf verständlich ist. Auf unserer Seite zur Kundenportalentwicklung finden Sie den Projektweg; hier geht es um die Vorbereitung Ihrer Anforderungen.
Einen Kundenvorgang vollständig beschreiben
Illustratives Beispiel, kein Kundenprojekt: Ein Projektbetrieb stellt seinem Kunden einen Zeichnungsentwurf bereit. Eine benannte Ansprechpartnerin darf diese Version freigeben oder eine Änderung anfordern. Das interne Team muss anschließend erkennen, welche Version entschieden wurde und welche Aufgabe folgt.
Beschreiben Sie diesen Vorgang in fünf Punkten:
- Anlass: Das interne Team stellt einen Entwurf zur Prüfung bereit.
- Information: Der Kunde sieht Projekt, Dokumentversion, Status und zuständige Person.
- Berechtigte Entscheidung: Die benannte Person gibt diese Version frei oder kommentiert den Änderungsbedarf.
- Weiterbearbeitung: Ihr Team erhält die Rückmeldung mit Bezug zur entschiedenen Version.
- Ausnahme: Ein neuer Entwurf, ein abgelaufener Zugang oder eine fehlende Freigabeberechtigung bleibt nachvollziehbar.
Damit können Sie eine Lösung vorführen und beurteilen. Ein Dateiupload allein löst noch nicht die Frage, ob die richtige Person über die aktuelle Version entschieden hat.
Welche Funktionen der erste Umfang braucht
Die folgende Tabelle ist unsere Planungshilfe für das Beispiel. Sie beschreibt mögliche Anforderungen, keine pauschale Pflichtausstattung jedes Portals.
| Kundenanliegen | Funktion im ersten Umfang | Frage für die Abnahme |
|---|---|---|
| Aktuellen Projektstand verstehen | Status und benannter Ansprechpartner | Ist erkennbar, wann der Stand zuletzt aktualisiert wurde? |
| Richtigen Entwurf finden | Dokument mit Version und Zuordnung | Bleibt die freigegebene Version eindeutig? |
| Rückmeldung geben | Freigabe oder Änderungskommentar | Ist die Entscheidung der berechtigten Person zugeordnet? |
| Nächsten Schritt kennen | Bestätigung und zuständige Stelle | Weiß der Kunde, wer jetzt weiterarbeitet? |
| Einen Ausnahmefall klären | Sichtbarer Klärungsstatus | Kann das Team den Vorgang übernehmen? |
Eine Bestellfunktion, ein Chat oder ein Terminbuchungssystem kann später sinnvoll werden. Nehmen Sie eine Funktion in den ersten Umfang auf, wenn sie für den gewählten Vorgang benötigt wird. So bleibt der Test aussagekräftig.
Rollen und Kundenzuordnung vor dem Build festlegen
OWASP unterscheidet Identitätsprüfung und Berechtigung: Eine angemeldete Person darf damit noch nicht jede Ressource nutzen. Rechte sollen pro Zugriff geprüft werden; fehlende Erlaubnis führt zur Ablehnung. Für das Portalbeispiel leiten wir daraus die Trennung von Lesen, Kommentieren und Freigeben ab.
Zusätzlich braucht jede relevante Information eine Kundenzuordnung. Die OWASP-Leitlinie zu mehreren Mandanten warnt davor, eine vom Browser angegebene Kundenkennung ungeprüft zu übernehmen. Die Anwendung muss sie mit der verifizierten Identität und deren Berechtigung abgleichen.
Vereinbaren Sie deshalb konkrete Gegenproben: Eine Person von Kunde B folgt dem Dokumentlink von Kunde A. Ein ausgeschiedener Ansprechpartner öffnet einen alten Link. Ein Leser versucht, eine Freigabe auszulösen. Diese Fälle gehören zur Abnahme des vereinbarten Rechtekonzepts.
Standardprodukt oder individuelles Kundenportal?
Kurzantwort: Prüfen Sie den vollständigen Vorgang in vorhandener Software. Ein Standardprodukt ist ein guter Kandidat, wenn Kundenzugänge, Daten und Rückmeldungen ausreichend passen. Individuelle Entwicklung wird relevant, wenn besondere Regeln oder Systemübergaben offenbleiben.
| Prüffrage | Was Sie zeigen lassen sollten |
|---|---|
| Gibt es schon ein Portal im ERP, CRM oder Projektwerkzeug? | Ihren konkreten Vorgang einschließlich Rückmeldung |
| Kann das Standardprodukt die benötigten Rollen abbilden? | Kundenzuordnung und getrennte Entscheidungen |
| Wo liegen Dokumente und Projektstatus heute? | Übernahme und Aktualisierung aus der vorhandenen Quelle |
| Was passiert nach einer Freigabe? | Zuständige interne Person und nächster Arbeitsschritt |
| Können Sie den Ablauf später weiterführen oder wechseln? | Datenexport, Betriebsaufgaben und Übergabe |
Passt ein Standardprodukt, vergleichen Sie Konfiguration, Lizenzen und laufende Betreuung für denselben Umfang. Bei einem individuellen Build kommen Entwicklung, Betrieb und Weiterentwicklung hinzu. Der Ratgeber zu Kosten individueller Software erklärt diese Betrachtung genauer.
ERP und CRM gezielt anbinden
Ein Portal braucht für den ersten Vorgang häufig nur einen Ausschnitt Ihrer Unternehmensdaten. Entscheiden Sie pro Information, welches System sie führt: etwa Ansprechpartner im CRM oder Auftragsstatus im ERP. Das Portal kann diesen Stand anzeigen, ohne eine zweite unabhängige Pflege einzuführen.
Legen Sie auch die nötige Aktualität fest. Ein täglich übernommener Projektstand kann für einen Ablauf passen, während eine Freigabe direkt weitergegeben werden muss. Anzeigen und Zurückschreiben sind getrennte Aufgaben mit eigenen Regeln. Unser Ratgeber zum Verbinden von ERP und CRM hilft bei dieser Auswahl; die Schnittstellenentwicklung beschreibt den Umsetzungsweg.
Kostenfaktoren und Projektstart bei NLD
Die Anzahl der sichtbaren Seiten beschreibt den Aufwand nur teilweise. Für die Planung zählen insbesondere Rollen, Versionen und Freigaben, vorhandene Daten, Systemanbindungen sowie die Aufgaben nach der Veröffentlichung. Lassen Sie diese Punkte für denselben Vorgang kalkulieren, damit Angebote vergleichbar werden.
Bei NLD dauert der bezahlte Discovery-Sprint 5 Arbeitstage und kostet 4.900 € netto. Sie erhalten eine Live-Demo, eine Bewertung und eine Entscheidungsempfehlung. Ein produktives Kundenportal mit vereinbarten Rechten, Anbindungen und Betrieb ist ein gesonderter Build und bleibt optional.
Für das erste Gespräch reichen der wiederkehrende Vorgang, die beteiligten Rollen und die heute verwendeten Systeme. Ein vereinfachtes Beispiel ohne vertrauliche Kundendaten genügt, um den Bedarf zu besprechen. Kundenportal und ersten Vorgang mit Simon klären.
Quellen und weiterführende Dokumente
Häufige Fragen
Kurz und direkt beantwortet.
Wann lohnt sich ein eigenes Kundenportal?
Ein individueller Build kommt infrage, wenn wiederkehrende Kundenanliegen einen besonderen Ablauf mit Dokumenten, Rollen oder Freigaben brauchen. Prüfen Sie zuerst, ob ein Portal Ihres vorhandenen Systems oder ein Standardprodukt diesen Vorgang ausreichend abbildet.
Welche Funktionen gehören in ein B2B-Kundenportal?
Der erste Umfang sollte einen vollständigen Kundenvorgang abdecken: zum Beispiel ein bestimmtes Dokument finden, die richtige Version prüfen und eine Rückmeldung geben. Rollen, Kundenzuordnung, Status, Benachrichtigung und interne Weiterbearbeitung gehören zu diesem Vorgang. Weitere Funktionen richten sich nach dem geklärten Bedarf.
Reicht ein Login, damit Kunden nur ihre eigenen Daten sehen?
Ein Login bestätigt die Identität. Ob die Person ein bestimmtes Projekt oder Dokument sehen und bearbeiten darf, braucht eine eigene Berechtigungsprüfung. Auch direkte Dokumentlinks und Zugriffe auf fremde Kundenvorgänge müssen auf dem Server geprüft werden.
Was beeinflusst die Kosten eines Kundenportals?
Rollen und Kundenzuordnung, Dokumentversionen, Freigaben, Datenübernahme, Schnittstellen und Betrieb bestimmen den Umfang. Bei NLD wird ein optionaler produktiver Build nach dem bezahlten Discovery-Sprint anhand des geklärten Vorhabens individuell zum Festpreis angeboten.