主动发货通知：分阶段时间线及消息示例

主动式运输通知应根据有意义的运输事件发送，而不是按照固定的每日时间表发送。对于电商团队而言，实用的顺序是订单确认、承运商交接、预计送达时间变化、派送中和送达确认；当延误或配送问题需要关注时，应另外发送提醒。每条消息都应说明已确认的事项、接下来会发生什么，以及客户是否需要采取行动。

本指南提供基于事件的时间线、可调整的消息示例和运营规则，帮助你让通知保持实用，同时避免每次追踪扫描都变成另一封邮件。模板仅为示例性建议，并非承运商要求，也不保证具体服务时间线。

围绕客户决策建立运输通知时间线

订单、履约和配送事件分别描述不同的事项。订单确认表示商店已收到订单。创建运输标签并不表示承运商已经持有包裹。预计送达时间也不等同于有保证的配送预约。

这些区别应决定每条消息的触发条件和措辞。例如，USPS 在其追踪状态指南中，会区分发货前信息与表明其已持有物品的事件。其他承运商可能使用不同的标签，因此应根据事件的含义配置消息，而不是仅仅匹配状态名称。

分阶段消息示例

将方括号字段替换为已验证的信息。如果字段不可用，请删除该句，或使用能够体现不确定性的替代表述。不要让空的预计时间字段变成猜测的送达日期。

1. 订单已确认：建立起点

发送时间：订单成功记录后。此触发条件应由订单管理系统负责，而不是由承运商信息源负责。

确认订单号、购买的商品和配送地址。将准备工作与运输过程分开说明。只有在预计发货时间反映商店实际履约承诺时，才应包含该信息。

主题：我们已收到您的订单 [order number]

感谢您，[first name]。我们正在准备您的订单。您的配送地址是 [address]。包裹交给承运商后，我们会再次通知您。您可以在此查看订单：[order link]。如果发现任何问题，请通过 [support link] 联系我们。

除非您的履约流程在此阶段支持更改地址，否则不要承诺仍可修改地址。

2. 已创建标签：解释为什么追踪信息可能没有变化

发送时间：追踪号码已生成，但尚未确认承运商已持有包裹。

此消息为可选项。如果交接通常会在之后很快发生，将这些信息合并到稍后的发货确认中可能更清晰。当客户已经看到追踪号码，并可能将创建标签误认为包裹已实际移动时，单独发送通知会更有用。

主题：订单 [order number] 的追踪信息已可用

我们已为您的包裹创建运输标签。承运商尚未确认取件，因此追踪信息可能暂时不会显示运输进展。承运商收到包裹后，我们会通知您。追踪包裹：[tracking link]。

如果在超过内部发货阈值后，标签仍没有对应的交接事件，请创建运营任务。反复发送相同的安抚信息不能代替检查包裹是否已经离开仓库。

3. 承运商交接：发送发货确认

发送时间：承运商接收事件或其他可靠的交接记录确认承运商已持有包裹后。

此时适合发送清晰的发货确认。只有在团队选定的信息源提供了预计送达日期时，才应包含承运商、追踪链接和预计送达日期。

主题：您的订单 [order number] 已交给承运商

[Carrier] 已收到您的包裹。目前预计送达时间段为 [date range]。这是一个预计时间，可能会随着运输进展而变化。您可以在此查看运输进度：[tracking link]。

如果没有预计时间，请将预计时间句替换为：“目前还没有可用的预计送达时间。请查看您的追踪页面，获取承运商的最新更新。”

4. 运输中：仅在信息会改变客户预期时通知

发送时间：出现有意义的里程碑、预计送达时间调整，或其他会改变客户预期的进展时。

常规设施扫描通常应显示在追踪页面中，而不是通过单独消息发送。对于国际货件，清关里程碑可能有用，但包裹抵达目的国本身并不能证明已经完成清关或可以派送。

主题：关于您的订单 [order number] 的更新

您的包裹已完成 [verified milestone]。目前预计送达时间段为 [date range]。现阶段您无需采取任何行动。查看最新追踪信息：[tracking link]。

只有在确定客户无需行动时，才使用“您无需采取任何行动”。如果承运商要求提供文件或付款，请先核实该要求，再引导客户前往官方渠道。避免在通知中加入不必要的身份或付款信息。

5. 延误或异常：说明已知事项以及下一步由谁负责

发送时间：承运商报告运输中断、预计送达时间发生重大变化，或货件未达到商店承诺时。

扫描记录之间存在间隔并不能证明包裹丢失。应将已确认的延误与根据你自己的规则生成的监控提醒区分开来。如果原因未知，应如实说明，而不是将其归因于天气、海关或承运商运力。

主题：您的配送时间比预期更长

您的订单 [order number] 尚未在我们告知的配送时间段内送达。目前我们还没有确认的新送达日期。我们的支持团队正在检查货件，并会在 [support follow-up date] 前向您更新。您无需再次提交请求。当前追踪信息：[tracking link]。

后续跟进日期是团队作出的承诺，并不是新的预计送达时间。发送消息前，请创建一项已分配负责人的支持任务。如果已确认的异常需要客户采取行动，请将一般性的安抚内容替换为具体行动和截止日期。

6. 派送中：帮助客户做好准备，但不要保证送达

发送时间：承运商报告包裹正在派送时。

不要将这一状态转化为保证到达时间。只有在该货件已确认需要签名或有配送时间段时，才提及相关要求或时间段。

主题：您的包裹正在派送中

[Carrier] 报告您的包裹正在派送中。预计今天送达，但路线或时间可能会发生变化。请在此查看最新状态和可用的配送说明：[tracking link]。

如果包裹没有送达，请使用下一个已确认的状态，或采用适当的未完成配送处理流程。当日过去后，不要继续重复发送“今天送达”。

7. 尝试派送或待取件：明确说明下一步行动

发送时间：记录了派送尝试，或承运商确认包裹已可取件时。

这是两种不同的事件。派送失败并不一定意味着包裹已经可以在取件点领取。在确认可以领取之前，不要指示客户前往取件。

主题：您的包裹需要采取行动

[Carrier] 报告此次配送未能完成。请查看承运商关于可用后续步骤的说明：[official tracking link]。如果说明不清楚，请通过 [support link] 联系我们。

对于已确认的取件事件，请使用单独的模板：“您的包裹已准备好，可在 [verified location] 领取。请在 [confirmed deadline] 前领取。您可以在此查看营业时间和取件要求：[official link]。”任何尚未确认的字段都应省略；不要自行编造标准保管期限。

8. 已送达：确认承运商报告并提供问题处理途径

发送时间：承运商记录送达后。

应将该状态归因于承运商，而不是断言客户本人已经收到包裹。只有在配送地点或送达证明链接可用且适合分享时，才应将其包含在消息中。

主题：您的包裹已标记为送达

[Carrier] 已将您的包裹标记为于 [date] 送达。您可以在此查看配送详情：[tracking link]。如果找不到包裹，请查看任何配送地点信息，并在适用时询问家庭成员或楼宇前台。仍然找不到？请通过 [support link] 联系我们，以便我们协助调查。

应让丢失包裹的求助途径始终清晰可见。当送达确认与客户实际体验不符时，促销内容不应遮挡客户需要采取的措施。

确保时间线准确的规则

将包裹与订单分开追踪

一个订单可能包含多个包裹，分别由不同承运商运输，并有不同的送达日期。每条消息都应注明所涉及的商品或包裹编号。当购买内容的一部分仍在运输中时，“2 个包裹中的第 1 个已送达”比“您的订单已送达”更准确。

保存订单、履约、追踪号码和所含商品之间的关系。同时还要考虑补发货件，避免其配送事件意外关闭原始支持案例。

去除重复事件并处理延迟更新

承运商或集成系统可能会提供重复更新。应围绕货件、事件身份和通知类型建立去重规则。发送新消息前，检查是否已经发送过相同消息。

如果条件允许，应同时保留事件发生时间和系统接收时间。延迟到达的运输事件不应在送达确认之后触发“运输中”通知。对于冲突或更正事件，应进行协调处理，而不是假设每条新记录都代表运输继续向前推进。

为每个异常指定运营负责人

仓库团队应调查未确认的交接。支持或物流团队应负责运输异常和客户跟进。你的消息工作流应在通知旁记录负责人、下一步行动和审核截止时间。

应根据履约承诺和观察到的承运商线路行为定义监控阈值。对于国内特快、国际经济型运输、周末和海关处理，不存在一个同样适用的统一扫描间隔阈值。

协调电子邮件、短信和追踪页面

使用电子邮件进行更完整的说明，使用追踪页面展示详细的事件历史。仅在收件人已获得必要许可且渠道适当时，才使用短信或推送提醒发送有用且具有时效性的更新。许可和消息要求因司法管辖区及渠道而异；请根据实际市场进行配置。

不要默认通过所有渠道发送完全相同的消息。让运输更新聚焦于交易本身，尊重相关偏好，并避免在锁屏可见的消息中包含完整地址或其他不必要的个人信息。

将工作流付诸实践

先建立事件到消息的映射，再选择能够支持该映射的工具。对于 Shopify 商家，在评估追踪和运输通知工作流时，17TRACK 订单追踪应用页面是一个相关的起点。请根据所需的触发条件、渠道和异常规则，检查其当前功能和设置，不要假设本指南中的每个模板都能作为内置自动化使用。

无论使用哪种系统，都应测试其行为，而不仅仅是模板外观：

• 只有标签没有交接：消息不得声称承运商已经持有包裹。
• 重复事件：客户不应两次收到相同提醒。
• 预计时间变化：消息应指出新的预期，不得保留过时日期。
• 拆分订单：每条通知都应标明正确的包裹或商品。
• 数据缺失：空的日期、地点和承运商名称不应以损坏的占位符形式出现。
• 延迟事件：较早的扫描不应生成相互矛盾的通知。
• 异常：承诺进行调查后，应为指定团队创建任务。
• 已送达但包裹缺失：客户应拥有可用的支持途径。

上线后，检查通知失败、重复发送、运输相关支持联系和未解决异常。应保持测量窗口的一致性。仅仅减少支持联系并不能证明沟通变得更好，因为客户也可能只是更难联系到你的团队。

常见问题

商店应发送多少条运输通知？

应使用有意义的事件，而不是强制规定消息数量。一次简单的运输可能只需要订单确认、承运商交接、派送中和送达确认。当预计时间发生变化或客户需要采取行动时，再增加消息。已创建标签和常规运输通知是可选的。

运输通知是否应包含送达日期？

当你拥有可靠的信息来源时，可以包含日期或时间段，并准确标明其属于预计时间还是承诺时间。如果没有可靠的预计时间，应说明目前尚不可用。不要根据一般运输平均时长计算精确到达日期，再将其表述为承运商已确认的信息。

追踪信息没有更新时应该说什么？

说明最后一个已确认的事件，并解释团队下一步正在做什么。仅有扫描间隔并不能证明货件延误或丢失。如果订单未达到承诺，应单独承认这一点，并提供合理的支持跟进时间。

延误通知是否应自动提供退款或补发？

只有当客户情况符合你的政策和适用义务时，才可以这样做。仅凭追踪异常可能没有足够信息来决定补救措施。应将案件转交给适当团队，并避免承诺工作流无权批准的结果。

运输通知可以包含促销内容吗？

应确保配送信息和任何必要行动都易于找到。加入促销内容可能会影响消息在适用消息规则下的认定，因此在将营销内容加入交易更新之前，应审核渠道和司法管辖区的要求。

来源

• USPS：我的包裹在哪里？ — 用于解释追踪阶段的参考资料，包括发货前、承运商持有、送达以及与配送相关的状态。不能假定 USPS 的术语适用于所有承运商。
• Shopify 应用商店：17TRACK — 用于评估实施部分提到的 Shopify 订单追踪和通知解决方案的官方市场页面。

通知顺序、示例文案和测试清单均为编辑建议。它们不是通用的承运商流程，也不是对特定软件配置的承诺。