配送追跡の例外管理を作る方法：荷物のステータスからチケットの解決まで

注文ページに配送業者のステータスを表示するだけでは、可視性の問題しか解決しません。マーチャントが実際に必要としているのは具体的な判断です。注文がいくつの荷物に分割されているか、どれが遅延しているか、住所の変更が必要か、いつ顧客に先回りして連絡するか、通関や紛失した荷物を誰が担当するか、そして解決結果を注文システムやサポートシステムにどう書き戻すか、といったことです。

r/ecommerceの複数の荷物からなる注文に関する議論では、1件の注文を分割して複数の追跡番号を割り当てたことで、異なるシステムから自動メールが送信され、一部の商品しか届かなかった顧客が、残りの商品は紛失したと思い込んだ事例が紹介されています。これは1事業者の事例であり、特定の物流ソフトウェアが市場で有効であることを証明するものではありません。それでも、データモデルの最初の落とし穴を的確に示しています。注文、出荷、荷物、追跡番号は同じオブジェクトではないということです。

最初のステップ：注文と物理的な荷物の分離

1つの注文に複数の出荷が含まれることがあり、1つの出荷に複数の荷物が含まれることもあります。さらに、荷物の追跡番号が変わったり、ラストマイルの配送業者に引き継がれたり、返送や再配達が発生したりすることもあります。データベースで注文テーブルにtracking_numberを1つしか保存していないと、以降のステータスはすべて互いに上書きされてしまいます。

4層の関係を設けることを推奨します。注文は商取引上の約束を保持し、出荷はフルフィルメントの手配を、荷物は物理的な品物を表し、追跡IDは配送業者と追跡番号を保持します。イベントは追跡IDに属し、荷物と注文に集約されます。注文が分割された場合でも、顧客には互いに無関係な5通のメールではなく、注文単位の進捗が表示されます。たとえば「1/2配達済み、残りの商品は明日到着予定」といった表示です。

荷物間の関係には明示的なバージョン管理が必要です。配送業者が出荷を統合または移管した後も、古い追跡番号が有効なまま残ることがあります。システムは新しい番号を別の注文として扱うのではなく、replaced_by、last_mile_tracking、または親子関係を記録する必要があります。

配送業者の生イベントの保持とセマンティクスの標準化

FedEx Basic Integrated Visibilityのドキュメントでは、スキャンイベント、配達予定時間帯、遅延ステータス、理由フィールドについて説明されており、配達予定日の情報はすべての追跡番号で返されるわけではないと明記されています。複数の配送業者に対応するプロダクトでは、ソースごとに精度が同じだと想定すべきではありません。

内部ステータスは、label_created、accepted、in_transit、out_for_delivery、delivered、exception、returning、unknownなどの少数のステージに集約できます。ただし、各イベントには配送業者の元のコード、説明、場所、イベント時刻、受信時刻、元のペイロードへの参照が保持されます。標準化されたステータスはワークフローに使用し、元のイベントは監査に使用します。

配送業者は表示テキスト、言語、時刻形式を頻繁に変更するため、正規化ルールを英語の説明文だけに依存させてはいけません。DHL Unified Trackingの更新ノートには、タイムスタンプへのタイムゾーンオフセットの明示や、イベントテキストの調整といった変更が記録されています。ロジックが特定の文言に依存していると、通常のアップグレードで例外アラートを見逃すおそれがあります。システムでは安定したコードのマッピングを優先し、未知のコード用に保留キューを用意すべきです。

時間軸も分けて扱う必要があります。イベント時刻は物理的な事象が発生した時刻、受信時刻はシステムがそれを受け取った時刻、記録時刻はデータがストレージに格納された時刻です。これらがずれた場合でも、リアルタイム追跡を装うためにイベントを並べ替えてはいけません。GS1 EPCIS v2.0.1はeventTimeとrecordTimeのセマンティクスを明確に区別しています。EPCISを完全に実装しない場合でも、この境界は取り入れる価値があります。

例外は単なる赤いラベルではない

例外としてラベル付けされたイベントには、それぞれ異なるアクションが必要です。住所の問題では受取人への連絡、通関の遅延ではコマーシャルインボイスの提出が必要です。天候による遅延では通常、到着見込みを更新します。配達失敗では再配達の日程を調整できる場合があり、スキャンが長期間途絶えた場合は配送業者への調査依頼が必要です。プロダクトは単に遅延メールを送るのではなく、ソースイベントを理由カテゴリ、推奨担当者、期限に対応付けるべきです。

例外ルールには、注文に関する情報も組み込む必要があります。高額商品、コールドチェーン商品、販促商品、配達日厳守の荷物では、待機時間のしきい値が異なります。モデルは自由記述の分類には役立ちますが、権限なしに返金、交換、配達日を約束してはなりません。アクションは、マーチャントのポリシーと運送会社が提供する機能に基づいて決定する必要があります。

対応につながる例外カードには、次の要素が含まれます。

• 注文と関連するすべての荷物、および完了済み・未完了の件数。
• 最新のイベント、運送会社から受信した未加工の説明文、発生時刻と受信時刻、データの鮮度。
• 当初および更新後の配達予定日と、その変更理由。ソースから配達予定期間が得られない場合は、明示的に空欄にします。
• 推奨アクション、担当チーム、顧客への通知状況、次回の確認日時。
• サポート担当者が誤って金銭取引を実行するのを防ぐために、返金、交換、住所変更、補償請求に必要となる承認。

プッシュとポーリングは相互検証が必要

DHL Shipment Tracking Unified Pushは、追跡IDまたはアカウント単位で購読できるプッシュ型の更新を提供しますが、利用可否は運送会社、アカウント、地域、商品によって異なります。Webhookでポーリングは減らせますが、順序が入れ替わって届いたり、重複したり、一時的に失敗したりすることは依然として起こります。

各イベントには冪等性キーを付与する必要があります。ソース側に安定したイベントIDがない場合は、運送会社、追跡番号、イベントコード、イベント日時、所在地を組み合わせて、監査可能なフィンガープリントを生成できます。受信側のエンドポイントは、非同期処理の前に生のイベントを保存する必要があります。つまり、成功レスポンスを返しても、業務上のアクションが完了したことにはなりません。ポーリングタスクは、取りこぼした更新を補完し、配送中、停滞中、配達済みの荷物ごとに異なる頻度を適用します。

FedExのドキュメントでは、業務上必要な頻度でのみ照会し、配達済みの荷物はバッチ追跡から除外することが推奨されています。プロダクトのコストは、API単価に加えて、追跡中の荷物のライフサイクル、ポーリング量、Webhookのカバー範囲、履歴の保持期間によって決まります。全注文を30秒ごとにポーリングするようなリフレッシュ頻度をリアルタイム機能とみなすと、クォータを浪費し、ソースの利用規約に違反するおそれがあります。

顧客通知はすべてのスキャンではなく、アクションに絞る

施設でスキャンされるたびに通知を送ると、ノイズが増えます。顧客が重視するのは、運送会社による荷物の引き受け、配達予定日の大幅な変更、必要なアクション、配達のための持ち出し、一部の荷物の配達完了、すべての荷物の配達完了です。通知ルールでは注文単位で更新を集約し、2つの荷物が同じ1分間に更新されても重複したメッセージが送られないようにします。

例外通知では、判明している事実、不明な点、次のステップを伝えるべきです。たとえば、「1点の商品が住所の問題で保留中のため、運送会社の公式ポータルで確認してください」と伝えるほうが、「異常が発生しました」という一般的な通知よりも行動につながります。住所変更リンクや支払い依頼には、フィッシングのリスクを抑えるため、検証可能なドメインを使用する必要があります。

社内のサポート担当者は、個人データの保護を維持したうえで追加の詳細を閲覧できます。DHLのUnified Trackingユーザー向け手順には、追跡情報の適法な利用、承認、データ保持、表示に関する条件が定められています。プロダクトは連携前に実際の契約内容を確認し、追跡番号があるというだけで物流データを恒久的に集約したり、広告に利用したりしないようにする必要があります。

地図アニメーションではなく、例外キューのMVPから始める

初期バージョンでは、1つのストア、2社の運送会社、直近の配送中の注文を対象にできます。サポートのチケットシステムと連携する前に、注文と荷物の紐付け、イベントの重複排除、ステータスのマッピング、配達日の変更、発生頻度の高い3種類の例外を検証します。地図上の軌跡、予測モデル、すべての運送会社への対応は後回しにできます。

受け入れ指標には、ソースイベントの遅延、不明ステータスの割合、例外検知までのリードタイム、重複通知率、担当者による一次対応時間、注文あたりの顧客問い合わせ件数、交換や返金の承認ワークフローが含まれます。監査では、配達済みステータスが一部の追跡番号だけでなく、すべての荷物に対応しているかどうかも確認してください。

サイト内の在庫補充プロダクトの手法は出荷前の供給と調達を、APIの自己修復ガイドはソースの障害を扱います。物流例外プロダクトは出荷後のイベントを起点に、顧客への連絡と問題解決チケットの対応を完結させます。

本記事は、EveryInfraが物流追跡プロダクトをリリースしたことを意味するものではありません。軌跡データの商業的な価値は、運送会社の8種類の輸送ステータスを同じ青色で表示することではなく、実際のどの荷物に問題が起きたかをシステムが識別し、次のステップを適切な担当者に振り分けることにあります。