Published
ShipStation sends your customers up to four emails about a shipment, configured per store, carrying your logo and colours. It also coordinates with your selling channel so the customer does not get the same message twice, lets you delay the first one until it is actually true, and lets an automation rule choose which template a given order gets.
That is a decent notification stack and most accounts leave it on the defaults. Below is what each email is, what to set, and the one status ShipStation tracks without emailing about it.
Set per store, under the store’s details on the Emails tab.
Shipment Confirmation — the order is being prepared. Estimated Delivery Date — the shipment has hit the mailstream and has an estimated date. Out for Delivery — it is on the van. Delivered — it arrived.
They are on by default, because ShipStation assumes you may already be using your selling channel’s notifications. When ShipStation sends a shipment confirmation it flags that in the marketplace notification so the channel skips sending its own, which is the mechanism that stops customers getting two emails. If you have ever wondered why enabling these did not duplicate everything, that is why.
An order needs a valid email address for any of it to work, which is worth checking at the store connection rather than assuming.
Four actions in the criteria and actions reference touch what the customer receives, and they are worth knowing because they let notifications vary by order rather than only by store:
The two template actions are the useful ones. A wholesale order and a consumer order can carry different copy without running two stores, and a preorder can get a template that explains the wait. There is also a general Send an email… action, though ShipStation notes it fires immediately at import and is for internal alerting rather than shipment updates — it points you at the template actions for anything tied to label creation.
This is the constraint that shapes everything else. ShipStation states it plainly:
Settings to delay customer notifications only apply to the Shipment Confirmation Email. Currently you cannot delay any delivery notifications. Delivery notifications are triggered only when the carrier alerts ShipStation that the package has been delivered.
That is reasonable — there is nothing to schedule about an event the carrier reports — and it means the only lever you have is on the first email.
By default the shipment confirmation goes out when you create the label. The alternatives, from the same settings page:
You can select several and the first condition met wins.
The mail stream option is the honest one and it has a caveat ShipStation states directly: for carriers that submit shipments electronically, it can fire before the carrier physically has the parcel. It is a data event. It is still much closer to the truth than label creation, particularly if you print labels ahead of the day they ship.
There is also an Additional Settings field for a BCC address, which is the cheapest way to find out what your customers are actually receiving.
ShipStation knows when a shipment goes into exception. Delivery Exceptions is one of the tracking statuses in the Shipments grid, it has its own section in the sidebar, and it has its own default date filter — ShipStation shows In Transit, Delivered and Delivery Exceptions shipments with a ship date in the last 30 days, against 14 days for recent shipments generally. It is on the Shipment Tracking Dashboard.
There is no notification attached to it.
So the state of the world is: ShipStation has the information, has built a filter for it, has built a dashboard metric for it, and does not tell you or your customer when it changes. The last thing that customer heard from you was that their order was on its way.
This is the one real gap in the customer-facing side of the product, and it is unlikely to be an oversight. An automatic exception email is genuinely hard to get right: carrier exception codes cover everything from an incorrect address to a weather delay to a missed delivery attempt, the right message differs completely between them, and a generic “there is a problem with your delivery” email generates more contacts than it prevents. Surfacing the status and leaving the judgement to you is a defensible call.
The mechanism ShipStation gives you is a filter, so the answer is a routine rather than a feature.
Check Delivery Exceptions daily. It is a saved view. Someone opens it in the morning, looks at what is new, and decides per shipment whether it is worth contacting the customer. On most order volumes this is a ten-minute job and it converts a complaint into a message the customer receives before they have started worrying.
That is the whole intervention. It is not sophisticated and it is the highest-return use of ten minutes in a fulfillment day, because the difference between a customer who was told and a customer who found out is the difference between a support ticket and a refund request.
Sort by shipment age, not by exception date. A parcel that went into exception yesterday and a parcel that has been sitting in exception for eight days need different responses, and only one of them is about to become a claim.
Use the same list for claims. Exceptions that resolve into a late delivery on a guaranteed service are the input to a refund request, and the window for filing those is short. A list you look at daily catches them inside it. A list you look at monthly does not.
Worth being clear about, because the instinct is to write a rule.
Automation rules act on orders, at import, before anything has shipped. A tracking exception happens days later on a shipment record. Classic rules fire once and do not re-evaluate, which is the defining property of the engine, and it means there is no rule that can watch for a status change on something already out the door.
Accounts with the redesigned Automation Rules screen have workflows with additional triggers — tag added, tag removed, and a schedule. That helps with anything you can express as a tag applied to an order. It does not help here, because the exception status is on the shipment rather than the order and nothing applies a tag when it changes.
So this stays manual, and the honest framing is that it is a process to run rather than a thing to configure.
Two smaller things worth setting once.
Notification emails carry your logo and colours, configured alongside the Branded Tracking Page. If you have enabled the emails and not the branding, your customers are receiving a generic template, which is a strange thing to be sending on a message they will open.
Multiple recipients are set per order in the Order Details screen rather than globally. That is useful for B2B, where the person who ordered and the person receiving are different, and it is a per-order action.
Send yourself the set. Put a BCC address on one store, ship a real order to yourself, and read all four emails in the order they arrive. Most people who have never done this find at least one thing that is wrong, out of date or unbranded.
Then look at the last month of Delivery Exceptions. Count them, and count how many turned into a customer contact. The ratio tells you what a daily review is worth, and on most operations it is a larger number than the effort involved.
Notifications describe what happened. They do not change it. A parcel that is going to be three days late is going to be three days late whether or not you emailed about it.
What they change is who owns the problem. A customer told in advance is a customer being kept informed. A customer who finds out by waiting has been let down, and those two are the same delivery with different outcomes.
The rest of that argument is about what the customer is actually buying, which is a date rather than a carrier.
String builds and maintains logic like this inside existing ShipStation accounts — cartonization, rate selection, batching, inventory-aware holds, cold chain rules. No dashboard, nothing for your team to learn.
Typically for operations past 6,000 orders a month with a dedicated fulfillment team.
