Every morning at 07:30, the operations manager of a mid-sized logistics company in Greater Jakarta started his day the same way: forty minutes of phone calls. Calling drivers to ask where they were. Calling warehouse leads to ask what had shipped. Calling the branch in Bandung to ask about yesterday's undelivered packages. Then he would assemble the answers into a WhatsApp message for the directors, and by 08:15 the information was already stale.
This logistics dashboard case study is about what happened when that company consolidated fleet position, driver status, and delivery progress into one screen. The technical build was straightforward. The interesting part, and the reason I am writing this up, is that the biggest return was not operational. It was political.
The company runs around 45 vehicles, 60 drivers, and roughly 1,200 delivery orders a day across Java. Names and details are anonymized, but the numbers are representative of what a firm this size actually deals with.
The Starting Point: Data Everywhere, Truth Nowhere
Before the project, the company was not short on data. They had GPS trackers on most trucks, installed two years earlier by a fleet-tracking vendor. They had a delivery order system, partly a legacy desktop app and partly Excel. Drivers reported status through three different WhatsApp groups. The Bandung and Semarang branches each kept their own spreadsheets.
The problem was that none of these sources agreed with each other, and no single person could see all of them. Specific symptoms:
- The morning phone ritual. Forty minutes daily of the ops manager manually building a picture that a system should have handed him.
- The ops-versus-sales war. Sales promised delivery windows to customers based on their spreadsheet. Ops worked from a different one. When a shipment was late, each side had "proof" the other was wrong, and the weekly management meeting regularly burned an hour relitigating whose numbers were real.
- Invisible idle assets. Nobody could answer "which trucks are parked right now, and why?" without a round of calls.
- Customer status queries routed through CS to ops to a driver's WhatsApp and back, a 2 to 4 hour round trip for a question that deserved a 10-second answer.
What We Built, and What We Deliberately Did Not
The mandate was one screen of shared truth, not a new ERP. Scope discipline mattered because the company had already lived through a failed "big system" attempt years earlier, the kind of stalled project I described in how to rescue a failed digital transformation project.
The build, delivered over about four months:
- Integrate, do not replace. We pulled GPS positions from the existing tracker vendor's API instead of installing new hardware. The legacy delivery order data was synced into a small central database. Total new hardware cost: zero rupiah.
- A driver status app replaced WhatsApp check-ins. Simple by design: accept manifest, depart, arrive, delivered with photo proof, or failed with a reason code. Five buttons, built as a mobile web app so nothing needed installing.
- The dashboard itself. One web screen showing every vehicle on a map, every delivery order with live status, per-branch summaries, and an exceptions panel: late departures, stalled vehicles, failed deliveries. Color-coded, readable on the TV in the ops room and on a director's phone.
- Role-based views. Sales got read access to delivery status. That single decision turned out to be the most valuable line in the spec.
Total project cost landed in the low hundreds of millions of rupiah, meaningful money, but a fraction of the "replace everything" quotes the company had collected earlier.
The Biggest Win Was Political, Not Technical
Here is the part vendors rarely tell you. Within a month of go-live, the weekly ops-versus-sales argument simply died. Not because anyone got better at arguing, but because there was nothing left to argue about. When sales and ops look at the same screen showing the same truck and the same timestamped delivery events, "your data is wrong" stops being an available move.
The ops manager put it plainly: the dashboard did not just save him forty minutes of calls, it saved him from being the human battleground between two departments. One shared truth is a conflict-resolution mechanism. In organizations where every department keeps a private spreadsheet, disputes are unfalsifiable, and unfalsifiable disputes become permanent. Shared, timestamped data makes disagreements finite. Someone is right, the screen says who, everyone moves on.
If you take one lesson from this logistics dashboard case study, take that one. Visibility projects get justified with efficiency numbers, but their deepest value is often that they end wars.
Measured Results After Six Months
The efficiency numbers came too:
| Metric | Before | After 6 months |
|---|---|---|
| Morning status assembly | ~40 minutes of calls | Under 5 minutes, read from screen |
| Customer status query turnaround | 2 to 4 hours | Under 15 minutes |
| Trucks idle without a logged reason | Unknown | Identified: 4 to 6 daily, then cut roughly in half |
| Weekly management meeting time on "whose data" disputes | ~1 hour | Effectively zero |
| On-time delivery rate | Not reliably measurable | Baselined, then improved 9 points |
The idle-asset finding deserves a note. Once every truck was on one map with status reasons, the company discovered it effectively owned 4 to 6 trucks' worth of daily idle capacity hidden across branches. They deferred two planned vehicle purchases, worth more than the entire project cost, because the dashboard proved the capacity already existed.
And notice the on-time delivery row: before the project, the number could not even be trusted. You cannot improve a metric two departments cannot agree on.
What Made It Work
- Integration over replacement. Reusing the GPS vendor and legacy order data cut cost and, more importantly, cut resistance. Nobody had to abandon a tool mid-project.
- The driver app was boring on purpose. Five buttons, in Indonesian, tested with the least tech-comfortable drivers first. Adoption problems kill these projects far more often than technical problems.
- An executive owned it. The operations director personally ran the morning standup from the dashboard starting week one. When leadership reads from the screen, the screen becomes the truth.
- Exceptions, not noise. The dashboard leads with what is wrong right now, so people check it because it is useful, not because they are told to.
The Takeaway
If your managers start each day reconstructing reality by phone, and your departments argue from competing spreadsheets, you do not need an ERP replacement. You need one screen of shared, timestamped truth, built mostly by integrating what you already own. Priced with discipline, a project like this pays for itself in deferred purchases and recovered management time within a year, and the ceasefire between departments comes free. If your operation sounds like the "before" section of this story, I help companies scope exactly this kind of build, starting with what you already have.