ホームブログリソース発送通知を自動化する方法：トリガー、チャネル、テンプレートを6つのステップで

発送通知を自動化する方法：トリガー、チャネル、テンプレートを6つのステップで

17TRACK

配送通知を自動化するには、配送イベントを注文記録に紐付け、どのステータス変更でメッセージを送るかを定義し、許可された配信チャネルを選択して、各トリガーにテンプレートを割り当てます。その後、リリース前に重複防止、例外処理、テストを追加します。以下の6つのステップでは、ECチームが、繰り返しや誤解を招くアラートを送信せずに顧客へ役立つ更新情報を提供するワークフローの構築方法を説明します。

6つのステップで配送通知のトリガー、チャネル、テンプレートを自動化する方法

このガイドは、販売事業者、EC運用チーム、購入後のコミュニケーションを担当する開発者を対象としています。まずは、配送業者による受付、配達中、配達完了、そして顧客の対応が必要な例外など、信頼性の高い少数の通知から始めることをおすすめします。その他のメッセージは、明確に異なる顧客の疑問に答える場合にのみ追加してください。

1. 追跡イベントを正しい注文と受取人に紐付ける

配送ラベル、配送業者のスキャン、顧客への通知は、それぞれ異なるものです。ラベルを作成しただけでは、配送業者が荷物を受け取ったことにはなりません。自動化では、最初からこの違いを維持する必要があります。

まず、通知の判断を担うシステムを特定します。店舗の通知ワークフロー、追跡アプリケーション、または注文管理システムに接続されたサービスなどが考えられます。複数のシステムが同じ更新情報を個別に送信しないよう、メッセージの種類ごとに1つの担当システムを割り当ててください。

実装方法として、次の2つが実用的です。

  • アプリベースの設定：すべての連携を構築せずに、対応イベントと顧客向けメッセージを設定したい場合は、EC追跡アプリケーションを使用します。Shopifyの販売事業者にとって、17TRACKアプリの掲載ページは、配送追跡と通知ワークフローを評価するための適切な出発点です。ルールを設定する前に、具体的なトリガー、チャネル、カスタマイズ options、プラン要件を確認してください。
  • APIベースの設定：配送イベントを既存の注文システムやカスタムメッセージワークフローに連携する必要がある場合は、追跡連携を使用します。17TRACK Tracking APIと公式ドキュメントは、実装時の参考資料です。使用する連携について、イベント配信の仕組み、ペイロードフィールド、認証、再試行動作を確認してください。追跡データの受信と顧客メッセージの送信は、別々の責任です。

どちらの方法を選ぶ場合も、各配送を正しい注文と受取人に紐付けます。役立つ内部記録には、次の情報が含まれます。

  • 注文番号と配送識別子。
  • 追跡番号と配送業者識別子（利用可能な場合）。
  • その配送に含まれる商品（特に分割注文の場合）。
  • 顧客の連絡先、言語、タイムゾーン、チャネル設定。
  • 最後に受け付けた配送ステータスとイベント発生時刻。
  • 各メッセージがどの配送に関するものかを含む通知履歴。

イベントの発生時刻と、システムが更新情報を受信した時刻は分けて管理してください。遅れて届いたスキャンを、新しい顧客アラートとして自動的に扱うべきではありません。また、サポート担当者が不明確なイベントを調査できるよう、正規化したステータスとともに配送業者の元の説明も保存してください。

2. 意味のある配送変更を反映するトリガーを定義する

トリガーは、すべての新しい追跡記録ではなく、顧客に関係する変更を表す必要があります。複数の施設スキャンがすべて「輸送中」を意味することもあります。それぞれについて通知を送ると、顧客の意思決定に役立たないノイズが生じます。

受信イベントを、理解しやすい少数のステータスにマッピングします。以下の表は、すべての配送業者に共通するステータス辞書ではなく、推奨ワークフローです。

トリガー送信条件メッセージの目的
ラベル作成任意。準備と配送業者による保管を区別する。追跡情報の準備ができたことを説明する。
配送業者による受付配送業者が荷物を受け取ったことを示す対応イベントがある。配送が配送業者のネットワークに入ったことを確認する。
輸送中任意のマイルストーン。繰り返される通常スキャンは抑制する。スキャンごとの情報ではなく、意味のある進捗を提供する。
配達中受信ステータスがこの解釈を明確に支持している。顧客が荷物を受け取る準備をできるようにする。
配送例外重要な問題または必要な対応が特定されている。問題と、次に役立つ手順を説明する。
配達完了配送業者がこの配送の配達完了を報告している。報告された結果を確認し、問い合わせ方法を提供する。

例外は通常のマイルストーンより慎重に扱います。配達失敗、通関問題、住所の問題、差出人への返送イベントには、それぞれ異なる案内が必要になる場合があります。イベントから顧客が何をすべきか分からない場合は、解決策を勝手に作らないでください。

「最近更新なし」のルールでは、全配送に共通する間隔ではなく、サービスと経路に適したしきい値を設定します。スキャンがないことは、荷物を紛失した証拠ではありません。不確実なケースは社内の確認キューに回すか、判明している事実を正確に説明する中立的な更新を送信してください。

配達予定日と配送ステータスは分けて管理します。信頼できる情報源がある場合にのみ予定日を含め、それが予定であることを明示し、業務上保証できない計算上の約束で欠落データを置き換えないでください。

3. チャネルを選択し、連絡ルールを設定する

利用できるからという理由ではなく、メッセージと顧客の希望に適しているからチャネルを使用します。メールは詳細な更新情報の実用的な出発点です。時間が重要な対応には、より即時性の高いチャネルが役立つ場合がありますが、許可、プロバイダーのルール、地域の要件が認める場合に限ります。

  • メール：注文情報、追跡リンク、分割配送の説明、サポート案内に適しています。プレーンテキスト版を含め、モバイル表示を確認してください。
  • SMS：許可されている場合、短く行動につながるアラートに便利です。送信者を明示し、メッセージを簡潔にして、不要な注文情報の露出を避けてください。
  • プッシュ通知：顧客がアプリを利用し、通知を有効にしている場合に適しています。一般的なホーム画面ではなく、該当する配送にリンクしてください。
  • メッセージングアプリ：顧客がすでにそのチャネルを利用しており、実装がプラットフォームの許可要件とメッセージ要件を満たす場合に検討します。
  • 追跡ページ：詳細を確認する参照先として使用します。外部通知を補完しますが、顧客が対応する必要がある場合のアラートに置き換わるものではありません。

チャネル間の関係を文書化します。たとえば、通常のマイルストーンにはメールを使用し、対応が必要な配送問題には許可されたモバイルチャネルを使用できます。すべてのイベントを、利用可能なすべてのチャネルから自動的に送信しないでください。

静穏時間の処理と代替チャネルの方針を設定します。一時的なメール送信失敗によって、SMSの送信が自動的に許可されるべきではありません。チャネルを切り替える前に、適切な連絡先と許可があること、別のシステムがすでにメッセージを送信していないことを確認してください。

配送更新は業務上必要な内容に保ちます。宣伝内容を追加すると、適用される規則上のメッセージの扱いに影響する可能性があります。米国では、FTCのCAN-SPAMガイダンスが、商業的内容と取引上の内容を組み合わせた場合、メッセージの主目的が重要であると説明しています。注文に言及するすべてのメッセージが商業メール要件の対象外になると考えないでください。

4. 明確なフォールバック動作を備えたテンプレートを作成する

各テンプレートは、「何が起きたか」「この配送にとって何を意味するか」「顧客は次に何をすべきか」という3つの質問に答える必要があります。データがない場合に壊れたプレースホルダーを残すのではなく、きれいに消えるよう条件付きフィールドを使用してください。

以下の例は開始用テンプレートです。角括弧内の変数は例示であり、特定のプラットフォームのテンプレート構文ではありません。

配送業者受付メール

件名：注文 [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. 完全な利用経路をテストしてから段階的に開始する

テストメールが正しく見えるかどうかだけでワークフローを評価しないでください。失敗ケースを含め、配送イベントから顧客の受信先までの全経路をテストします。

  • 通常の経路：受付、輸送中、配達中、配達完了によって、意図したメッセージが生成される。
  • イベントの重複：同じイベントを再生しても、別の通知が作成されない。
  • 順序が前後したイベント：配達完了後に遅れて届いた輸送中スキャンが、古いアラートを発生させない。
  • 分割注文：各メッセージが正しい配送を示し、すべての商品が到着したと誤解させない。
  • フィールドの欠落：名前、配送業者、予定日、商品一覧がない場合でも、読みやすいフォールバック文を生成する。
  • 連絡制限：ワークフローがチャネル設定、抑制ルール、設定された静穏時間を尊重する。
  • 配信失敗：無効なアドレス、プロバイダーエラー、再試行が、制御不能な再送を起こさず追跡可能な結果を生成する。
  • 顧客の対応：すべての追跡リンクとサポートリンクが、モバイルで意図したページに到達する。

まずは限られた配送グループから開始し、追跡履歴とともにメッセージ履歴を確認します。顧客が受け取った内容をサポートスタッフが確認できるようにしてください。配送追跡自体を無効にせず、問題のあるルールを停止できる一時停止機能を用意します。

通知対象資格、送信試行、プロバイダーによる受理、失敗、重複、イベント受信からメッセージ送信までの遅延を監視します。プロバイダーが受理したことは顧客がメッセージを読んだことを意味せず、開封率だけでワークフローが役立ったとは判断できません。

顧客への影響を評価するには、一貫した定義と比較可能な配送グループを用いて、配送関連の問い合わせ率を比較します。通知による変化だと判断する前に、配送業者の構成、配送問題、注文量の変化を考慮してください。

FAQ

ラベルが作成された時点で発送確認を送るべきですか？

ラベル作成の更新を送信することはできますが、正確に説明してください。配送情報の準備ができたこと、または配送準備中であることを伝えます。配送業者による保管を確認する表現は、それを裏付けるイベントがある場合に限って使用してください。

API連携なしで配送通知を利用できますか？

はい。アプリベースのワークフローでは、インターフェースを通じて接続と通知ルールを処理できます。選択した設定で利用できるイベント、チャネル、テンプレート制御、例外処理を確認してください。既存システムに特別なルーティングや判断ロジックが必要な場合は、カスタム連携の方が適しています。

各配送は何件の通知を受け取るべきですか？

一律の理想的な件数はありません。明確で役立つマイルストーンと、対応が必要な例外から始めてください。繰り返される輸送中スキャンは抑制し、顧客が必要とする情報を提供する場合にのみメッセージを追加します。

追跡情報の更新が止まった場合はどうすべきですか？

配送が紛失したと判断するのではなく、サービスに適した確認ルールを適用します。最後のイベント、利用可能な配達予定日、関連する業務プロセスを確認してください。確認済みの情報や役立つ次の手順を追加できる場合にのみ、顧客へ更新を送信します。

配達完了通知でサポートケースを自動的に終了できますか？

配達完了スキャンでケースを更新することはできますが、顧客からの未着申告を自動的に解決済みにしてはいけません。配送業者の配達ステータスと顧客の問題を別々の記録として扱い、調査プロセスに従ってください。

Sources