Shipping Confirmation Email Templates for Tracking, Delays, and Split Shipments
A shipping template system should map to fulfillment events, not merely decorate a single “your order is on the way” email. The same order can move through multiple shipments and exceptions.
State-to-template map
| State | Subject | Primary action |
|---|---|---|
| Shipped | Your order has shipped | Track shipment |
| Label created | Your shipment is being prepared | Wait for carrier acceptance |
| Delayed | An update about your shipment | Review latest estimate |
| Split shipment | Part of your order has shipped | Track each package |
| Out for delivery | Your package is out for delivery | Prepare to receive |
| Delivered | Your package was delivered | Review delivery details |
| Returned | Your package is returning to sender | Contact support or confirm refund |
Do not call a label-created event shipped if the carrier has not accepted the package.
Base shipped template
Subject: Your order {{order_number}} has shipped
Hello {{customer_name}},
{{item_summary}} shipped with {{carrier_name}}. Estimated delivery: {{delivery_estimate}}.
[Track shipment]
If tracking does not update by {{stalled_date}}, contact {{support_email}}.
Delay variant
Subject: An update about order {{order_number}}
Your shipment is delayed. The latest carrier update is {{current_status}}. We now expect delivery {{updated_estimate}} or will send another update by {{next_update_date}}.
[View tracking]
Do not replace the estimate with a guaranteed date unless the carrier gives one.
Split-shipment variant
Subject: Part of your order has shipped
The following items are on the way:
{{shipped_items}}
Track them here: {{shipped_tracking_url}}
The remaining items are expected {{remaining_estimate}}. We will send another message when they ship.
Returned-shipment variant
Subject: Your shipment is returning to us
The carrier could not complete delivery and is returning shipment {{shipment_id}}. We will {{actual_next_step}}. Contact {{support_email}} if the delivery address needs review.
Data and suppression
Render from shipment records with immutable item membership. Use shipment ID, status, and event version for idempotency. Suppress or replace messages when:
- the order is canceled;
- the shipment is delivered or returned;
- an address correction owns the workflow;
- a replacement shipment is created;
- a customer has an active support case for the same exception.
QA checklist
- Each item appears in only the shipment where it was fulfilled.
- Carrier status is not stale or out of order.
- Tracking links are correct and safe.
- Delivery estimates are qualified.
- Duplicate webhooks do not duplicate messages.
- The email remains understandable without decorative content.
Use the shipping confirmation examples for shorter copy and the split shipment template for one state in detail.
Data contract and event ordering
Treat each shipment as an immutable record with item IDs, carrier, tracking, destination, and status timestamps. Carrier webhooks can arrive late or out of order, so the workflow should ignore an older event after a newer terminal state unless the carrier sends an explicit correction.
Before rendering, check:
- the order is not canceled;
- the shipment belongs to the recipient;
- tracking is valid for the stated carrier;
- item membership has not changed;
- the estimate is not older than the last carrier update.
Support handoff
Every exception variant should tell support what the customer will see in the portal and what evidence is available. A good template reduces WISMO tickets; a vague template merely moves the question from the inbox to the help desk.
Define the source-of-truth boundary
Fulfillment owns whether a package is handed to a carrier; the carrier owns scans after handoff; the order system owns what was purchased; support owns manual exceptions. Put that ownership in the template contract so a copy edit cannot accidentally turn an estimate into a promise.
Use a versioned status mapping and test it against real provider payloads. “Label created,” “accepted,” “in transit,” “attempted,” “delivered,” and “returned” should not collapse into one state just because they share a tracking number. When a provider adds a new status, route it to review rather than guessing the nearest customer-facing phrase.
Rendering and accessibility
Put the operational action near the top, show item names in text, and keep tracking links next to the shipment they describe. Use alt text for product images, a visible plain-text URL or support path in the text part, and a mobile layout that does not require horizontal scrolling. Avoid placing the only delivery estimate inside an image.
Test long item names, multiple packages, right-to-left addresses, dark mode, blocked images, a missing estimate, carrier tracking downtime, and a replacement shipment. Track delivery-related contacts, invalid tracking links, duplicate sends, and the rate at which customers reach the correct self-service path.