BigCommerce 配送集成：费率、标签和追踪选项

BigCommerce 配送集成主要承担三项不同的工作：在结账时计算配送费率、为履约购买面单，以及在发货后追踪包裹。对于商家而言，合适的设置不一定是一个承诺包办一切的应用，而是一套相互连接的工作流，使结账方式、仓库操作、货运记录和客户更新保持一致。

从目前出现问题的配送环节开始。如果结账费用异常，应检查费率；如果打包和发货缓慢，应检查面单工作流；如果缺少配送更新，应改进追踪。这些问题可以共享订单数据，但解决其中一个并不会自动解决其他问题。

每种配送集成实际负责什么

在选择集成之前，应将面向客户的配送方案与履行该方案所需的运营工作区分开来。结账时收取的配送费不一定等于之后购买面单所支付的金额，而追踪号码也不能证明承运商已经收到包裹。

BigCommerce 的官方应用市场是寻找打包集成的起点。其开发者文档则是验证自定义连接的起点。仅凭市场列表，不能确认某个应用支持你使用的每个国家、承运商服务、结账配置或履约工作流。

围绕工作流选择集成路径

规则简单时使用平台配送设置

如果你的配送方案比较简单，应先检查商店中已经提供的配送配置。在添加其他系统之前，先定义服务目的地、购物者应看到的配送方式，以及这些方式背后的商业规则。

例如，一家提供标准国内配送费的商店，可能需要更清晰的配送区域和排除规则，而不是外部费率引擎。一家从多个地点配送超大产品的商店则面临不同问题：简单的费用可能掩盖履约成本之间的重要差异。

最适合：包裹情况可预测、履约复杂度有限，并且现有配置能够表达其配送规则的商家。当所需逻辑无法可靠表示时，再考虑超出此路径，而不应仅仅因为其他应用拥有更多设置就更换方案。

需要重复性履约工作时使用打包集成

当员工需要反复复制地址、选择服务、购买面单或输入追踪号码时，值得评估打包配送集成。它的价值在于减少交接，并使订单记录与实际发出的货物保持一致。

不要假设每个面单集成都能提供结账费率。同样，也不要假设能够导入订单的应用可以将货件详情回写到 BigCommerce。要求服务提供商使用你的工作流演示每个必要的数据流转方向。

最适合：希望使用成熟操作界面、又不想维护自有集成的团队。如果关键仓库规则需要通过手动变通来处理，从而抵消节省的时间，则不适合使用该方案。

其他系统负责履约时使用自定义连接

当订单管理系统、仓库平台或第三方物流服务商已经控制发货时，自定义集成可能更合适。在这种安排中，BigCommerce 可能只是销售渠道，而不是每项配送操作的运营事实来源。

明确哪个系统负责地址、包裹决策、面单购买、货件创建和追踪更新。然后在相关文档中确认所需的 API 操作、身份验证要求、权限和平台限制。

最适合：确实存在工作流需求，并且具备维护能力的商家。一旦将监控、支持和未来变更纳入考虑，自定义开发并不一定是成本最低的路径。

费率：让结账承诺与配送运营相匹配

费率集成应生成你能够履行的配送方案，而不只是返回一个数字。在测试服务提供商之前，应记录决定服务适用性和成本的发货地、目的地、产品及包装输入。

• 发货地：哪个仓库或履约合作伙伴会发出订单？
• 产品数据：重量和尺寸是否准确，单位是否统一？
• 包装：计算使用单个产品、选定纸箱，还是估算的包裹？
• 目的地：偏远地区、邮政信箱和服务范围之外的地点如何处理？
• 商业规则：你会收取计算出的金额、补贴配送费，还是应用促销门槛？

结账费用和面单成本可能不同，因为履约时使用的包裹、服务、发货地或账户与结账时的假设不同。在认定费率计算错误之前，应比较测试订单的两方面。

还应定义失败处理方式。如果费率请求失败，结账应显示已配置的替代方案、移除受影响的方式，还是停止订单？适当选择取决于团队是否能够履行该替代方案。接受一个无法配送的订单的备用费用，并不算成功恢复。

对于国际订单，应将运输费用与关税和税费分开。除非负责的服务明确计算相关费用，且履约流程支持所声明的付款安排，否则不要将费率描述为全包到岸成本。

面单：评估完整的发货周期

面单购买应从订单导入一直测试到取消，而不仅仅是测试第一次成功打印。运营层面要确认的是，集成是否能让仓库工作与商店记录保持同步。

使用以下验收检查：

1. 订单导入：确认正确的订单能够进入履约环节，并且编辑能够按预期处理。
2. 包裹创建：测试单个包裹、多个包裹，以及只发出部分商品的订单。
3. 服务选择：检查购物者的结账方式如何映射到仓库员工购买的服务。
4. 打印：确认面单尺寸、文件格式和打印设置能够与实际仓库设备配合使用。
5. 货件回写：验证正确的追踪信息和已发出商品能够写入 BigCommerce 订单。
6. 重新打印和作废：明确员工如何避免重复购买，以及未使用面单如何按照适用的服务提供商规则处理。

一个特别有用的测试是：面单购买成功，但后续订单更新失败。员工需要一种恢复路径，在不再次购买面单的情况下更新订单。这正是成熟演示与可靠生产工作流可能存在差异的地方。

还应检查谁负责客户通知。如果配送集成和另一个已连接系统都发送发货消息，客户可能会收到重复或相互冲突的更新。

追踪：区分货件记录与配送可见性

将追踪号码写入订单可以解决记录保存问题。收集后续承运商事件则可以解决可见性问题。你的业务可能两者都需要，但应分别进行评估。

有用的追踪工作流应保留订单、货件、包裹、承运商和追踪号码之间的关系。当一个订单包含多个包裹，或一个包裹经过多个配送运营商时，这种关系非常重要。

对于由开发人员主导的追踪层，17TRACK Tracking API 是值得评估的选项。其官方 API 文档为在自定义工作流中评估追踪注册和事件交付提供了依据。这是追踪使用场景，不能替代结账费率计算或面单购买。

不要假设拥有 API 就意味着包含现成的 BigCommerce 连接器。应明确货件详情如何从商店或履约系统传入追踪服务，更新如何到达目标位置，以及由谁维护连接。

在实施之前，确认是否支持你实际使用的承运商和服务、相关订阅条款以及更新交付配置。然后测试延迟扫描、无法识别的号码、重复更新和配送异常。追踪集成无法制造尚未发生的实体承运商扫描。

还应在企业内部指定追踪负责人。除非有人负责调查停滞货件，并决定何时联系承运商或客户，否则异常仪表板的运营价值有限。

比较总成本，不要依赖醒目定价

由于这些集成层承担不同的工作，应根据所需工作流比较成本，而不是只看单一的宣传订阅价格。

• 软件费用：确认订阅费、使用额度、超额费用和单独计费的功能。
• 配送费用：将邮资和承运商调整费用与软件费用分开。
• 实施费用：包括设置、数据清理、服务映射、测试和员工培训。
• 持续运营：考虑手动更正、同步失败和支持责任。
• 退出要求：确认如何获取货件记录，以及如何在不影响未完成订单的情况下移除连接。

要求每个服务提供商解释哪些事件会计入计费使用量。订单、面单、包裹、已注册追踪号码和 API 请求并不是可互换的计量单位。估算成本时，应使用自身运营中的代表性周期。

切换前运行小规模端到端试点

最可靠的选择方法是使用真实订单进行受控试点。应包括普通国内包裹、多商品订单、拆分货件，以及对业务重要的任何国际或特殊货件类型。

对于每项测试，记录结账方案、所选服务、面单结果、货件记录、追踪目标和客户通知。至少加入一个失败案例，例如地址被拒或同步中断。

明确责任归属：电子商务团队批准结账行为，仓库员工批准打包和打印，客户支持批准货件可见性，技术负责人批准权限和恢复流程。检查每个连接会接收哪些客户数据，并且只授予其工作所需的访问权限。

实际建议：在运营允许的范围内保持设置简单。在现有配送配置满足要求时继续使用；在履约集成能够消除重复工作时添加它；当货件可见性需要独立工作流时引入专门的追踪层。应有意识地连接各层，而不是默认购买相互重叠的功能。

常见问题

费率、面单和追踪需要单独的集成吗？

不一定。一个集成可能涵盖多个功能，而另一个可能只处理其中一项。应独立验证每项所需功能，包括它是否读取订单、将货件信息写回，以及是否提供后续追踪更新。

面单集成会自动改变结账配送费率吗？

不要这样假设。面单购买发生在履约期间，而结账费率是在下单前展示的。确认集成是否提供结账费率功能，以及该功能是否适用于商店配置。

可以连接我自己的承运商账户吗？

这取决于集成、承运商、账户资格和配送区域。询问支持哪些账户和服务、是否可以使用你的账户费率，以及由谁收取邮资和后续调整费用。

17TRACK 可以替代 BigCommerce 面单工具吗？

Tracking API 应用于评估追踪可见性，而不是替代面单购买。自定义工作流可以将货件信息连接到追踪服务，同时由负责这些任务的系统继续处理结账计算和面单创建。

为什么客户收到追踪号码后可能看不到任何进展？

追踪号码可能在包裹获得第一次承运商扫描之前就已经存在。其他可能性包括号码错误、承运商识别问题或事件延迟提供。在将没有更新视为软件故障之前，应检查履约交接和承运商信息。

来源

• BigCommerce 应用市场 — 用于识别打包集成并查看单个列表的官方起点。
• BigCommerce 开发者文档 — 用于验证平台集成要求和 API 实施细节的官方参考资料。
• 17TRACK Tracking API — 本指南所讨论的追踪 API 选项的官方产品参考资料。
• 17TRACK API Documentation — 用于评估自定义追踪工作流的技术参考资料。