Run a courier or last-mile delivery business in Sydney, Melbourne or Brisbane and two questions eat more staff time than anything else: "where is my parcel" and "prove it was actually delivered". Neither question is hard to answer in principle. Every order sits in a TMS, every stop has a GPS ping, every drop-off has a photo or a signature. The problem is that answering well means pulling from three or four systems, formatting it into something a customer or an insurer will accept, and doing that dozens or hundreds of times a day. Claude is well suited to exactly this kind of repetitive, evidence-based writing task, and a growing number of Australian delivery operators are wiring it into their dispatch and support desks. Most delivery businesses already hold everything needed to answer both questions properly. What is usually missing is a fast, reliable way to pull it together and say it in plain English, at the volume a busy dispatch desk actually needs.
What the dispatch desk actually deals with each day
Most of the inbound volume to a courier's support line is not complicated. It is the same handful of questions, asked by different customers, at different times of day, about different parcels. A dispatch coordinator or customer service rep spends their morning triaging these before they can get to anything that actually needs judgement, like rerouting a vehicle around a closed road or negotiating a delivery window with a difficult building manager.
Where is my parcel right now, and what time will it arrive today
Can this delivery be redirected to a different address or a parcel locker
The tracking page says delivered but the customer says nothing arrived
Can I get formal proof of delivery for an insurance claim
Why was a delivery attempt marked as a failed drop when someone was home
A Claude-based front line can read the incoming email, SMS or webchat message, match it against the order in the TMS, and draft a reply that answers the actual question with the actual data attached. Genuinely ambiguous cases, like a customer disputing a driver's account of events, still go to a human. The routine ones do not need to.
Proof-of-delivery disputes are where the real money leaks
Dispatch queries are annoying but cheap. Proof-of-delivery disputes are the expensive ones. When a customer or a retailer disputes a delivery, someone has to locate the driver's photo, the GPS timestamp, the signature capture and the delivery notes, then write a response that will actually hold up against a chargeback or an insurance claim. For a mid-sized Australian courier running a few hundred deliveries a day, we have seen unresolved or poorly evidenced disputes add up to roughly $45,000 a year once you count written-off claims, refunded freight and the staff hours spent chasing records across separate systems.
Claude can be given read access to the delivery record, the photo metadata and the driver's app notes, and asked to produce a structured dispute response: what time the parcel was scanned as delivered, the GPS coordinates at that timestamp, a description of the photo evidence, and the relevant clause from the customer's terms of service. That response used to take a claims officer twenty minutes to assemble by hand. It now takes under a minute to draft, with the officer reviewing and sending rather than building it from scratch each time.
What a Claude-based setup looks like inside a courier business
The builds we have delivered for delivery and freight clients tend to follow the same shape. Claude sits between the inbound channel (email, SMS, a webchat widget) and the TMS or delivery-management platform, connected through the vendor's existing API rather than a screen-scrape. Incoming messages are classified, matched to an order, and drafted into a reply. Anything outside a defined confidence threshold, such as a driver safety complaint or a claim above a set dollar value, is flagged straight to a human rather than answered automatically. Most builds start with one channel, usually email or webchat, running in shadow mode alongside the existing team for a couple of weeks before anything goes live unsupervised. That gives the operator a clear before-and-after view of accuracy and response time before trusting it with customer-facing traffic.
Getting this right for an Australian operator also means building in the Privacy Act obligations around what customer and driver data the model is allowed to see and retain, and keeping a clear audit trail of every drafted response for six months or longer in case a dispute escalates. None of that is exotic. It is standard practice for any system handling customer data, and it is worth setting up properly before the first response ever goes out. If dispatch queries and proof-of-delivery disputes are quietly costing your business time each week, we would be glad to walk through what a fit-for-purpose build looks like for your operation: [book a short call](/contact).
