How to automate delivery status updates to customers

Why manual status replies cost money

Delivery enquiries consume support time, but the true cost depends on your team’s wages, overhead, contact channel and the time spent finding the right order and checking the carrier. Gartner’s 2024 customer service benchmark reports a median cost of $13.50 per assisted contact and $1.84 for self-service. These are broad service benchmarks, not a forecast for your delivery enquiries or a guarantee that automation will save the difference. Use them as context, then calculate your own cost from the time spent per enquiry and your fully loaded labour cost.

The less obvious cost is inconsistency. One person may copy an old scan, another may promise a delivery date the carrier no longer supports, and a third may miss a customer whose parcel is held for an address issue. Those errors can create more messages and make it harder to resolve the original problem. Before automating, count delivery-status contacts and record how often the team has to correct or escalate an answer.

Manual updates compared with automated updates

How to automate delivery status updates

1. Choose the authoritative shipment record

Decide which system is the source of truth for order ID, customer contact, carrier, tracking code and fulfilment status. It may be an ERP, an order-management system, a shipping platform or a carefully controlled spreadsheet. Do not treat an email thread or a scanned label as the permanent record.

For a spreadsheet-based process, Google Sheets API can read and write cell values. That is useful for a modest, structured workflow, but it does not make a sheet a reliable database by itself. Restrict who can edit key fields, validate tracking codes and keep a record of when each value was last confirmed.

2. Connect tracking events

Use the carrier’s own tracking API when it supports your carriers and shipment mix. Another option is a multi-carrier service such as EasyPost. EasyPost’s Tracker records tracking information and can send updates to a configured webhook; its documentation also notes that data availability varies by carrier. Confirm support and access requirements for the carriers you use before choosing an integration.

A webhook is a message sent by one system to another when an event occurs. Your integration receives the event, checks its authenticity, associates it with the correct order and stores the update. Build the receiver to tolerate retries and duplicate events. EasyPost says webhook events may be retried if delivery fails, and its Events documentation recommends an idempotent handler so an event is not processed twice.

3. Standardise status before writing customer messages

Carrier wording differs. Create a small mapping between carrier events and the language you will use, such as “in transit”, “out for delivery”, “delivered” and “delivery issue”. Do not present every carrier scan as a promise. In particular, distinguish a carrier-provided estimated date from a confirmed delivery appointment.

Use fixed rules for deciding whether an event deserves a message. A label-created scan may not mean the parcel has been collected. A repeated facility scan may not be useful to the customer. Send only updates that are meaningful, and prevent duplicate notifications for the same shipment status.

4. Connect the customer’s channel

For email, connect the order system or workflow to your existing email service, using an approved message template and the customer’s recorded address. For WhatsApp, use the WhatsApp Business Platform Cloud API or an integration provider that supports it. Meta’s developer materials describe webhooks for receiving platform events; your outbound workflow must also follow the platform’s current requirements for business messaging and templates. Confirm those requirements during setup rather than assuming an ordinary WhatsApp Business app can run the same automated workflow.

Keep messages brief: identify the order using a safe reference, state the carrier’s latest confirmed status, include the tracking link if available, and explain how to contact support. Avoid putting unnecessary personal or payment information in a notification.

5. Add human review for exceptions

Automatically send routine updates only when the shipment match is clear and the tracking record is recent enough for your policy. Create a review task instead if the tracking code is missing, two systems disagree, a parcel is marked delivered but the customer reports otherwise, or there has been no new scan for a period you define with your carriers and operations team.

The reviewer should see the order record, carrier event history, last event time and the reason the workflow paused. That makes the hand-off actionable. Do not use an LLM to invent a shipment status or decide which conflicting record is correct. If you use an LLM at all, limit it to rewriting an already verified status into clear wording, with the status and allowed facts supplied as structured input.

6. Test, monitor and expand

Test normal movement, delivery, failed delivery, returned parcels, duplicate webhook events, missing tracking codes and delayed scans. Compare a sample of sent messages with the carrier record. Track repeat delivery enquiries, incorrect notifications, messages held for review and time spent handling exceptions. Expand to additional carriers or channels only after the first workflow behaves predictably.

What can break, and how to prevent it

• Wrong order match: Match on a stable order identifier plus carrier and tracking code, not a customer name alone.
• Stale scans: Record the event timestamp and the time your system received it. If the event is older than your review threshold, do not describe it as current without checking.
• Conflicting records: Set a source-of-truth rule and flag disagreements rather than choosing the newest-looking status automatically.
• Duplicate or missed events: Make event handling repeat-safe, log processing outcomes and provide a way to retry failed jobs.
• Carrier-specific gaps: Check what each carrier exposes and how often it updates. A tracking API cannot create scans the carrier has not supplied.
• Incorrect channel or consent: Verify customer contact details and applicable messaging rules for the markets where you operate.
• Unhelpful message volume: Send only meaningful status changes and provide a clear path to a person when the customer needs help.

When not to automate

Automation may not be worthwhile if shipment volume is low, each parcel needs a different explanation, tracking records are routinely incomplete, or a person must investigate nearly every status. It is also a poor fit if the business cannot reliably link orders to tracking codes or has no owner for exception queues. In those cases, first fix the shipment data and standard operating process. A simple shared queue and reusable reply templates may be enough.

What it typically takes

There is no dependable universal implementation time. A single carrier, one customer channel and clean order records take less coordination than multiple carriers, ERPs, marketplaces and regional messaging rules. The work usually includes mapping records, connecting the tracking feed, writing status and exception rules, configuring approved messages, testing failures and training the person who reviews held cases. Start with one end-to-end workflow and agree on how stale data is defined before estimating a wider rollout.