The Problem: A Multi-Site Logistics Operation Running on Phone Calls, Spreadsheets, and Paper Dockets#
There is a specific operational ceiling that Australian logistics businesses hit when they grow past a single depot. At one site, a coordinator can know the status of most consignments from memory and direct observation. At two or three depots — or when freight is moving interstate across multiple carriers and multiple handling points — that personal knowledge stops being sufficient and no system steps in to replace it. Status updates start travelling by phone. Receipts get created manually. Reports get assembled from spreadsheet exports at the end of the shift. The coordinator's day fills up with information-gathering that should be automatic, and the information they eventually gather is already hours old.
This is the operational situation we walked into at the start of this engagement. An Australian logistics operator managing goods movements across multiple depots and interstate freight corridors was coordinating daily operations through a combination of phone calls to carriers for status updates, manual receipt creation for every inbound consignment, spreadsheet-based shift report assembly, and email chains between depot managers for inter-site coordination. Each depot had visibility of its own activity. Nobody had visibility of the network. Client inquiries about their freight status went to a coordinator who had to check multiple systems and make a phone call before they could answer.
The cost of this operational model was measurable and daily: hours of coordinator time spent on information gathering rather than operational management, a 24-hour lag between delivery completion and proof-of-delivery processing that delayed billing cycles, and a management team making network-wide decisions from a picture that was always at least one shift old.
The mandate was to replace this entirely with a purpose-built multi-site logistics intelligence platform — live goods tracking connected to carrier APIs and barcode scan events, automatic receipt generation at point of inbound scan, client-facing status visibility without coordinator involvement, and automated operational reporting across all depots.
Existing Environment#
The operation ran across multiple Australian depots handling inbound freight from interstate and international origins, cross-dock movements between facilities, and outbound delivery across metro and regional routes. Multiple carriers were in use across different freight types and lanes — each with their own tracking portals, none of which fed into a shared operational view. Inbound receiving was managed through manual paper receipts. Delivery confirmations were collected on paper dockets returned by drivers at end of shift. Operational reporting was manually compiled from TMS and WMS exports supplemented by supervisor inputs.
No existing unified tracking or reporting platform was in place. The new system needed to connect to multiple carrier APIs, process barcode scan events from depot receiving operations, generate receipts automatically, provide a client-facing visibility layer, and produce automated operational reports — all without requiring changes to existing carrier relationships or depot workflows beyond the replacement of paper processes with digital equivalents.
What We Built#
The platform was designed as a complete multi-site logistics operational intelligence system — built on React, Node.js, and PostgreSQL, deployed on AWS, covering every workflow that had previously run on manual coordination.
Consignment Management and Movement Tracking
The core of the system was a consignment management engine where every goods movement was tracked from origin booking through to final delivery confirmation. Each consignment record carried originating depot, destination, carrier assignment, service type, current status, full movement history, exception log, document attachments, and linked receipt and POD records. Status updates flowed into the consignment record from two sources: carrier API polling (automated status fetches from carrier systems on a defined schedule) and barcode scan events (real-time status updates captured at each depot handling point). The result was a consignment record that reflected the actual current location and status of goods at all times — not the last manual update someone had time to enter.
Carrier API Integration and Status Fetching
The carrier integration layer connected to each carrier's tracking API or data feed — automatically polling for status updates, scan events, and estimated delivery window changes across all active consignments. When a carrier system recorded a scan — depot receipt, linehaul departure, destination depot arrival, out for delivery, delivered — that event was fetched automatically and written to the consignment record without any coordinator action. Carriers without live API access were handled through structured data exchange — file-based status feeds on a defined polling cycle. The system normalised status data across all carriers into a consistent event taxonomy, so a consignment moving across multiple carriers in sequence showed a unified status history rather than separate carrier-specific records.
Automatic Receipt Generation
Every inbound consignment reaching a depot triggered an automatic receipt generation process at the point of barcode scan. The receipt engine pulled consignment details from the database, applied the relevant receipt template (configurable per client and per freight type), captured the scan timestamp, receiving depot, and receiving operator identity, and generated a structured PDF receipt within seconds of the scan event. Receipts were stored against the consignment record, emailed to the configured recipient list automatically, and available for immediate download from the consignment view. Exception notations — damaged goods, short delivery, temperature exceedance — were captured at the scan point and reflected in the receipt automatically. The manual receipt creation process — previously 15 to 20 minutes per consignment — was eliminated entirely.
Proof of Delivery and Digital Confirmation
Delivery drivers confirmed completed deliveries through a mobile interface at point of drop — capturing recipient confirmation, delivery timestamp, condition notation, and photo evidence where required. The POD record updated the consignment status to delivered, generated an automated delivery confirmation notification to the client, and triggered the billing workflow update in the financial system. The 24-hour lag between physical delivery and POD processing — previously caused by paper dockets being returned to depot at end of shift — was eliminated. Billing triggers fired the same day as delivery.
Multi-Depot Operational Dashboard
The multi-depot dashboard gave operations management a single live view of the entire network — inbound consignment volumes by depot, outbound dispatch completion rates, carrier performance by lane, exception counts by type and location, and active consignment status distribution across all sites simultaneously. Each depot retained its own localised view for site-level management. The consolidated network view was accessible to operations leadership without requiring login to separate systems at each depot. KPI cards updated in real time from scan events and carrier status feeds throughout the operational day.
Automated Shift Reporting
At the end of every shift, the system compiled an automated shift performance report for each depot — consignment volumes received, processed, and dispatched; exception counts and resolution status; carrier performance summary for the shift; and comparison against the previous shift and the weekly average. Reports generated automatically at shift end without any coordinator or supervisor involvement, distributed to the configured management distribution list, and stored against the depot's historical report archive. The two-to-four-hour manual report compilation process was eliminated across every depot simultaneously.
Client-Facing Consignment Tracking Portal
The client portal gave freight clients direct, real-time visibility of their consignments without contacting the operations team. Clients logged into their portal view, saw their active consignments, checked current status and movement history, downloaded receipts and POD documents, and received automated notifications at key status milestones — depot receipt, linehaul departure, out for delivery, delivered. The volume of inbound client status inquiry calls and emails — previously consuming significant coordinator time daily — reduced substantially within the first weeks of the portal going live, as clients accessed the same information directly that coordinators had previously been required to retrieve and relay.
Exception Management and Alert System
The exception management system monitored consignment progress against expected timelines — flagging consignments that had missed a scheduled scan event, hadn't progressed from an intermediate status within the expected window, or had carrier-reported exceptions recorded against them. Alerts routed to the relevant depot coordinator or supervisor based on consignment type and exception severity. Exception resolution was tracked within the system — coordinators logged the action taken and the resolution outcome against each exception record, creating a structured exception history rather than an unrecorded phone conversation.
Roles and Access Management
Role-based access controlled every feature in the platform. Depot receiving staff accessed inbound scan processing and receipt generation within their depot. Dispatch coordinators accessed consignment management, carrier status views, and exception queues across their assigned depots. Depot managers accessed full site-level reporting, exception oversight, and consignment management. Operations leadership accessed the consolidated multi-depot dashboard and network-wide reporting. Client portal users accessed only their own consignments. Administrators managed carrier integrations, receipt templates, alert thresholds, and user accounts.
Operational Problems This System Solved#
Status unknown between scan events — The carrier API polling and barcode scan event processing system ensured consignment status reflected the latest available information at all times, updated automatically rather than dependent on a coordinator making a phone call or manually checking a carrier portal.
Receipt creation consuming receiving team time — Automatic receipt generation at point of scan eliminated 15 to 20 minutes of manual receipt creation per consignment across every depot. For high-volume receiving operations, this translated to hours of staff time returned to operational work every shift.
Billing delayed by paper POD lag — Digital delivery confirmation at point of drop updated the billing trigger the same day as delivery, eliminating the 24-hour lag that occurred when paper dockets were returned to depot at end of shift.
No consolidated network view for management — The multi-depot dashboard gave operations leadership a real-time picture of the entire network that had not previously existed in any form. Decisions about resource allocation, carrier performance, and inter-depot coordination were made from current data for the first time.
Client inquiries consuming coordinator time — The client portal eliminated the coordinator-as-intermediary model for status enquiries. Clients accessed their freight status directly, reducing the volume of inbound calls and emails that had previously interrupted coordinator workflow throughout every shift.
Shift reports consuming end-of-shift time — Automated shift reports generated from live operational data eliminated the manual compilation process across all depots simultaneously, returning two to four hours of coordinator and supervisor time to actual operational management every shift.
Exceptions discovered too late to act on — The exception alerting system surfaced developing exceptions — missed scan events, timeline breaches, carrier-reported issues — during the operational window rather than in an end-of-shift report, giving coordinators time to act while recovery was still possible.
Lessons Learned#
Carrier API diversity is the hardest integration challenge, not the most obvious one. The assumption at the outset was that carrier integration would be straightforward — carriers have tracking APIs, we connect to them. The reality was that every carrier had a different API structure, different authentication model, different event taxonomy, and different data reliability characteristics. Building a normalisation layer that translated disparate carrier event data into a consistent internal status model was the most technically demanding part of the engagement — and the most valuable, because without it the consignment view would have been a different experience per carrier rather than a unified operational picture.
Receipt automation value compounds with volume. At low consignment volumes, the time saving from automatic receipt generation is incremental. At the consignment volumes this operation processed daily, it was transformational — the receiving team's capacity to handle inbound volume increased significantly simply because the documentation overhead per consignment was removed.
Client portals change the operational dynamic faster than expected. We anticipated a gradual adoption curve for the client tracking portal. The actual adoption was immediate — clients who had previously called coordinators for status switched to the portal within the first week because the portal gave them better information faster than a coordinator call did. The operational impact on coordinator workload was visible within days of go-live.
Automated reporting only becomes trusted when the underlying data is trusted. The first week of parallel operation — running automated reports alongside manually compiled reports — was the most important week of the engagement. When the automated report matched the manual report on day three, the operations team's confidence in the data shifted completely. The manual process was retired not because we said it should be, but because the team verified the automated version was more accurate.
Integrations#
Carrier API integrations were built as modular connectors — each carrier had its own integration module normalising their specific API response format into the platform's internal event schema. This architecture allowed new carrier integrations to be added without changes to the core platform. Where carriers provided file-based tracking exports rather than live APIs, scheduled ingestion jobs processed the files on defined polling cycles. The billing system integration was built as a webhook trigger — delivery confirmation events fired a structured notification to the client's financial system, updating the relevant invoice record without manual re-entry. No changes were required to existing carrier contracts or carrier-side system configuration.