Shippo 應用還是 API：如何讓配送適配商店

先選運營模式，再選介面

Shippo 提供配送應用和 API，能力包括面單、承運商連線、追蹤和退貨。兩者代表將配送融入企業的不同方式：應用為操作人員提供現成工作空間，API 則把配送功能連線到其他系統。正確選擇取決於員工在哪裡工作，以及長期由誰維護連線。

列出從收到訂單到交出包裹的各個步驟，明確現有哪個系統負責每一步。如果員工在配送工作空間就能順暢完成任務，定製整合可能增加不了多少價值。如果配送必須在倉庫應用或其他既定流程中完成，則可以考慮 API。不要把定製開發自動視為成熟的標誌。

仔細定義配送資料

建立一份配送記錄樣本，包含發件人、收件人、商品明細、包裹尺寸和重量。明確單位。納入企業服務的目的地和產品所需資訊，並向相應承運商及服務核實要求。不完整的配送資料無論經由介面還是 API 進入，都會變成運營問題。

決定如何處理更正。客戶可能在下單後改地址，包裝人員也可能發現預計紙箱不合適。記錄何時仍可修改，以及必須更新哪個系統。流程應讓履約和客服都能看到最新配送資訊。

把故障處理當作一項功能評估

對於應用，請操作人員處理欄位缺失、服務不可用和配送取消。對於整合，請開發者解釋如何記錄失敗、如何控制重試，以及員工怎樣得知需要處理某項操作。如果系統只有在每次請求都成功時才能運作，遲早會在不方便的時候需要人工調查。

明確區分建立面單與確認包裹進入承運商網路。不能僅因為面單已經存在，就告訴客戶和員工訂單已經實際發貨。確保內部流程使用的狀態術語描述的是確實發生的事件。

比較完整擁有成本

計入訂閱或用量收費、實施、持續維護和操作人員培訓。定製連線應指定變更負責人，並記錄另一位開發者如何接手。使用應用時，則檢查匯出和整合是否覆蓋現有系統需要的資訊。

當 Shippo 的服務符合配送目的地和團隊工作方式時，值得評估。先使用範圍小但有代表性的配送樣本，並記錄結果。選擇能夠滿足已證明需求的最簡單方式。訂單模式或運營系統發生變化時重新評估，而不要僅因訂單量增長就重建配送流程。