Kundenportal für Geschäftskunden: bauen, kaufen oder das Shop-Konto ausbauen?

Ein Kundenportal ist der geschützte Bereich, in dem Ihre Geschäftskunden selbst nachsehen, was der Innendienst sonst am Telefon beantwortet: Auftragsstatus, Belege, Preisliste, Reklamation, Ansprechpartner. Es ist kein zweiter Shop. Vor dem Bau steht eine Prüfung: Was zeigt Ihr Shop-Kundenkonto heute schon — und welche Daten fehlen ihm noch?

Abgrenzung vorweg. Dieser Beitrag behandelt den Service-Teil: Was Ihre Kunden nach der Bestellung wissen und melden wollen. Die Bestellstrecke selbst — Katalog, Warenkorb, Kaufabwicklung, Auswahl des Shopsystems — steht im Beitrag zum B2B-Online-Shop für Geschäftskunden. Beide Kanäle können in derselben Software liegen. Sie beantworten trotzdem verschiedene Fragen, und genau diese Verwechslung macht viele Portalprojekte teuer.

1. Drei Kanäle, drei Aufgaben — und wo das Portal steht

Wer nach „Kundenportal" sucht, landet in einer merkwürdigen Suchergebnisliste. Fast alles, was dort steht, ist eine Anmeldeseite: Landesämter, Rentenversicherung, Versicherer, Entsorger, Verkehrsbetriebe. Erklärt wird der Begriff nur an wenigen Stellen, und dort meist aus der Sicht eines Software-Anbieters. Für einen Betrieb, der Ware verkauft, liefert und repariert, ist das wenig hilfreich.

Also fangen wir bei der Aufgabe an. In einem Handels- oder Produktionsbetrieb laufen mehrere Kanäle nebeneinander, und jeder hat eine andere Funktion. Erst wenn diese Aufteilung klar ist, lässt sich sagen, ob überhaupt ein Portal fehlt.

Die Zeile, die am meisten Missverständnisse auflöst, ist die letzte. EDI ist der Gegenentwurf zum Portal: keine Oberfläche, keine Anmeldung, kein Klick. Bestellung, Lieferavis und Rechnung laufen als strukturierte Nachrichten zwischen zwei Systemen. Wie das funktioniert und wann es sich rechnet, haben wir im Beitrag zur EDI-Schnittstelle erklärt. Für wenige große Handelspartner ist EDI fast immer der bessere Weg. Ein Portal zielt auf das andere Ende: viele kleine und mittlere Kunden, die dieselben Fragen stellen.

2. Sechs Anfragen und wo ihre Antwort wirklich liegt

Ein Portalprojekt beginnt nicht mit einer Softwareauswahl, sondern mit einer Strichliste. Notieren Sie vier Wochen lang, was bei Ihnen eingeht — am Telefon, per E-Mail, über das Kontaktformular. In den meisten Betrieben verteilen sich weit über die Hälfte aller Kundenfragen auf eine Handvoll Anlässe. Die folgende Tabelle nimmt die sechs häufigsten und zeigt, welches System die Antwort schon heute enthält.

Zwei Einsichten stecken in dieser Tabelle. Erstens: Keine dieser Antworten muss neu erzeugt werden. Sie existiert bereits — in der Warenwirtschaft, in der Versandsoftware, im Ticketsystem. Ein Portal erfindet keine Daten, es macht vorhandene sichtbar. Deshalb ist der teuerste Teil eines Portalprojekts fast nie die Oberfläche, sondern der Weg zu den Daten und ihre Ordnung.

Zweitens: Die Spalte „Wo die Antwort heute liegt" ist das eigentliche Problem. Preislisten im Mailanhang, Rechnungen im Postfach einer einzelnen Person, Ansprechpartner auf alten Visitenkarten — das sind keine Systemlücken, sondern gewachsene Gewohnheiten. Ein Portal ersetzt sie nur, wenn es an derselben Stelle bequemer ist als der Griff zum Telefon.

Übrigens erleben Sie dieselbe Situation regelmäßig von der anderen Seite: als Kunde Ihrer Lieferanten. Welche Daten Sie dort selbst gern hätten und wie sich das systematisch aufsetzen lässt, steht im Beitrag zum digitalen Lieferantenmanagement. Der Perspektivwechsel hilft beim Zuschnitt der ersten Ausbaustufe mehr als jede Anbieter-Demo.

3. Funktionskatalog nach Priorität statt nach Broschüre

Anbieterseiten listen Portalfunktionen als Sammlung auf: individuelle Preise, Nachbestellung, Rollen und Rechte, Dokumenten-Self-Service, ERP-Integration. Als Aufzählung ist das richtig, als Bauplan unbrauchbar. Sinnvoller ist eine Reihenfolge, die sich an Ihrer Strichliste orientiert und an dem, was die Daten hergeben.

Der Reklamationsteil der zweiten Stufe verdient eine eigene Bemerkung. Ein Meldeformular mit Pflichtfeldern spart Ihnen zwei Rückfragen je Fall, weil Bestellnummer, Position und Foto gleich mitkommen. Wie ein solcher Prozess vom Erstkontakt bis zur Ursachenanalyse aufgebaut ist, steht im Beitrag zum Reklamationsmanagement. Geht es dagegen um die Rücksendung von Ware im engeren Sinn, ist ein eigenes Retourenportal oft der bessere Zuschnitt — es funktioniert auch ohne Kundenkonto und erreicht damit Gelegenheitskäufer.

Eine Funktion fehlt in der Tabelle bewusst: der Versand elektronischer Rechnungen. Ein PDF im Portal ist keine E-Rechnung im Sinne der seit 2025 geltenden Empfangspflicht. Was formal gefordert ist und welche Formate zählen, haben wir in der Übersicht zur E-Rechnungspflicht zusammengetragen. Das Portal ist ein zusätzlicher Abholweg, kein Ersatz für den vereinbarten Rechnungskanal.

4. Woher die Daten kommen — und wo sie kippen

Jede Portalfunktion hat genau eine führende Datenquelle. Wo das nicht festgelegt ist, zeigt das Portal später zwei verschiedene Wahrheiten, und der Kunde entdeckt sie vor Ihnen. Die folgende Tabelle nennt zu jeder Quelle den typischen Stolperstein aus Projekten.

Die Warenwirtschaft ist dabei fast immer die führende Quelle. In JTL-Wawi etwa liegen Kundenstammdaten, Kundengruppen und Kundenkategorien an einer Stelle; der JTL-Guide beschreibt, dass Sie beim Markieren eines kundenbezogenen Datensatzes „wie Aufträge, Rechnungen etc." in Echtzeit alle wichtigen Daten zum Kunden erhalten (Quelle: JTL-Guide, Kundenverwaltung, abgerufen am 6. September 2026). Genau diese Sicht will ein Portal für den Kunden nachbilden — allerdings auf den Ausschnitt beschränkt, der ihn betrifft.

Das Ticketsystem ist die zweite Quelle, und es ist die heikelste. Vorgänge lassen sich zeigen, interne Notizen und Zwischenstände nicht. Welche Werkzeuge sich für welche Teamgröße eignen, steht im Vergleich von Helpdesk-Software. Für das Portal zählt weniger das Produkt als die Frage, ob es eine Schnittstelle mit einer sauberen Trennung zwischen interner und kundensichtbarer Ebene bietet.

5. Zuerst prüfen: Was das Shop-Kundenkonto schon kann

Bevor ein neues System entsteht, gehört eine unbequeme Frage auf den Tisch: Was zeigt Ihr Shop-Kundenkonto heute eigentlich — und was davon haben Sie eingeschaltet? In vielen Projekten stellt sich heraus, dass ein Teil der gewünschten Funktionen bereits vorhanden ist und schlicht nie konfiguriert wurde.

Ein Beispiel aus der JTL-Welt, weil dort die Dokumentation öffentlich nachlesbar ist. Der JTL-Guide beschreibt für den Kundenbereich unter anderem den Pfad Mein Konto > Meine Wunschzettel und, sobald das Download-Modul aktiv ist, den Bereich Meine Downloads: Dort können Kunden eine Datei herunterladen, „sobald die zugehörige Bestellung bezahlt wurde" (Quelle: JTL-Guide, Download-Modul, abgerufen am 6. September 2026). Auftragsübersicht und Adressverwaltung gehören ebenfalls zum Standard-Kundenbereich.

Genauso wichtig ist, was die Dokumentation nicht beschreibt. Einen Download von Rechnungs-PDFs im Kundenkonto führt der Guide nicht auf. Im JTL-Forum wurde die Frage 2018 von einem Mitarbeitenden mit „Ist im Shop nicht geplant" beantwortet, 2020 verwies ein Administrator auf ein Plugin. Beide Beiträge sind älter als die heutige Shop-Generation. Wir geben sie deshalb ausdrücklich als Forumsstand mit Datum wieder und nicht als Aussage über Ihre Version: Prüfen Sie das an Ihrem eigenen Shop nach, bevor Sie Kunden etwas zusagen.

Dieses Muster ist nicht JTL-spezifisch. Bei Shopware gibt es mit den B2B Components sieben dokumentierte Module — Employee Management, Quote Management, Order Approval, Individual Pricing, Quick Order und Shopping List, Organization Unit sowie Digital Sales Composables. Shopify beschreibt B2B als „suite of native features", mit der über Admin und Onlineshop an Firmen verkauft wird, mit Firmen als eigenem Kundenobjekt, Katalogen samt eigenen Preislisten und Zahlungsbedingungen; verfügbar sind diese Funktionen laut Hersteller auf den Plänen, die B2B unterstützen. In allen drei Fällen lohnt derselbe Schritt: erst die Bordmittel inventarisieren, dann die Lücke benennen.

6. Bauen, kaufen oder ausbauen: drei Wege im Vergleich

Erst nach dieser Bestandsaufnahme lässt sich die Grundsatzfrage beantworten. Es gibt drei Wege, und keiner davon ist grundsätzlich richtig. Was zählt, ist die Ausgangslage.

Zum dritten Weg gehört eine Zwischenstufe, die oft übersehen wird: die Low-Code-Plattform. Microsoft beschreibt Power Pages als „sichere, unternehmensweite, Low-Code-Software as a Service (SaaS)-Plattform zum Erstellen, Hosting und Verwalten moderner externer Geschäftswebsites", die auf denselben Daten in Microsoft Dataverse arbeitet wie Apps und Workflows der Power Platform (Quelle: Microsoft Learn, Stand der Seite 23. April 2026). Wer ohnehin in dieser Welt unterwegs ist, kommt damit schneller zu einem Portal als mit einer Eigenentwicklung.

Ein Detail dieses Wegs entscheidet allerdings über die Wirtschaftlichkeit, und es steht nicht in der Produktbeschreibung, sondern in den Lizenz-FAQ: Power Pages wird nach Nutzern abgerechnet, nicht pro Portal. Microsoft nennt zwei Kapazitätsarten, „Authenticated users per website/month" und „Anonymous users per website/month". Ein Paket umfasst 100 authentifizierte Nutzer, mindestens 25 müssen einer Umgebung zugewiesen sein; bei anonymen Nutzern sind es 500 je Paket und mindestens 200. Als Nutzer zählt jede Person, die sich in einem Kalendermonat mindestens einmal anmeldet — unabhängig davon, wie oft (Quelle: Microsoft Power Platform Licensing FAQs, Stand der Seite 14. August 2026). Bei 400 Ansprechpartnern auf Kundenseite rechnen Sie also anders als bei 40. Preise nennen wir hier bewusst nicht: Die Preisseiten der Hersteller laden ihre Tabellen erst im Browser nach, und ohne belegten Stand ist jede Zahl in einem Blogartikel wertlos.

Bleibt der Weg der echten Eigenentwicklung. Er ist heute günstiger zu beginnen als noch vor wenigen Jahren, weil KI-gestützte Werkzeuge den ersten lauffähigen Stand beschleunigen. Er wird trotzdem im Betrieb bezahlt: Aktualisierungen, Sicherheitslücken, Dokumentation, Ausfälle. Wo diese Rechnung aufgeht und wo sie kippt, haben wir im Beitrag zum Vibe Coding im Unternehmen nüchtern durchgerechnet — inklusive der Studienlage zur tatsächlichen Zeitersparnis.

Ein weiterer Weg wird oft geprüft und ebenso oft falsch eingeschätzt: der Low-Code-Baukasten der Microsoft Power Platform. Für Anwendungen innerhalb der eigenen Belegschaft ist er stark, für ein Portal mit betriebsfremden Nutzern greift jedoch eine eigene Lizenzwelt — der Lizenzleitfaden verweist externe Nutzer ausdrücklich auf Power Pages mit eigenen Kapazitätspaketen für angemeldete und anonyme Zugriffe. Was das für Ihre Kalkulation bedeutet, zeigen wir im Beitrag zu Power Apps im Mittelstand.

7. Rollen und Rechte: der Punkt, an dem Portale kippen

Im Geschäft mit Firmenkunden gibt es selten den Kunden. Es gibt einen Einkauf, eine Buchhaltung, ein Lager, vielleicht eine Technikabteilung — und alle arbeiten mit denselben Vorgängen, aber mit unterschiedlichem Informationsbedarf. Genau daran scheitern Portale, die aus einem Endkunden-Konto entstanden sind: Sie kennen nur ein einziges Konto je Kunde.

Die Hersteller haben dafür eigene Begriffe. Shopware beschreibt Employee Management als Erweiterung der Kontoverwaltung „set into a company context": Mitarbeitende gehören zu einem Firmenkonto, Rollen bündeln Berechtigungen, und Berechtigungen erlauben oder verbieten einzelne Aktionen wie das Bestellen ohne Freigabe. Shopify modelliert dasselbe über Firmen und Standorte. Wie auch immer es heißt — Sie brauchen vorher eine Vorstellung davon, wer beim Kunden was sehen darf.

Die letzte Zeile ist die wichtigste. Wenn beim Kunden niemand berechtigt ist, eigene Nutzer anzulegen und zu sperren, landet diese Arbeit bei Ihnen — und zwar dauerhaft. Ein Portal, das Ihren Innendienst entlasten soll, erzeugt dann eine neue Verwaltungsaufgabe. Delegieren Sie die Nutzerverwaltung von Anfang an an eine benannte Person je Kundenunternehmen.

Wenn Ihre Kunden bereits mit Unternehmens-Anmeldungen arbeiten, lohnt außerdem der Blick auf zentrale Anmeldeverfahren. Was dabei technisch zusammenspielt und warum eine zweite Sicherungsstufe dazugehört, steht im Beitrag zu Single Sign-On im Mittelstand.

8. Datenschutz: vier Pflichten vor dem Livegang

Ein Portal zeigt personenbezogene Daten an Personen außerhalb Ihres Hauses. Damit gelten vier Anforderungen, die vor dem Livegang geklärt sein müssen. Alle Fundstellen sind unten in der Quellensektion verlinkt; der Stand ist der 6. September 2026.

• Sicherheit der Verarbeitung. Artikel 32 Absatz 1 DSGVO verlangt technische und organisatorische Maßnahmen für ein „dem Risiko angemessenes Schutzniveau" und nennt dabei ausdrücklich Pseudonymisierung und Verschlüsselung, die dauerhafte Sicherstellung von Vertraulichkeit und Integrität, die rasche Wiederherstellbarkeit nach einem Zwischenfall sowie ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit. Für ein Portal heißt das konkret: Transportverschlüsselung, eine zweite Sicherungsstufe beim Anmelden, geordnete Protokollierung und ein wiederkehrender Test der Rechte.
• Voreinstellungen und Zugänglichkeit. Artikel 25 Absatz 2 DSGVO verpflichtet dazu, durch Voreinstellung nur die für den Zweck erforderlichen Daten zu verarbeiten — und bezieht das ausdrücklich auf „die Menge der erhobenen personenbezogenen Daten, den Umfang ihrer Verarbeitung, ihre Speicherfrist und ihre Zugänglichkeit". Ein neu angelegter Portalnutzer startet also mit den engsten Rechten, nicht mit den weitesten.
• Meldepflicht bei einer Panne. Zeigt das Portal einem Kunden die Daten eines anderen, ist das eine Verletzung des Schutzes personenbezogener Daten. Artikel 33 Absatz 1 DSGVO verlangt die Meldung an die Aufsichtsbehörde „unverzüglich und möglichst binnen 72 Stunden", nachdem sie bekannt wurde. Rechnen Sie diese Frist ein, bevor sie eintritt: Wer meldet, an wen, mit welchen Angaben.
• Auftragsverarbeitung. Betreibt ein Dienstleister das Portal oder hostet es, brauchen Sie einen Vertrag nach Artikel 28 DSGVO. Welche Punkte darin stehen müssen und wie Anbieter ihn bereitstellen, haben wir im Beitrag zum Auftragsverarbeitungsvertrag aufgeschlüsselt.

Ein häufiges Missverständnis noch zum Thema Einwilligung: Das Anmelde- und Sitzungs-Cookie eines Portals braucht keine Zustimmung. § 25 Absatz 2 Nummer 2 TDDDG nimmt Speicherung und Zugriff auf dem Endgerät von der Einwilligungspflicht aus, wenn sie „unbedingt erforderlich" sind, damit der ausdrücklich gewünschte Dienst bereitgestellt werden kann. Für ein Analyse- oder Marketing-Werkzeug im Portal gilt das dagegen nicht — dort greift die Einwilligungspflicht des Absatzes 1 wie überall sonst.

Und eine Klarstellung, die sich Anbieter gern sparen: Ein Portal ist kein Ersatz für die Auskunft nach Artikel 15 DSGVO. Es zeigt einen von Ihnen gewählten Ausschnitt. Ein Auskunftsersuchen bleibt ein Auskunftsersuchen und braucht einen eigenen Weg.

9. Einführung in vier Etappen

Portalprojekte scheitern selten an der Technik. Sie scheitern daran, dass zu viel auf einmal live geht und niemand weiß, welche Funktion tatsächlich genutzt wird. Vier Etappen halten das Vorhaben klein und überprüfbar:

1. Vier Wochen zählen Bevor irgendetwas gebaut wird, erfassen Sie jede eingehende Kundenfrage in wenigen Kategorien. Diese Strichliste entscheidet über den Funktionsumfang der ersten Stufe — nicht die Feature-Liste eines Anbieters.
2. Datenquellen klären Für jede geplante Funktion halten Sie fest, aus welchem System der Wert kommt, wie aktuell er ist und wer ihn pflegt. Wo diese Antwort fehlt, fehlt später die Funktion oder sie zeigt falsche Werte.
3. Eine Kundengruppe live Starten Sie mit einer überschaubaren Gruppe, die viel bestellt und Ihnen offen Rückmeldung gibt. Zehn bis zwanzig Kunden reichen, um Rollen, Texte und Rechte zu prüfen, bevor alle anderen eingeladen werden.
4. Ausrollen und nachschärfen Erst nach der ersten Nutzungsmessung laden Sie den Rest ein und ergänzen Stufe 2. Was in der Pilotgruppe niemand geöffnet hat, kommt nicht in die zweite Stufe, sondern auf die Liste der offenen Fragen.

Zwei Dinge gehören zusätzlich in den Plan. Erstens die Einladung: Ein Portalzugang, den niemand erklärt, wird nicht genutzt. Der Vertriebsinnendienst sollte ihn beim nächsten Anruf mit anbieten, statt eine Rundmail zu verschicken. Zweitens der Rückweg: Jede Portalseite braucht eine sichtbare Möglichkeit, doch einen Menschen zu erreichen. Ein Portal ohne Ausweg erzeugt Anrufe bei der Zentrale statt beim zuständigen Betreuer.

10. Kennzahlen, die Sie selbst messen müssen

Hier wird es unbequem. Im Netz kursieren zu Kundenportalen viele Prozentzahlen: Entlastung des Innendienstes, Rückgang der Tickets, Self-Service-Quoten. Wir geben davon keine wieder. Diese Werte stammen fast durchgehend von Anbietern, ohne dass Erhebungsmethode, Stichprobe oder Branche nachvollziehbar wären. Auf Ihren Betrieb übertragen sind sie wertlos — und als Erwartung an ein Projekt sogar schädlich.

Was hilft, ist eine eigene Messung mit einem Ausgangswert. Die folgende Tabelle nennt sechs Kennzahlen und sagt zu jeder, wie Sie sie erheben und wann.

Der entscheidende Punkt steht in der ersten Zeile: Ohne Ausgangsmessung gibt es später keinen Nachweis. Die vier Wochen Strichliste vor dem Projekt sind der billigste Teil des ganzen Vorhabens und der einzige, der sich nicht nachholen lässt.

11. Unsere Rolle — und was wir nicht tun

Damit keine falsche Erwartung entsteht: Wir verkaufen keine Portal-Plattform. Wir haben kein eigenes Produkt in diesem Feld, das wir empfehlen müssten, und wir haben kein Interesse daran, dass Sie etwas bauen, das Ihr vorhandenes Shopsystem schon kann. In etlichen Gesprächen endet die Prüfung genau dort — mit ein paar eingeschalteten Funktionen statt eines Projekts.

Was wir tun, liegt davor und daneben. Wir sortieren mit Ihnen die eingehenden Anfragen, klären für jede geplante Funktion die führende Datenquelle und benennen, wo Ihre Stammdaten das Portal blamieren würden — meist bei kundenspezifischen Preisen. Für Handel, Großhandel und Logistik steckt der Rahmen dafür in unserer Digitalisierung für Logistik und Großhandel: Lager, Versand, EDI und die Annahme von Bestellungen aus Firmenkunden-Hand gehören zusammen betrachtet.

Führt die Prüfung zu einer eigenen Anwendung, bauen wir sie — mit KI-gestützter Entwicklung, aber mit menschlicher Prüfung, Tests und Dokumentation. Wie dieser Weg abläuft, steht auf der Seite zur AI-App-Entwicklung mit Vibe Coding. Was wir nicht tun: Wir sind keine Rechtsberatung. Die datenschutzrechtliche Bewertung Ihres konkreten Portals gehört zu Ihrem Datenschutzbeauftragten oder zu einer Kanzlei.

12. Fazit

Ein Kundenportal ist kein Produkt, das man kauft, sondern ein Zuschnitt, den man trifft. Der Zuschnitt ergibt sich aus dem, was Ihr Innendienst täglich beantwortet — nicht aus dem Funktionsumfang eines Anbieters. Vier Funktionen tragen in fast jedem Betrieb die erste Stufe: Auftragsstatus, Belege, Preisliste, Ansprechpartner. Alles Weitere kommt nach der ersten Messung.

Prüfen Sie vorher, was Ihr Shop-Kundenkonto schon zeigt. In vielen Fällen fehlt weniger, als es zu Projektbeginn aussieht, und der schnellste Weg zum Nutzen führt über eingeschaltete Bordmittel statt über ein neues System. Wo die Bordmittel nicht reichen, entscheidet die Ausgangslage zwischen Plattform-Baustein und eigener Anwendung — und beim Lizenzmodell lohnt der zweite Blick, weil manche Plattform nach aktiven Nutzern abrechnet und nicht pro Portal.

Bleibt der Teil, den kein Anbieter gern betont: Rollen und Rechte. Ein Portal für Firmenkunden hat mehrere Nutzer je Kunde mit unterschiedlichem Bedarf. Wer das erst nach dem Livegang klärt, baut zweimal — und riskiert im schlechtesten Fall eine Panne mit 72-Stunden-Frist.

Hinweis: Dieser Artikel ist allgemeine Information und ersetzt keine Rechtsberatung. Die datenschutzrechtliche Bewertung eines konkreten Portals gehört zu Ihrem Datenschutzbeauftragten oder zu einer Kanzlei. Alle Normen, Herstellerangaben und Funktionsbeschreibungen entsprechen dem Stand vom 6. September 2026 und wurden an der DSGVO, § 25 TDDDG, dem JTL-Guide, Microsoft Learn, der Shopware-Entwicklerdokumentation und dem Shopify Help Center geprüft; Produkte ändern sich häufig. Prüfen Sie den Funktionsumfang Ihrer eigenen Version, bevor Sie Kunden etwas zusagen. Angaben ohne Gewähr.

13. Häufige Fragen zum Kundenportal

Was ist ein Kundenportal?

Ein Kundenportal ist ein geschützter Bereich im Web, in dem angemeldete Kunden ihre eigenen Vorgänge selbst einsehen und anstoßen: Aufträge, Lieferstatus, Belege, Reklamationen, Preislisten und Ansprechpartner. Es verkauft nicht in erster Linie, sondern beantwortet Fragen, die sonst als Anruf oder E-Mail im Innendienst landen.

Was ist der Unterschied zwischen Kundenportal und Kundenkonto?

Das Kundenkonto gehört zum Shop und begleitet den Kauf: Adressen, Bestellhistorie, Wunschzettel, manchmal Downloads. Ein Kundenportal umfasst auch Vorgänge ohne Bestellung — Reklamationen, Verträge, Dokumente, Freigaben durch mehrere Personen. Viele Betriebe brauchen kein zweites System, sondern nur ein Kundenkonto, das mehr zeigt als heute.

Was muss ein Kundenportal können?

Zuerst nur das, was Ihr Innendienst am häufigsten beantwortet. In der Regel sind das vier Dinge: Auftragsstatus mit Liefertermin, Belege zum Herunterladen, die aktuelle Preisliste des Kunden und ein Weg, eine Reklamation zu melden. Alles Weitere kommt in die zweite Stufe — nach der ersten Nutzungsmessung.

Wie erstelle ich ein Kundenportal?

In vier Etappen: Anfragen zählen, Datenquellen klären, eine erste Kundengruppe live schalten, dann ausbauen. Technisch stehen drei Wege offen — das vorhandene Shop-Kundenkonto erweitern, einen Portal-Baustein der Shop-Plattform lizenzieren oder eine eigene Anwendung bauen. Die Entscheidung fällt nach der Datenlage, nicht nach dem Funktionsumfang eines Anbieters.

Welche Software eignet sich für ein Kundenportal?

Das hängt davon ab, wo Ihre Daten liegen. Wer einen Shop betreibt, prüft zuerst dessen Bordmittel: Shopware dokumentiert sieben B2B-Module, Shopify beschreibt B2B als native Funktionen für Firmenkunden. Wer kein Shop-Frontend braucht, kommt mit einer Low-Code-Plattform wie Microsoft Power Pages oder einer eigenen Anwendung weiter. Stand: 6. September 2026.

Was kostet ein Kundenportal?

Eine seriöse Pauschale gibt es nicht, und wir nennen deshalb keine. Die Kostentreiber sind benennbar: Zahl der Datenquellen, Sauberkeit der Preis- und Kundenstammdaten, Rollenmodell, Betrieb und Support. Achten Sie auf das Lizenzmodell — Microsoft rechnet Power Pages nach monatlich aktiven Nutzern je Website ab, nicht pauschal pro Portal.

Was ist ein Serviceportal?

Serviceportal wird meist für den Ausschnitt verwendet, der nach dem Kauf beginnt: Störmeldungen, Reklamationen, Garantiefälle, Wartungstermine, Dokumentation zu gelieferten Geräten. Ein Kundenportal kann diesen Ausschnitt enthalten. Der Unterschied ist nicht technisch, sondern eine Frage des Zuschnitts — und der sollte zu Ihren tatsächlichen Anfragen passen.

Braucht jeder Betrieb mit Geschäftskunden ein Portal?

Nein. Wer wenige, große Partner beliefert, fährt mit EDI besser: Bestellung, Lieferavis und Rechnung laufen dann als strukturierte Nachrichten, ganz ohne Oberfläche. Ein Portal lohnt sich bei vielen kleinen und mittleren Kunden mit wiederkehrendem Sortiment — also dort, wo heute viele gleichartige Rückfragen auflaufen.

Welche Datenschutzpflichten gelten für ein Kundenportal?

Artikel 32 DSGVO verlangt technische und organisatorische Maßnahmen mit angemessenem Schutzniveau, Artikel 25 Absatz 2 beschränkt die Zugänglichkeit durch Voreinstellung auf das Erforderliche. Zeigt das Portal fremde Daten, ist das eine meldepflichtige Verletzung — nach Artikel 33 Absatz 1 möglichst binnen 72 Stunden. Betreibt ein Dienstleister das Portal, brauchen Sie einen Auftragsverarbeitungsvertrag.

14. Quellen & offizielle Informationen

Die Angaben in diesem Beitrag stützen sich auf die folgenden Quellen. Alle wurden am 6. September 2026 abgerufen und im Volltext gegengelesen — die Normtexte in der amtlichen Fassung, die Produktangaben ausschließlich bei den Herstellern selbst. Externe Quellen öffnen in einem neuen Tab.

• JTL-Guide — Wunschzettel im Kundenkonto von JTL-Shop anbieten — Belegt den Menüpfad des Kundenkontos: Der angemeldete Kunde erreicht seine Wunschzettel „über das Menü Mein Konto > Meine Wunschzettel oder über das Herz-Symbol im Standard-Template von JTL-Shop".
• JTL-Guide — Download-Artikel mit dem Download-Modul anbieten — Belegt den Bereich „Meine Downloads" im Kundenkonto und die Bedingung dafür: „Sobald die zugehörige Bestellung bezahlt wurde, können die Kunden die Datei hier herunterladen."
• JTL-Guide — Kundenverwaltung in JTL-Wawi — Belegt die Warenwirtschaft als Datenquelle: Wer einen kundenbezogenen Datensatz „wie Aufträge, Rechnungen etc." markiert, erhält „in Echtzeit alle wichtigen Daten" zum Kunden. Dort liegen Kundenstammdaten, Kundengruppen und Kundenkategorien.
• JTL-Forum — Rechnung im Kundenkonto zum Download anbieten — Antwort eines JTL-Mitarbeitenden vom 27. März 2018: „Ist im Shop nicht geplant." 2020 verweist ein Administrator auf ein Plugin. Beide Beiträge sind älter als die heutige Shop-Generation und deshalb nur als Forumsstand mit Datum zitiert.
• Microsoft Learn — Was ist Power Pages? — Herstellerdefinition: eine „sichere, unternehmensweite, Low-Code-Software as a Service (SaaS)-Plattform zum Erstellen, Hosting und Verwalten moderner externer Geschäftswebsites", die auf denselben Daten in Microsoft Dataverse arbeitet. Stand der Seite: 23. April 2026.
• Microsoft Learn — Power Platform licensing FAQs — Das Lizenzmodell von Power Pages: kapazitätsbasiert nach „Authenticated users per website/month" und „Anonymous users per website/month", Paketgröße 100 beziehungsweise 500 Nutzer, Mindestzuweisung 25 beziehungsweise 200 je Umgebung. Stand der Seite: 14. August 2026.
• Microsoft Learn — Kapazität in Power Pages verwalten und überwachen — Bestätigt die beiden Kapazitätskategorien „authenticated MAU" und „anonymous MAU" und beschreibt, wie der Verbrauch je Umgebung und je Website ausgewertet wird. Stand der Seite: 17. März 2025, zuletzt aktualisiert am 31. August 2026.
• Shopware Developer Docs — B2B Components — Nennt die sieben dokumentierten Module: Employee Management, Quote Management, Order Approval, Individual Pricing, Quick Order und Shopping List, Organization Unit sowie Digital Sales Composables. Die Verfügbarkeit je Plan weist Shopware an dieser Stelle nicht eindeutig aus.
• Shopware Developer Docs — Employee Management — Beschreibt das Rollenmodell für Firmenkunden: Mitarbeitende gehören zu einem Firmenkonto, Rollen bündeln Berechtigungen, Berechtigungen erlauben oder verbieten einzelne Aktionen wie das Bestellen ohne Freigabe.
• Shopify Help Center — B2B on Shopify — Beschreibt B2B als „suite of native features", mit der über Shopify-Admin und Onlineshop an Firmen verkauft wird: Firmen als Kundenobjekt, Kataloge mit eigenen Preislisten, Zahlungsbedingungen und Auftragsentwürfe. Zur Verfügbarkeit heißt es, die Funktionen seien „included on plans that support B2B capabilities".
• Verordnung (EU) 2016/679 — Datenschutz-Grundverordnung (EUR-Lex) — Artikel 25 Absatz 2 zu datenschutzfreundlichen Voreinstellungen einschließlich der Zugänglichkeit von Daten, Artikel 28 zur Auftragsverarbeitung, Artikel 32 Absatz 1 zur Sicherheit der Verarbeitung und Artikel 33 Absatz 1 zur Meldung „unverzüglich und möglichst binnen 72 Stunden".
• § 25 TDDDG — Schutz der Privatsphäre bei Endeinrichtungen — Absatz 1 macht Speicherung und Zugriff auf dem Endgerät von einer Einwilligung abhängig. Absatz 2 Nummer 2 nimmt davon aus, was „unbedingt erforderlich" ist, damit der gewünschte digitale Dienst bereitgestellt werden kann. Der Pfad lautet weiterhin ttdsg, die Seite selbst trägt den Titel TDDDG.

Drei Angaben fehlen bewusst. Erstens Preise für Power Pages, die Shopware B2B Components und Shopify B2B: Die Preisseiten der Hersteller laden ihre Tabellen erst im Browser nach, und ohne belegten Stand geben wir keine Zahl wieder. Zweitens die Zuordnung einzelner Shopware-Module zu konkreten Plänen — die Dokumentation weist sie an der geprüften Stelle nicht eindeutig aus. Drittens jede Form von Benchmark zu Self-Service-Quoten, Ticket-Rückgängen oder Amortisationszeiten.