Shippo 应用还是 API：如何让配送适配商店

先选运营模式，再选界面

Shippo 提供配送应用和 API，能力包括面单、承运商连接、追踪和退货。两者代表将配送融入企业的不同方式：应用为操作人员提供现成工作空间，API 则把配送功能连接到其他系统。正确选择取决于员工在哪里工作，以及长期由谁维护连接。

列出从收到订单到交出包裹的各个步骤，明确现有哪个系统负责每一步。如果员工在配送工作空间就能顺畅完成任务，定制集成可能增加不了多少价值。如果配送必须在仓库应用或其他既定流程中完成，则可以考虑 API。不要把定制开发自动视为成熟的标志。

仔细定义配送数据

创建一份配送记录样本，包含发件人、收件人、商品明细、包裹尺寸和重量。明确单位。纳入企业服务的目的地和产品所需信息，并向相应承运商及服务核实要求。不完整的配送数据无论经由界面还是 API 进入，都会变成运营问题。

决定如何处理更正。客户可能在下单后改地址，包装人员也可能发现预计纸箱不合适。记录何时仍可修改，以及必须更新哪个系统。流程应让履约和客服都能看到最新配送信息。

把故障处理当作一项功能评估

对于应用，请操作人员处理字段缺失、服务不可用和配送取消。对于集成，请开发者解释如何记录失败、如何控制重试，以及员工怎样得知需要处理某项操作。如果系统只有在每次请求都成功时才能运作，迟早会在不方便的时候需要人工调查。

明确区分创建面单与确认包裹进入承运商网络。不能仅因为面单已经存在，就告诉客户和员工订单已经实际发货。确保内部流程使用的状态术语描述的是确实发生的事件。

比较完整拥有成本

计入订阅或用量收费、实施、持续维护和操作人员培训。定制连接应指定变更负责人，并记录另一位开发者如何接手。使用应用时，则检查导出和集成是否覆盖现有系统需要的信息。

当 Shippo 的服务符合配送目的地和团队工作方式时，值得评估。先使用范围小但有代表性的配送样本，并记录结果。选择能够满足已证明需求的最简单方式。订单模式或运营系统发生变化时重新评估，而不要仅因订单量增长就重建配送流程。