首页博客资源如何自动化货件通知：6 个步骤了解触发器、渠道和模板

如何自动化货件通知：6 个步骤了解触发器、渠道和模板

17TRACK

要自动化货件通知，请将货件事件连接到订单记录，定义哪些状态变化需要发送消息，选择获准的投递渠道，并为每个触发器关联模板。然后在上线前加入重复通知防止、异常处理和测试。以下六个步骤展示了电商团队如何构建工作流，在不发送重复或误导性提醒的情况下，为客户提供有用的更新。

如何通过6个步骤自动化货件通知触发器、渠道和模板

本指南适用于负责购后沟通的商家、电商运营团队和开发人员。建议从一组可靠的通知开始：承运商接收、派送中、已送达，以及需要客户采取行动的异常情况。只有在其他消息能够回答不同的客户问题时，才添加这些消息。

1. 将跟踪事件连接到正确的订单和收件人

运输标签、承运商扫描和客户通知是不同的事情。创建标签并不代表承运商已经收到包裹。自动化流程从一开始就应保留这种区别。

首先确定负责通知决策的系统。它可能是商店的通知工作流、跟踪应用，或连接到订单管理系统的服务。为每种消息类型指定一个负责人，避免多个系统分别发送相同的更新。

有两种实用的实施方式：

  • 基于应用的设置：当团队希望配置受支持的事件和面向客户的消息，而不构建完整集成时，可以使用电商跟踪应用。对于 Shopify 商家，17TRACK 应用列表是评估货件跟踪和通知工作流的相关起点。配置规则前，请确认具体的触发器、渠道、自定义选项和方案要求。
  • 基于 API 的设置：当货件事件必须传入现有订单系统或自定义消息工作流时，可以使用跟踪集成。17TRACK Tracking API及其官方文档是相关的实施参考。请确认计划使用的集成所采用的事件交付机制、负载字段、身份验证和重试行为。接收跟踪数据与发送客户消息是两项不同的职责。

无论选择哪种方式，都应将每个货件映射到正确的订单和收件人。一条有用的内部记录包括：

  • 订单参考号和货件标识符。
  • 跟踪号码和承运商标识符（如有）。
  • 该货件中包含的商品，尤其是拆分订单中的商品。
  • 客户联系信息、语言、时区和渠道偏好。
  • 最近一次已接受的货件状态及事件发生时间。
  • 通知历史，包括每条消息涉及哪个货件。

将事件发生时间与系统收到更新的时间分开记录。延迟扫描不应自动变成新的客户提醒。同时保留承运商的原始描述，并记录规范化状态，以便支持人员调查含义不明确的事件。

2. 定义能够反映有意义货件变化的触发器

触发器应代表与客户相关的变化，而不是每一条新的跟踪记录。多个设施扫描可能都表示“运输中”。为每一次扫描发送通知只会制造噪音，并不能帮助客户做出决定。

将传入事件映射到一组易于理解的状态。下表是建议的工作流，并非适用于所有承运商的通用状态字典。

触发器发送条件消息目的
已创建标签可选；区分准备阶段与承运商持有包裹。说明跟踪信息已准备就绪。
承运商已接收受支持的事件表明承运商已收到包裹。确认货件已进入承运商网络。
运输中可选里程碑；抑制重复的常规扫描。提供有意义的进度，而不是逐次扫描信息流。
派送中传入状态明确支持这一解释。帮助客户准备接收包裹。
派送异常发现了有意义的问题或需要采取的行动。说明问题和下一步有用的操作。
已送达承运商报告该货件已送达。确认报告的结果并提供求助途径。

对异常情况的处理应比常规里程碑更加谨慎。派送失败、海关问题、地址问题和退回寄件人事件可能需要不同的说明。如果事件没有解释客户应采取什么措施，就不要自行编造解决方案。

对于“近期无更新”规则，应根据服务和路线选择合适的阈值，而不是采用一个统一的时间间隔。没有扫描记录并不能证明包裹丢失。将不确定的情况转入内部审核队列，或发送准确描述已知信息的中性更新。

将预计送达日期与货件状态分开。只有在拥有可靠来源时才加入预计日期，并明确标注为预计日期；不要用运营无法支持的计算承诺替代缺失数据。

3. 选择渠道并设置联系规则

选择渠道应因为它适合消息和客户偏好，而不只是因为它可用。对于详细更新，电子邮件是实用的起点。即时性更高的渠道可用于有时效性的行动，但前提是获得许可、符合提供商规则和当地要求。

  • 电子邮件：适合提供订单背景、跟踪链接、拆分货件说明和支持指引。应包含纯文本版本，并检查移动端布局。
  • 短信：在获准的情况下，适合发送简短且可执行的提醒。标明发送者，保持消息聚焦，并避免暴露不必要的订单信息。
  • 推送通知：适用于客户使用你的应用并已启用通知的情况。链接到相关货件，而不是通用主页。
  • 消息应用：当客户已经使用该渠道，且实施符合平台的许可和消息要求时，可以考虑使用。
  • 跟踪页面：将其作为详细信息参考页面。它可以补充外发通知，但当客户需要采取行动时，不能取代提醒。

记录渠道之间的关系。例如，可以使用电子邮件发送常规里程碑，并使用获准的移动渠道发送需要采取行动的派送问题。不要自动通过每个可用渠道发送每个事件。

设置免打扰时间处理方式和备用策略。临时电子邮件发送失败不应自动授权发送短信。切换渠道前，请确认拥有合适的联系方式和许可，并确认其他系统尚未发送该消息。

保持货件更新的运营属性。加入促销内容可能影响消息在适用规则下的处理方式。在美国，FTC 的 CAN-SPAM 指南说明，当商业内容和交易内容结合时，消息的主要目的很重要。不要认为所有提及订单的消息都不受商业电子邮件要求约束。

4. 构建具有清晰备用行为的模板

每个模板都应回答三个问题：发生了什么？这对本次货件意味着什么？客户下一步应该做什么？使用条件字段，使缺失数据能够干净地消失，而不是留下损坏的占位符。

以下示例是起始模板。方括号中的变量仅用于说明，并不代表某个平台的具体模板语法。

承运商接收邮件

主题：订单 [order_number] 的货件正在发往途中

您好，[first_name]：

[carrier_name] 已收到订单 [order_number] 的货件。您可以在此跟踪进度：[tracking_link]。

[如果有可靠的预计日期：预计送达日期：[estimated_delivery_date]。该预计日期可能会发生变化。]

[如果订单已拆分：本货件包含 [shipment_items]。订单中的其他商品将有单独的跟踪更新。]

派送中消息

根据承运商的最新更新，订单 [order_number] 的货件正在派送中。查看进度和任何可用的派送详情：[tracking_link]。

除非运营有充分依据，否则不要添加保证的到达时间。“派送中”是报告的状态，并不保证当天一定完成派送。

包含已验证下一步的异常消息

主题：订单 [order_number] 的派送更新

承运商报告您的货件存在以下情况：[plain_language_issue]。[verified_next_step]。在此查看最新详情：[tracking_link]。如需帮助，请通过 [support_link] 联系我们。

如果没有确认的下一步，请将该句替换为：“我们目前还没有确认的下一步。请查看跟踪页面获取更新，或联系我们的支持团队。”只有在确实已分配审核任务时，才能说团队正在调查。

已送达邮件

主题：您的货件已标记为送达

[carrier_name] 已将订单 [order_number] 的货件标记为于 [delivery_date] 送达。在此查看可用的派送详情：[tracking_link]。如果您找不到包裹，请通过 [support_link] 联系我们，以便我们帮助您了解下一步。

对于拆分订单，应使用货件级措辞。当另一个包裹仍在运输中时，“您的订单已送达”可能会产生误导。如果承运商名称、日期或客户姓名不可用，请使用经过测试的替代句子，而不是显示空字段。

5. 增加防止重复、过时和误导性消息的保护措施

自动化需要记录已经完成的操作。仅在事件到达时发送消息的工作流，可能会在重试后重复提醒，或在新的里程碑出现后发送过时信息。

  • 防止重复处理：在可用时使用稳定的事件标识符。否则，根据货件、事件类型和事件发生时间等合适字段定义去重键。另行记录相应通知是否已经安排或发送。
  • 抑制状态重复：映射到同一客户可见状态的多个扫描，不应自动产生多条消息。
  • 发送前检查事件相关性：发送前重新评估排队中的消息。如果此后已报告送达，则抑制旧的运输中提醒。
  • 有意处理更正：保留原始事件历史并审核看似倒退的状态。不要假设后到达的每个事件都更新或更准确。
  • 安全重试：区分发送失败和结果未知。在支持的情况下，使用提供商的幂等功能，降低重试产生另一条消息的可能性。
  • 保护收件人匹配：绝不能仅根据未经验证的跟踪号码匹配将货件关联到客户。
  • 升级未解决的异常：指定运营负责人，而不是反复向客户发送相同警告。

对于自定义集成，请遵循提供商关于身份验证、事件确认和重试的文档方法。保持处理日志有用，但不要在其中复制不必要的个人数据。跟踪链接也应避免暴露其他客户的订单，或超出收件人所需范围的信息。

一个有用的处理顺序是：验证事件、识别货件、更新其状态、检查通知资格、选择获准渠道、渲染模板、将消息加入队列并记录结果。如果消息在队列中等待，则在发送时重新检查资格。

6. 测试完整旅程，然后逐步上线

不要只根据测试邮件是否显示正确来判断工作流。应测试从货件事件到客户目的地的完整路径，包括失败情况。

  • 正常流程：接收、运输、派送中和已送达会产生预期消息。
  • 重复事件：重放相同事件不会创建另一条通知。
  • 乱序事件：延迟的运输扫描不会在送达后触发过时提醒。
  • 拆分订单：每条消息都能识别正确货件，不会暗示所有商品都已送达。
  • 字段缺失：缺少姓名、承运商、预计日期或商品列表时，会生成可读的备用文本。
  • 联系限制：工作流遵守渠道偏好、抑制规则和配置的免打扰时间。
  • 投递失败：无效地址、提供商错误和重试会产生可追踪的结果，不会失控地重复发送。
  • 客户操作：每个跟踪和支持链接在移动设备上都能到达预期目的地。

从数量有限的货件开始，并结合跟踪历史审核消息历史。让支持人员能够查看客户收到了什么。保留暂停控制，以便团队可以停止错误规则，而不必禁用货件跟踪本身。

监控通知资格、发送尝试、提供商接受、失败、重复，以及从接收事件到发送消息之间的延迟。提供商接受并不代表客户已经阅读消息，仅凭打开率也不能证明工作流产生了帮助。

要评估对客户的影响，应使用一致的定义和可比的货件组比较与货件相关的联系率。在将变化归因于通知之前，应考虑承运商组合、派送问题和订单量的变化。

常见问题

应在创建标签时发送发货确认吗？

可以发送已创建标签的更新，但应准确描述。可以说运输详情已准备好，或货件正在准备中。只有在有相应事件支持时，才使用确认承运商已持有包裹的措辞。

没有 API 集成，货件通知也能正常工作吗？

可以。基于应用的工作流可能通过其界面处理连接和通知规则。请确认所选设置中可用的事件、渠道、模板控制和异常处理。现有系统需要专门的路由或决策逻辑时，自定义集成更为合适。

每个货件应接收多少条通知？

没有统一的理想数量。从明确、有用的里程碑和可采取行动的异常开始。抑制重复的运输扫描，仅在消息能够提供客户需要的信息时添加消息。

跟踪停止更新时应怎么办？

应用适合该服务的审核规则，而不是直接宣布货件丢失。检查最后一个事件、可用的预计送达时间和相关运营流程。只有在能够增加已验证信息或有用下一步时，才向客户发送更新。

已送达通知可以自动关闭支持工单吗？

已送达扫描可以更新工单，但不应自动解决客户报告的未收到问题。将承运商的送达状态和客户的问题作为不同记录处理，然后按照调查流程执行。

来源