Ausgangslage
Die Großhandelskunden des Herstellers schickten Bestellungen auf verschiedenen Wegen: über die Website und über Messenger. Danach durchlief jede Bestellung eine lange Kette: Prüfung, Kommissionierung, Abgleich, Dokumente und Zahlungskontrolle.
Der schwierigste Punkt in diesem Prozess ist das Gewicht. Fleischprodukte werden mit dem tatsächlichen Gewicht kommissioniert, das vom bestellten abweicht, daher ändert sich der Rechnungsbetrag erst nach dem Zusammenstellen der Bestellung. Das muss in den Dokumenten und in der Abrechnung mit dem Kunden berücksichtigt werden.
Eine eigene Aufgabe war die Kundenstruktur. Ein Großhändler kann mehrere Lieferadressen, mehrere Logins für seine Mitarbeitenden und mehrere juristische Personen haben, auf die Rechnungen ausgestellt werden. Das übliche Schema „ein Kunde, ein Konto“ funktioniert hier nicht.
Die Kunden brauchten außerdem ein eigenes Portal: Katalog ansehen, Bestellungen aufgeben, Rechnung, Finanzen und aktuelle Schulden einsehen, ohne den Manager anzurufen. Da das Portal mit Finanzdaten arbeitet, waren die Anforderungen an die Sicherheit beim Login und bei der Datenspeicherung hoch.
Was wir getan haben
„Hurtom“ haben wir auf Basis des CRM für Marktplätze aufgebaut, das wir zuvor für denselben Hersteller entwickelt hatten. Derselbe Stack (Next.js 16, React 19, Tailwind CSS v4, Supabase, Vercel), fertige Benachrichtigungen, Rollen und Prozesslogik ermöglichten es, nicht bei null anzufangen. Deshalb haben wir die erste funktionsfähige Version mit allen Modulen, mobiler Version und Kundenportal in einer einzigen nächtlichen Arbeitssitzung von etwa 3 Stunden zusammengestellt.
CRM für das Team (19 Ansichten)
- Bestellungen mit Rechnung und Bearbeitungsschritten;
- Kunden mit Lieferadressen, mehreren Logins und mehreren juristischen Personen;
- Produkte, Preise und Aktionen;
- Analysen, Integrationen, Benutzer;
- Rollen für Administrator, Manager und Operator.
Portal für Großhandelskunden (9 Ansichten)
Katalog, Warenkorb, Bestellungen, Rechnung, Finanzen und Schulden, Profil. Das Portal hat keine eigene Datenbank und arbeitet ausschließlich über die API des CRM, sodass die Daten immer identisch sind.
Sicherheit
- das Login-Token ist an die Passwortversion gebunden: Nach dem Zurücksetzen des Passworts werden alle Sitzungen sofort beendet;
- Limits gegen das Erraten von Passwörtern pro Login und pro IP-Adresse;
- die Daten liegen in einem geschlossenen Schema, das über die öffentliche API nicht erreichbar ist, der Zugriff erfolgt nur über serverseitige Funktionen;
- tägliches Backup um 01:30, die letzten 30 Snapshots werden aufbewahrt.
Ergebnis
Im Oktober 2026 erhielt der Hersteller zwei verbundene Systeme: ein CRM mit 19 Ansichten für das Team und ein Portal mit 9 Ansichten für Großhandelskunden. Bestellungen von der Website gehen nicht mehr zwischen Messengern verloren, und Rechnung, tatsächliches Gewicht, Dokumente und Schulden sind in einer Karte sichtbar.
Was das dem Unternehmen bringt:
- der Kunde sieht seine Bestellungen, Rechnungen und offenen Beträge selbst;
- der Manager arbeitet mit der gesamten Kundenstruktur: Lieferadressen, Logins, juristische Personen;
- Preise und Aktionen werden an einem Ort gepflegt;
- die Daten sind auf Architekturebene geschützt und nicht nur durch ein Passwort.
Als nächsten Schritt planen wir die Synchronisierung mit 1C (BAF), damit Dokumente und Abrechnungen nicht doppelt im Buchhaltungssystem erfasst werden.
Was dieses Projekt besonders macht
Die wichtigste Besonderheit ist Geschwindigkeit ohne Qualitätsverlust. Die erste Version stand nach etwa 3 Stunden, nicht weil wir die Aufgabe vereinfacht hätten, sondern weil wir bewährte Bausteine des vorherigen CRM wiederverwendet haben: Rollen, Benachrichtigungen, Prozessschritte. Für das Unternehmen bedeutet das, dass jedes weitere Produkt auf der gemeinsamen Basis schneller umgesetzt wird.
Die zweite Besonderheit ist das Kundenportal ohne eigene Datenbank. Alle Daten laufen über die API des CRM, daher besteht kein Risiko, dass im Portal und beim Manager unterschiedliche Zahlen stehen. Das geschlossene Datenschema und die Bindung der Sitzungen an die Passwortversion schließen typische Schwachstellen von Kundenportalen.
Veröffentlicht: · Aktualisiert: