Communicate delivery delays automatically
even when the ERP won't support it
Intersince, a provider of fire-safety and security technology with around 50 employees, had hundreds of open orders. When a delivery date slipped, someone had to inform the customer by hand. That happened unreliably – so the missing logic was built next to JTL.
The customer calls in, instead of being informed
With hundreds of open orders, informing customers about delays by hand simply wasn't reliable. Customers called in instead of hearing about it in time.
It couldn't be automated, because JTL doesn't expose the necessary link in a machine-readable way. The reference order number is a free-text field. Delivery dates sit on the order, not on the individual line item. And writing directly into the database isn't robust across updates.
That ruled out the obvious solution. There was no connection between the supplier order and the customer order that a workflow could have been built on.
Instead of bending JTL, build beside it
A dedicated portal maintains the delivery data per article – by article number, quantity, and date. A FIFO distribution assigns incoming quantities to the open orders in order sequence and also handles partial deliveries. Before every email send, the portal pulls the current status from JTL so that changed line items don't trigger incorrect notifications. At its core, this is a clean CRM integration between the ERP and HubSpot.
How the notification comes together
Maintain delivery data per article
The portal holds delivery data by article number, quantity, and date – regardless of the fact that JTL only knows the date at the order level.
FIFO distribution across open orders
Incoming quantities are assigned to the open orders in the sequence they were ordered. When a delivery isn't enough for all of them, the logic represents partial deliveries correctly.
Reconcile the status from JTL
Before every send, the portal pulls the current status from JTL. Deleted or changed line items therefore don't cause incorrect notifications.
Automatic email delivery
The customer is proactively informed about the delay – without anyone pulling up and updating the order by hand.
Along the way: the duplicates removed
For the notifications to reach the right customer, the sync between JTL and HubSpot had to be right too. Previously, companies with the same name but different addresses came in as duplicates.
Customer number as the unique key
The sync was switched to the customer number instead of the company name. Each customer therefore lands in the CRM exactly once.
No more duplicate records
Companies with the same name but a different address are no longer created as separate duplicates.
Reconciliation before every send
The current order status comes straight from JTL. The ERP stays the leading source of truth.
A project turned into a partnership
What began as a HubSpot rollout has become an ongoing collaboration.
Before vs. after
Before – manual work
- Inform the customer by hand, per order
- Unreliable across hundreds of orders
- Customers call in instead of being told
- Duplicates in the CRM from name matching
After – proactive & automatic
- Customers are proactively informed about delays
- No per-order upkeep
- Partial deliveries represented correctly
- Each customer exactly once in HubSpot
Who this pays off for
Merchants on JTL ERP with many open orders
Where delivery delays are communicated manually and therefore fall through the cracks.
Teams hitting the limits of their ERP
When the necessary link isn't available in the system in a machine-readable form and a standard workflow is off the table.
Businesses with duplicates in the CRM
That want to switch their JTL–HubSpot sync to a unique key.
Questions & answers
The link between the supplier order and the customer order is not machine-readable in JTL: the reference order number is a free-text field, and the delivery date sits on the order, not on the individual line item. There is nothing reliable to build a workflow on. So the missing logic was built next to the ERP rather than inside it.
It maintains delivery data per article – by article number, quantity, and date. A FIFO distribution assigns incoming quantities to the open orders in the sequence they were ordered, and it also handles partial deliveries.
Yes. When an incoming quantity isn't enough for every order, the FIFO logic splits it across several open orders. Each order gets the status that actually applies to it.
Before every email send, the portal pulls the current status from JTL. Deleted or changed line items therefore don't trigger incorrect notifications.
In parallel, the sync between JTL and HubSpot was switched to the customer number as the unique key. Previously, companies with the same name but different addresses came in as duplicates. Now each customer lands in the CRM exactly once.
The principle, yes: add the missing logic next to the system, reconcile against the source before every step, and communicate outward in a controlled way. The concrete implementation depends on which data the respective system exposes in a machine-readable form.
Is your ERP hitting its limits?
Let's take a free call to look at what can be added next to your system when the system itself won't play along.