Skip to content
MJCX Studio
Start hereHome Check the proofProjects What we buildServices Meet the teamAbout Talk to us →
Case study

12 Drivers. One WhatsApp Group.

CooljekCold Chain LogisticsIndonesia
Cooljek — Cold-chain last-mile delivery ERP
Image for illustration only

What the founder wanted to work on next

The company operates as a cold-chain last-mile delivery provider in Jakarta — 12 drivers, a fleet of refrigerated motorcycles, B2B customers who need frozen, chilled, and ambient goods delivered reliably. The business bridges the gap between food producers and end-point delivery, a growing logistics segment in Indonesia.

The operation worked, but it was held together by WhatsApp and manual effort. The founders wanted to professionalize — serve more customers, onboard B2B clients who expect system integration, and scale the fleet without scaling the ops team proportionally.

Where they were stuck

WhatsApp was the primary channel for everything — driver coordination, delivery assignment, attendance confirmation, and proof of delivery photos — all mixed in one group chat. Finding a specific delivery photo meant scrolling through the entire chat history.

Route planning was manual: the ops team typed delivery addresses into Google Maps one by one. No clustering by area, no sequencing optimization. When a driver didn’t show up on delivery day, the only fallback was ad-hoc calls to backup drivers.

GPS trackers were already installed on motorcycles, but the data lived on the vendor’s separate dashboard — not connected to orders or driver assignments. Customers had to call or WhatsApp to check delivery status. B2B customers with their own ERP/WMS had no automated connection to the company’s operations.

Route VisibilityLow
Dispatch CoordinationMedium
Proof & AccountabilityHigh

How we worked together through the CGA

An initial meeting followed by an operational process mapping session on 15 July 2026 — mapping the full daily cycle from order intake through dispatch, delivery execution, and post-delivery. We observed the WhatsApp coordination, rode along on delivery runs, and documented every manual touchpoint.

The pattern was clear: the operational knowledge existed, the drivers were skilled, and the customer relationships were strong. But every coordination task — assigning routes, confirming attendance, tracking deliveries, sharing proof — ran through a single WhatsApp group. The system couldn’t scale because the coordination couldn’t scale.

The build

A full operational platform covering order intake to delivery completion and customer access. Web dashboard for admin and customers, with an optional Flutter driver app.

Orders flow in through three channels: manual entry from WhatsApp/phone/email, self-service via a B2B customer portal, or automated inbound via REST API from client ERP/WMS systems. All three merge into a single admin queue for review and confirmation.

The night before delivery, an automated check-in fires at 18:00 — drivers tap Confirmed or Unavailable with a reason. Cutoff at 20:00. Non-responders auto-flag as no-show. Two of twelve drivers rotate as daily standby. If a primary driver doesn’t show, the admin activates a standby with one tap — no phone calls needed.

Then the route optimization algorithm takes over: all confirmed orders geocoded, clustered by area, assigned to available drivers, stops sequenced in most efficient order, ETAs estimated. The admin reviews on a map, can drag-drop orders between drivers, reorder stops, and override suggestions before confirming.

During delivery, live GPS tracking scrapes sensor data every 30 seconds from the existing vendor dashboard and projects it onto the company’s unified interface. Customers track deliveries two ways: a shareable tracking link (no login, real-time driver position, ETA, POD photo after completion — expires 24 hours after delivery) or through the customer portal (full order history, POD gallery, never expires).

Proof of delivery is mandatory — drivers photograph evidence, the system auto-attaches timestamp, GPS coordinates, order ID, and driver ID. No delivery can be marked complete without at least one photo.

Three roles with strict data isolation: Admin (full access), Driver (own assignments only — no customer names, deal values, or other driver data), Customer (own orders only).

Route planning review screen: 7 orders across 5 drivers and 4 zones, stops sequenced per driver with time windows and temperature class, reassigned automatically after a driver no-show
Live GPS tracking map showing driver routes and positions, with a panel listing each driver as on route, at stop, or idle, plus stops completed and ETA
Driver mobile app showing today’s confirmed status, two deliveries with estimated duration, a freezer-box loading checklist, sequenced stops with time windows, and a start route button
Customer portal order history with a detail panel showing delivery address, temperature class, assigned driver, a confirmed-to-delivered timeline, proof of delivery photo, and a shareable tracking link

The outcome

One dashboard replaces WhatsApp groups, Google Maps, and the vendor GPS dashboard. Route optimization replaces daily manual address plotting. Automated check-in with standby rotation replaces ad-hoc phone calls.

POD photos are stored per order, accessible by admin and customer — no more scrolling WhatsApp. The customer portal enables self-service tracking and order creation. API readiness enables automated order flow from client systems, opening the door to enterprise B2B accounts that require system integration.

The platform is designed to expand beyond Jakarta — the route optimization algorithm and multi-driver architecture work for any city.

← All projects

Tell us which one is yours.

One short call at a time that suits you, or forward this to whoever runs the operation with you.