B2B-Kundenportal mit Laravel und Vue.js entwickeln

Ein B2B-Kundenportal mit Laravel und Vue.js zu entwickeln lohnt sich, wenn Ihre Geschäftskunden regelmäßig nach Preisen, Verfügbarkeiten, Auftragsstatus oder Rechnungskopien fragen und diese Anfragen heute per Telefon und E-Mail im Innendienst landen. Das Portal bündelt diese Informationen an einem Ort, nimmt Bestellungen direkt entgegen und überträgt sie ins ERP. Laravel übernimmt dabei Geschäftslogik, Rechte, Schnittstellen und Hintergrundprozesse, Vue.js die bedienfreundliche Oberfläche. Im Folgenden beschreiben wir, welche Funktionen ein Portal zum Start braucht, wie die Architektur aussieht und wie Sie ein solches Projekt ohne Risiko für das laufende Geschäft einführen.

Wofür Ihre Kunden das Portal nutzen

Einkäufer im B2B-Umfeld wollen vor allem eines: schnell und verlässlich bestellen, ohne auf einen Rückruf zu warten. Aus den Anfragen, die im Innendienst ankommen, lassen sich die Kernfunktionen meist direkt ableiten:

• „Welcher Preis gilt für uns?“ – kundenindividuelle Preise, Staffeln und Konditionen aus dem ERP.
• „Ist der Artikel lieferbar?“ – verfügbarer Bestand und Lieferzeit, nicht nur „auf Lager“.
• „Wo ist meine Bestellung?“ – Auftragsstatus, Lieferschein, Sendungsverfolgung.
• „Schicken Sie mir bitte die Rechnung noch einmal.“ – Rechnungen, Gutschriften und Dokumente zum Download.
• „Wir bestellen dasselbe wie letzten Monat.“ – Nachbestellung aus der Historie, Schnellbestellung per Artikelnummer oder Datei-Upload.

Hinzu kommen Funktionen, die das B2B-Geschäft vom Onlineshop unterscheiden: Firmenkonten mit mehreren Benutzern, Rollen wie Besteller, Freigeber und Administrator, Bestelllimits sowie Verpackungseinheiten und Mindestmengen.

Architektur im Überblick

Ein Kundenportal besteht aus drei Schichten, die klar getrennt sein sollten:

1. Oberfläche mit Vue 3 – Katalog, Warenkorb, Kundenkonto, Dokumente.
2. Anwendung mit Laravel – Benutzer und Rollen, Preislogik, Bestellprozess, Benachrichtigungen, Protokollierung.
3. Integrationsschicht – Anbindung an ERP, gegebenenfalls PIM, Versanddienstleister und Buchhaltung, mit Warteschlangen und regelmäßigem Datenabgleich.

Inertia.js oder eigenständige Single-Page-Anwendung?

Für die meisten Portale setzen wir auf Inertia.js mit Vue 3: Laravel steuert Routing und Controller, die Seiten sind Vue-Komponenten. Es entsteht keine zusätzliche API nur für die Oberfläche, die Anmeldung läuft über normale Laravel-Sessions, und ein kleines Team kommt zügig voran.

Eine eigenständige SPA mit Laravel-API ist sinnvoll, wenn dieselbe Schnittstelle später auch eine mobile App oder Partnersysteme bedienen soll oder wenn Frontend- und Backend-Teams getrennt arbeiten. Der Mehraufwand für API-Versionierung und Token-Verwaltung sollte dann bewusst eingeplant werden.

In beiden Fällen arbeiten wir mit Composition API, TypeScript und Vite. Wie wir datenintensive Oberflächen mit großen Tabellen und Filtern performant halten, beschreiben wir im Beitrag Vue.js-Frontend-Entwicklung für Admin-Panels.

Warum Laravel im Backend

• Rechte und Rollen lassen sich mit Policies und Gates sauber abbilden – etwa „Besteller bis zu einem Limit, darüber Freigabe“.
• Hintergrundprozesse wie ERP-Abgleich, PDF-Erzeugung und E-Mails laufen über Queues mit Redis und werden mit Horizon überwacht.
• Geplante Aufgaben wie der nächtliche Bestandsabgleich laufen über den Laravel-Scheduler.
• Suche im Katalog über Laravel Scout mit Meilisearch oder Typesense.
• Wartbarkeit: Aktuelle Laravel-Versionen setzen modernes PHP ab 8.3 voraus, haben einen planbaren Release-Zyklus und eine große Entwicklergemeinschaft – wichtig, wenn das Portal über viele Jahre betrieben wird.

Die ERP-Anbindung entscheidet über den Erfolg

Das Portal ist nur so gut wie seine Daten. Deshalb planen wir die Anbindung an das ERP von Anfang an mit:

• Stammdaten (Artikel, Kunden, Preislisten) werden zeitgesteuert und bei Änderungen aus dem ERP übernommen.
• Preise werden entweder im Portal nach denselben Regeln berechnet oder als fertige Kundenpreislisten vom ERP geliefert – entscheidend ist, dass Warenkorb und Rechnung übereinstimmen.
• Bestellungen gehen über eine Warteschlange ins ERP, mit der Portal-Auftragsnummer als Idempotenzschlüssel, damit Wiederholungen keine Dubletten erzeugen.
• Status, Lieferscheine und Rechnungen laufen zurück ins Kundenkonto.

Ist das ERP kurzzeitig nicht erreichbar, können Kunden trotzdem bestellen; die Aufträge werden nachgeliefert. Mehr zur Integrationsschicht lesen Sie unter API-Integrationen für ERP, CRM und E-Commerce.

Rahmenbedingungen im DACH-Raum

• Datenschutz: Hosting in der EU, Auftragsverarbeitungsverträge mit allen Dienstleistern, sparsame Protokollierung personenbezogener Daten.
• Mehrsprachigkeit: Deutsch und Englisch sind häufig Pflicht, bei Kunden in Nachbarländern weitere Sprachen. Übersetzungen von Artikeltexten sollten aus PIM oder ERP kommen, nicht im Portal gepflegt werden.
• Barrierefreiheit: Das Barrierefreiheitsstärkungsgesetz richtet sich vor allem an Angebote für Verbraucher. Ob ein reines B2B-Portal betroffen ist, sollten Sie im Einzelfall prüfen lassen – eine gut bedienbare, tastaturfreundliche Oberfläche ist aber ohnehin sinnvoll.
• Rechnungsdokumente: Wenn Ihr ERP bereits E-Rechnungen erzeugt, kann das Portal diese zusätzlich zum PDF zum Download anbieten.

Sicherheit und Zugriffskontrolle

• Jede Datenabfrage ist zentral auf das Firmenkonto des angemeldeten Benutzers beschränkt – nicht nur in einzelnen Controllern.
• Rollen und Limits (wer bestellen, freigeben, Preise oder Rechnungen sehen darf) sind je Kunde konfigurierbar.
• Einladungen, Passwort-Zurücksetzung und optional Zwei-Faktor-Anmeldung übernimmt das Portal; für Großkunden lässt sich Single Sign-on ergänzen.
• Änderungen an Adressen und Benutzern werden mit Person und Zeitpunkt protokolliert.
• Dokumente werden über signierte, zeitlich begrenzte Links ausgeliefert, nicht über öffentliche Dateipfade.

Wann sich ein eigenes Portal nicht lohnt

Wenn Sie nur wenige Geschäftskunden mit einfachen, einheitlichen Preisen haben, reicht oft die B2B-Funktion eines bestehenden Shopsystems oder ein regelmäßiger Preislistenversand. Ein individuell entwickeltes Portal rechnet sich vor allem dann, wenn Konditionen komplex sind, viele Kunden regelmäßig nachbestellen oder das ERP Anforderungen stellt, die Standardlösungen nur mit großem Anpassungsaufwand abdecken.

Typische Fehler

• Onlineshop mit Login statt Kundenportal. Firmenkonten, Konditionen und Dokumente müssen von Anfang an mitgedacht werden.
• Abweichende Preise. Unterscheidet sich der Preis im Warenkorb von der Rechnung, verliert das Portal schnell das Vertrauen der Kunden. Vor dem Start Preise für eine Stichprobe von Kunden und Artikeln vergleichen.
• Einheiten nicht gemappt. „1 Karton“ muss als korrekte Anzahl Basiseinheiten im ERP ankommen.
• Start mit allen Kunden gleichzeitig. Eine Pilotgruppe deckt Bedienprobleme günstig auf.
• Keine Verantwortung im Haus. Jemand im Vertrieb oder Innendienst muss Konten, Inhalte und Rückmeldungen betreuen.

Einführung in Etappen

1. Analyse: Kundengruppen, Preisregeln, Schnittstellen des ERP, benötigte Dokumente.
2. Informationsportal: Katalog, Preise, Bestände, Auftragshistorie und Rechnungen – bestellt wird noch auf dem bisherigen Weg.
3. Bestellfunktion: Warenkorb, Schnell- und Nachbestellung, Übertragung ins ERP, zunächst mit manueller Prüfung.
4. Self-Service: Benutzerverwaltung, Lieferadressen, Retouren.
5. Erweiterungen: Freigabeprozesse, Angebotsanfragen, Auswertungen, weitere Sprachen.

Nächster Schritt

Sammeln Sie eine Woche lang die Kundenanfragen, die im Innendienst ankommen, und ordnen Sie sie grob nach Themen. Die drei häufigsten Themen bilden den Kern der ersten Portalversion. Details zu unserem Vorgehen finden Sie auf der Seite B2B-Kundenportal; für ein erstes Gespräch über Ihre Preislogik und Ihr ERP können Sie uns gern kontaktieren.