Replacing Excel + WhatsApp with a Real Courier Management System

The client & the problem

The client is a two-decade-old courier network operating across western India with 14 hubs, a 60-vehicle line-haul fleet, and a 400-strong corporate client list. Business was healthy. The back-office was not.

Every pickup was written in a booking book, transcribed to Excel at end of shift, manifested by reading out AWBs on a WhatsApp group, billed from a separate Excel sheet once a month, and tracked by calling the hub manager on his personal phone. The founder's son, who had taken over operations, knew the model wouldn't survive another doubling of volume. His specific pain points:

• Data entered 3–4 times: once at pickup, once at hub-in, once at hub-out, once at billing. Each transcription introduced errors.
• Billing errors costing money: ~8 billing disputes per month, most traced to AWB/weight/service mismatches between Excel sheets.
• No visibility between hubs: a shipment "lost" in transit often just meant nobody had updated the WhatsApp group.
• Zero self-service for corporate clients: every "where is my shipment?" call interrupted a supervisor's work.
• End-of-day closing took 2+ hours: supervisors reconciled pickups vs manifests vs delivered vs COD collected, manually.

The solution: model the entire pickup-to-POD workflow, then ship it

The fundamental mistake small-courier software makes is treating this as "a form to enter an AWB." It isn't. It's a chain of physical hand-offs that must be reflected faithfully in software, with each hand-off recorded by the person actually doing it, on the device they have in their hand.

We spent three weeks embedded with the ops team (head office, one city hub, one line-haul route, one delivery beat) before writing a line of code. What came out was a five-stage workflow that the CMS models end to end:

Modules we built

• Booking: corporate client portal (web) + field booking on Android + walk-in counter screen. Every booking generates a printable AWB and feeds the pickup queue in real time.
• Pickup management: beat-wise pickup lists, pickup boy Android app with barcode scan + photo capture + signature, auto cross-check against booked volume.
• Hub operations: in-scan, sort-by-destination, out-scan, hand-over to line-haul. Barcode-first — the hub floor never has to type an AWB.
• Manifest & line-haul: digital manifest with piece-count + weight checks, vehicle + driver + seal record, GPS trace of line-haul runs.
• Delivery: beat planning, delivery boy app with POD capture (signature, photo, GPS stamp), re-attempt flow, COD collection.
• Billing: auto-calculated invoices per contract, weight dispute workflow, COD remittance, monthly statements — zero manual Excel.
• Tracking & MIS: corporate tracking portal (white-labelled), public tracking, head-office dashboards for SLA breach, pendency, revenue, hub utilisation.

Tech stack & why

This is a high-volume, low-margin, high-reliability system. It needed to be cheap to operate, easy to host on Indian infrastructure, and simple enough that a future in-house team could maintain it. That pointed firmly at a battle-tested LAMP-style stack over anything trendy:

Laravel for the web CMS: fast to build, huge ecosystem, and — critical for this client — every second PHP developer in India already knows it. When the client eventually hires an in-house dev, onboarding will take a week, not a quarter.

Kotlin Android for field apps: the devices in the field are rugged Android scanners from Zebra and Honeywell. Native Kotlin means first-class support for the scanner SDKs, which are absolutely not a Flutter-friendly world. iOS was explicitly not required.

MySQL over anything exotic: 5M+ shipment rows, 20M+ scan events, heavy read load on tracking queries. Well-indexed MySQL handles this effortlessly and is operationally boring — which for a logistics back-office is a compliment.

Redis for hot tracking: the corporate tracking portal sees the same AWB looked up dozens of times. Redis caches the "latest known status" and cuts MySQL load to a trickle.

The hardest non-technical problem we solved

Rollout. The software was the easy part. Moving 35 people off a 20-year-old Excel workflow onto a new platform — without grinding a working business to a halt — was the real work.

We learned this the hard way on the first hub. A big-bang switchover caused two days of chaos: new UI, unfamiliar scanner flow, a couple of genuine bugs, and a supervisor who'd been doing manifests on Excel since 2005 deciding on day two that "the old way was better." Volume that hub handled halved for 48 hours.

For the remaining 13 hubs we switched to a dual-running rollout:

• Week 1: new system running in shadow mode — real data captured, but Excel is still the source of truth.
• Week 2: new system becomes the source of truth for bookings and pickups; hub/manifest still on Excel.
• Week 3: hub/manifest flips to CMS; Excel becomes read-only reference.
• Week 4: Excel sunset.

A dedicated field trainer (from our side) was physically present for the first week in each hub. The next 13 rollouts had zero volume disruption.

Results

What we would do differently

Skip the first-hub big-bang entirely. In hindsight, everyone on the project agreed the 4-week dual-run cadence is just better for a 20-year-old operation; we should have used it from day one. We would also invest more upfront in a proper hub-supervisor training video library — written SOPs got read twice and ignored; short videos on a shared tablet actually stuck.