Lieferverzug automatisch kommunizieren
obwohl die Warenwirtschaft es nicht hergibt
Intersince, Anbieter von Brandmelde- und Sicherheitstechnik mit rund 50 Mitarbeitern, hatte hunderte offene Aufträge. Platzte ein Liefertermin, musste jemand den Kunden von Hand informieren. Das passierte unzuverlässig – also wurde die fehlende Logik neben JTL gebaut.
Der Kunde ruft an, statt informiert zu werden
Bei hunderten offenen Aufträgen ließ sich die Kundeninformation bei Verzug nicht zuverlässig von Hand erledigen. Kunden riefen an, statt rechtzeitig Bescheid zu bekommen.
Automatisieren ließ sich das nicht, weil JTL die nötige Verknüpfung nicht maschinenlesbar bereitstellt. Die Bezugsauftragsnummer ist ein Freitextfeld. Liefertermine hängen am Auftrag, nicht an der einzelnen Position. Und direkte Eingriffe in die Datenbank sind bei Updates nicht belastbar.
Damit fiel die naheliegende Lösung aus. Es gab keine Verbindung zwischen Lieferantenbestellung und Kundenauftrag, auf die sich ein Workflow hätte aufsetzen lassen.
Statt JTL zu biegen, daneben gebaut
Ein eigenes Portal pflegt die Lieferdaten artikelbasiert – pro Artikelnummer, Menge und Termin. Eine FIFO-Verteilung ordnet eingehende Mengen nach Bestelleingang den offenen Aufträgen zu und bildet auch Teillieferungen ab. Vor jedem Mailversand zieht das Portal den aktuellen Stand aus JTL, damit geänderte Positionen nicht zu falschen Benachrichtigungen führen. Im Kern ist das eine saubere CRM-Integration zwischen Warenwirtschaft und HubSpot.
Wie die Benachrichtigung entsteht
Lieferdaten artikelbasiert pflegen
Das Portal hält die Lieferdaten pro Artikelnummer, Menge und Termin – unabhängig davon, dass JTL den Termin nur am Auftrag kennt.
FIFO-Verteilung auf offene Aufträge
Eingehende Mengen werden nach Bestelleingang den offenen Aufträgen zugeordnet. Reicht eine Lieferung nicht für alle, bildet die Logik Teillieferungen korrekt ab.
Stand aus JTL abgleichen
Vor jedem Versand zieht das Portal den aktuellen Stand aus JTL. Gelöschte oder geänderte Positionen lösen so keine falschen Benachrichtigungen aus.
Automatischer Mailversand
Der Kunde wird proaktiv über die Verzögerung informiert – ohne dass jemand den Auftrag von Hand heraussucht und nachpflegt.
Nebenbei: die Dubletten beseitigt
Damit die Benachrichtigungen beim richtigen Kunden landen, musste auch der Abgleich zwischen JTL und HubSpot stimmen. Vorher liefen Firmen mit gleichem Namen, aber unterschiedlichen Adressen als Dubletten ein.
Kundennummer als eindeutiger Schlüssel
Der Sync wurde auf die Kundennummer umgestellt statt auf den Firmennamen. Jeder Kunde landet damit genau einmal im CRM.
Keine doppelten Datensätze mehr
Firmen mit gleichem Namen, aber anderer Adresse werden nicht mehr als getrennte Dubletten angelegt.
Abgleich vor jedem Versand
Der aktuelle Auftragsstand kommt direkt aus JTL. Die Warenwirtschaft bleibt die führende Quelle.
Aus Projekt wurde Zusammenarbeit
Was als HubSpot-Einführung begann, ist eine laufende Zusammenarbeit geworden.
Vorher vs. Nachher
Vorher – Handarbeit
- Kunde pro Auftrag von Hand informieren
- Bei hunderten Aufträgen unzuverlässig
- Kunden rufen an, statt Bescheid zu bekommen
- Dubletten im CRM durch Name-Matching
Nachher – proaktiv & automatisch
- Kunden werden proaktiv über Verzug informiert
- Kein Nachpflegen pro Auftrag
- Teillieferungen korrekt abgebildet
- Jeder Kunde genau einmal in HubSpot
Für wen sich das lohnt
Händler mit JTL-Wawi und vielen offenen Aufträgen
Bei denen Lieferverzug manuell kommuniziert wird und deshalb liegen bleibt.
Teams, die an Grenzen der Warenwirtschaft stoßen
Wenn die nötige Verknüpfung im System nicht maschinenlesbar vorliegt und ein Standard-Workflow ausfällt.
Betriebe mit Dubletten im CRM
Die ihren JTL-HubSpot-Abgleich auf einen eindeutigen Schlüssel umstellen wollen.
Fragen & Antworten
Die Verbindung zwischen Lieferantenbestellung und Kundenauftrag ist in JTL nicht maschinenlesbar: Die Bezugsauftragsnummer ist ein Freitextfeld, und der Liefertermin hängt am Auftrag, nicht an der einzelnen Position. Darauf lässt sich kein verlässlicher Workflow aufsetzen. Deshalb wurde die fehlende Logik neben der Warenwirtschaft gebaut statt in ihr.
Es pflegt Lieferdaten artikelbasiert – pro Artikelnummer, Menge und Termin. Eine FIFO-Verteilung ordnet eingehende Mengen nach Bestelleingang den offenen Aufträgen zu und bildet auch Teillieferungen ab.
Ja. Die FIFO-Logik verteilt eine eingehende Menge auf mehrere offene Aufträge, wenn sie nicht für alle reicht. Jeder Auftrag bekommt den Stand, der ihm tatsächlich zusteht.
Vor jedem Mailversand zieht das Portal den aktuellen Stand aus JTL. Gelöschte oder geänderte Positionen führen so nicht zu falschen Benachrichtigungen.
Parallel wurde der Abgleich zwischen JTL und HubSpot auf die Kundennummer als eindeutigen Schlüssel umgestellt. Vorher liefen Firmen mit gleichem Namen, aber unterschiedlichen Adressen als Dubletten ein. Jetzt landet jeder Kunde genau einmal im CRM.
Das Prinzip schon: fehlende Logik neben dem System ergänzen, vor jedem Schritt gegen die Quelle abgleichen, kontrolliert nach außen kommunizieren. Die konkrete Umsetzung hängt davon ab, welche Daten das jeweilige System maschinenlesbar bereitstellt.
Stößt deine Warenwirtschaft an Grenzen?
Lass uns in einem kostenlosen Gespräch schauen, was sich neben deinem System ergänzen lässt, wenn es selbst nicht mitspielt.