Why a National Pharmacy Fleet Rebuilt Its Transportation Software Stack, And Found the Real Cost Was Never the Routes

Forty vehicles. Four software tools. Six weeks of internal audit. And the answer nobody on the operations team had expected.

The fleet belonged to SuperPharmacy, a national pharmacy chain running prescription and retail deliveries across metro and regional Australia. They came in convinced the problem was route mileage. They left the audit with a different diagnosis entirely. The cost wasn't on the road. It was at the door.

This is the story of how that audit reshaped their transportation software stack, what the data showed six months later, and the questions every operator should be asking before they sign their next dispatch contract.

The moment a 40-vehicle pharmacy fleet realised their transportation software was solving the wrong problem

The SuperPharmacy team had been running a stack of four tools. A routing application for daily planning. A separate GPS tracker for vehicle location. A third-party proof-of-delivery app on driver phones. And a messaging tool to coordinate dispatch in real time.

Each tool did its job. Sort of.

What none of them did was talk to each other. A failed delivery in the POD app didn't trigger a re-route. A delay flagged by GPS didn't update the customer ETA. Dispatch was a person watching four browser tabs and typing into a fifth.

The audit started because the CFO wanted to know why fuel was creeping up faster than stop volume. The team expected to find inefficient routing. Instead they found something subtler.

Drivers were spending too long at each stop. Not because the routes were wrong. Because every exception, every wrong address, every locked door, every customer who needed a callback, was being handled manually. The route stayed efficient on paper while the day collapsed in real time.

That was the pivot moment. Routes weren't the problem. The transportation software stack was solving for the wrong cost.

What transportation software actually has to do in 2026 (beyond route lines on a map)

Drawing a clean route on a map is table stakes. Has been for a decade.

What modern transportation software has to do is harder. It has to handle the moment the route breaks.

A driver arrives at a locked warehouse. A customer changes the delivery window. A pickup runs 22 minutes late and three downstream stops cascade. Roadworks close a corridor that the optimiser was relying on. The platform has to absorb all of that and resequence without anyone manually intervening.

It also has to surface what's happening to everyone who needs to know. Dispatch sees the exception. The customer gets an updated ETA. The driver sees the new sequence on their phone. The back office sees the proof-of-delivery photo and signature land in real time.

According to McKinsey's analysis of last-mile delivery, last-mile costs account for roughly 53% of total shipping spend, with failed deliveries and dwell time identified as the primary hidden drivers.

That's the shift. Transportation software in 2026 is less about planning the day and more about reacting to it.

The hidden cost layer: dwell, exceptions, and the proof-of-delivery gap

SuperPharmacy's audit broke their cost down by category. Fuel was visible. Driver wages were visible. Vehicle maintenance was visible.

The invisible layer was the one bleeding budget.

Dwell time at stops. Every additional minute a driver spends parked at a pharmacy adds compounding cost across 40 vehicles. Multiply across a five-day week and the number stops being small.

Exception handling was worse. A failed delivery, in their old workflow, triggered a phone call to dispatch, a manual decision about re-routing, a callback to the customer, and often a return-to-depot trip. Each one cost real money. None of it appeared in the routing software's report.

Then there was the proof-of-delivery gap. The driver captured a signature on a third-party app. The data sat in that app's cloud. Customer service didn't have it when the pharmacy called asking where their script was. So they took the call, escalated to ops, ops checked the POD app, called back. Forty-five minutes for a question the customer should have answered themselves with a tracking link.

This is the layer generic buyer guides miss. They tally feature lists. They don't ask where your money is actually leaking.

How a single transportation software platform replaced four disconnected tools

The team rebuilt around one principle. The route, the tracking, the driver app, and the proof-of-delivery had to live in the same database. Not integrated via API afterthought. The same database.

That meant when a driver marked a delivery as failed, the next stop in the sequence updated automatically. When a customer's ETA shifted by more than 15 minutes, the SMS notification fired without anyone clicking a button. When dispatch needed to see why a vehicle had been stationary for too long, they saw it on the same screen they used to plan the day.

Four tools became one. Four logins became one. Four datasets became one.

The integration work that mattered wasn't between the four old tools. It was between the new platform and the rest of the business. Route optimisation needed to pull orders from the pharmacy's existing WMS. Proof of delivery needed to push back into the ERP for invoicing. Customer notifications needed to reflect the brand, not a generic dispatch template.

Gartner's transportation management research notes that organisations consolidating fragmented transportation tooling into a single platform typically report meaningful reductions in operating cost within the first year.

The capabilities that moved the needle: live tracking, dispatch logic, driver app, POD

Not every feature mattered equally. Four capabilities did most of the work.

Live tracking changed the customer experience first. The pharmacy started sending a tracking link with every dispatch. Customer calls asking "where is my order" dropped sharply because the answer was already in the customer's inbox. The real-time tracking feed also gave dispatch a single screen showing every vehicle's status without polling drivers.

Dispatch logic was the one nobody had expected to value as highly. When a driver marked a stop as failed, the system suggested the next-best action automatically. Reschedule for tomorrow's run. Reassign to a closer driver. Trigger a customer callback. The decision didn't disappear, but the cognitive load on the dispatcher did.

The driver app was the unsung hero. Drivers stopped switching between three apps to do their job. One screen showed the route, the customer details, the photo capture, the signature pad, and the navigation handoff to their preferred map provider.

Proof of delivery closed the loop. Every drop generated a timestamped photo and signature that flowed into the back office instantly. Proof of delivery wasn't just a compliance feature anymore. It was the customer service team's most valuable tool.

What the data showed after 6 months: stops per hour, failed deliveries, customer call volume

Six months in, the operations team had three metrics they hadn't been able to track reliably before.

Stops per hour, calculated against actual dwell rather than planned. Failed delivery rate, broken down by reason code. Customer call volume to the contact centre, correlated against tracking-link opens.

The pattern was consistent across both metro and regional routes. Stops per hour rose because dwell time fell, not because the routes got shorter. Failed deliveries dropped because the customer notification gave them a chance to be home or to reschedule before the truck arrived. Customer calls dropped because the answer to "where is it" was already in the customer's pocket.

None of those metrics had been visible in the old stack. The data existed, scattered across four tools. None of it was correlated.

The BITRE 2024 Australian Infrastructure Statistics Yearbook shows Australian road freight task at roughly 240 billion tonne-kilometres, with last-mile and urban distribution accounting for a rising share. As that share grows, the operators who can measure their own dwell, exception, and notification performance will be the ones absorbing volume profitably.

Where most transportation software implementations stall, and how to avoid it

The common failure mode isn't choosing the wrong platform. It's implementing the right one badly.

The rollouts that stall usually share a few characteristics. The project is owned by IT instead of operations. Drivers are trained in a classroom instead of on a real route. Integrations are scoped late, after the platform is already live. Old tools are kept running in parallel "just in case" and become a permanent shadow stack.

The rollouts that work look different.

Operations owns the project. Drivers are trained on their own routes with their own customers, not on dummy data. Integrations are scoped before contract signature, not after. The cutover from old to new is firm and dated.

SuperPharmacy ran their cutover one depot at a time. Each depot had a two-week parallel period where both stacks ran, then a clean cutover. By the time the last depot migrated, the dispatch team had refined the workflow enough that the final go-live was almost uneventful.

The World Bank Logistics Performance Index notes that top-performing logistics economies show very high adoption of integrated transportation platforms. The pattern is consistent. Consolidation works when it's run as an operational programme, not an IT project.

Choosing transportation software: the questions operators wish they'd asked first

The buying conversation usually starts with feature lists. It should start somewhere else.

The question that matters first is this. Where is my current cost actually hiding, and what data would prove or disprove that hypothesis in 30 days?

If you can't answer that, no platform will help, because you won't know what to measure when it's live.

The second question is about integration. The platform has to talk to your existing WMS or ERP, your accounting system, your e-commerce front end if you have one. Ask for the API documentation before the demo. If the integration story is hand-wavy, the rollout will be hand-wavy.

The third question is about scale. Does the same platform handle a three-driver micro-fleet and a thousand-driver enterprise on the same architecture? Because your fleet next year is not your fleet today. Locate2u's route engine handles the high-density urban routes and the regional long-haul sequences on the same platform, without forcing you to switch products as you grow.

The fourth question is about the actual people. Who answers the phone when something breaks? Are they in your timezone? Do they know your industry? For pharmacy, for cold chain, for building supplies, the answers matter.

The global road freight market is projected to exceed USD 2.8 trillion by 2026, according to Statista, with software-driven dispatch cited as the fastest-growing operational spend category. The platforms that win in that market will be the ones that answer those four questions cleanly.

FAQ: transportation software, integrations, pricing, and rollout

What integrations does Locate2u support?

Locate2u offers a public API alongside native integrations with common e-commerce, accounting, and warehouse systems including Shopify, Xero, and major WMS platforms. Custom integrations into ERPs and proprietary order-management systems are handled through the API and supported by the implementation team.

What does Locate2u cost?

Pricing starts from US$25 per user per month, with tiered plans for small fleets through to enterprise operations. Full pricing breakdowns and feature inclusions are on the pricing page.

How long does a typical rollout take?

A small-to-mid-size fleet implementation typically runs over a few weeks, depending on integration scope and the number of depots involved. Multi-depot enterprise rollouts are usually phased depot by depot to keep operations stable during cutover.

What makes purpose-built transportation software different from a fleet tracker?

A fleet tracker shows you where the vehicle is. Transportation software ties location to orders, routes, proof of delivery, customer notifications, and the back office systems that depend on all of it. The difference is operational, not cosmetic. One tells you what happened. The other helps you change what happens next.

Is Locate2u suitable for pharmaceutical and healthcare delivery?

Yes. The pharmaceutical solution covers prescription delivery, cold-chain workflows, signature and ID capture for controlled goods, and the auditability that pharmacy operators need for compliance.

Can the platform handle both metro and regional routes?

Yes. The route engine handles high-density urban sequences and long-haul regional routes on the same platform, with dispatch logic that adjusts to both contexts.

If the audit conversation in this article sounds familiar, the next step isn't a feature list. It's a 30-minute look at where your own cost is hiding. Request access and we'll walk you through the data points your current stack probably isn't showing you, and what a consolidated platform would surface in the first month. No script, no slide deck, just the questions worth asking.