J. Llorente & Cía.

Introduction

J. Llorente is an Argentine distribution company serving a broad network of customers, and in distribution, delivering on time and in full is the business itself. Every order passes through a chain of hands: internal systems that create and invoice it, third-party logistics providers that transport it, and a destination that has to receive the right goods, on time and in the right condition. When that chain works, the customer orders again. When it breaks, the cost goes beyond logistics and reaches the customer's trust.

With a network of that size, the difficulty lies in knowing where each delivery is, how far it has to go and what has gone off course, while the information stays scattered among the people who produce it.

The problem

Logistics information was split between files from the transport provider and internal reports, with no single place to read the actual status of each delivery. Knowing which stage an order had reached, whether it would arrive on time, whether a delay came from the warehouse or from transport, or whether the signed proof of delivery had come back, meant cross-checking spreadsheets and asking several people. Every answer was a manual reconstruction.

That had two costs. The first was reaction time: deviations surfaced late, once the customer had already called, because there was no dashboard raising the alert in time. The second was analysis: measuring performance by customer, destination or process stage was close to impossible when the data shared no common structure. The operation kept moving without a reliable reading of its own status.

The solution

We built a tracking application that connects to Llorente's ERP through an API, adds the information from the transport provider's files, and turns that flow into a single, organized and actionable base. The integration is what makes the operation automatic: orders and their statuses arrive from the ERP with no manual re-entry, instead of being copied from one system to another. On top of that base, each order lives as a single record that moves through the real stages of the process, from loading to signed receipt, including sales and credit release, invoicing, truck loading, dispatch and delivery, so the status of every order is looked up instead of reconstructed.

Each delivery brings together the variables that used to be scattered: delivery number, recipient, location, process dates, ETA, lead time, status in the transport management system (TMS), on-time performance and proof of delivery. A module of configurable ETAs sets the expected time for each stage, and with that parameter the application tells apart what is moving normally from what is falling behind. The main dashboard summarizes the operation at a glance and flags the orders that need attention, those with several days and no movement, before they turn into a complaint.

The piece that defines the case is the channel. In Latin America, WhatsApp is where day-to-day business coordination happens, between internal teams and with external providers alike. Instead of asking the team and the transport providers to adopt a new tool, we built access on top of WhatsApp: an order opens from the same place where the operation is already coordinated, its details can be checked and its status updated from a phone. What used to be a chain of loose messages and spreadsheets became an operation with a record, with no added adoption friction. Around that core, the application handles roles by user type, customer and sales rep management, and an audit log that records who changed what and when.

Results

• End-to-end traceability. The actual status of each delivery, with its dates, ETA and proof of delivery, is read in one place instead of being rebuilt by cross-checking files.

• Deviations caught early. Expected times per stage and the dashboard of orders that need attention expose delays while they can still be corrected.

• From manual to automated. The API integration with the ERP feeds tracking with no manual re-entry: data and statuses that used to be copied between systems and spreadsheets now flow on their own, with a record of every change.

• The operation on WhatsApp. Checking and updating deliveries from the channel the team and its providers already use removed the barrier of adopting a new tool.

Conclusion

A generic dashboard would have displayed the data and left the underlying problem untouched: the logistics operation happens in the back-and-forth of messages between the team and its providers, far from a desktop screen. Building the solution to measure made it possible to meet the operation there, on WhatsApp, and turn that flow into an operation with traceability without asking anyone to change how they work. The software is the evidence that we understood the operation.