ホームブログBigcommerceの配送連携：料金、ラベル、追跡のオプション

Bigcommerceの配送連携：料金、ラベル、追跡のオプション

17TRACK

BigCommerceの配送連携には、チェックアウト時の配送料金計算、フルフィルメント用ラベルの購入、発送後の荷物追跡という3つの異なる役割があります。マーチャントにとって、適切な構成は必ずしもすべてを提供すると約束する1つのアプリとは限りません。チェックアウト方法、倉庫での作業、配送記録、顧客への更新情報が一貫して保たれる、連携されたワークフローです。

Bigcommerce Shipping Integrations Options for Rates Labels and Tracking

まず、現在問題が発生している配送の部分から始めましょう。チェックアウト時に予想外の料金が表示される場合は、料金設定の見直しが必要です。梱包や発送に時間がかかっている場合は、ラベルワークフローの見直しが必要です。配達状況の更新がない場合は、追跡機能の改善が必要です。これらの問題は注文データを共有できますが、1つを解決しても、他の問題が自動的に解決されるわけではありません。

各配送連携が実際に行うこと

連携を選ぶ前に、顧客向けの配送オファーと、それを実現するために必要な運用作業を分けて考えましょう。チェックアウト時の配送料金は、後でラベルに支払う金額と必ずしも同じではなく、追跡番号があるからといって、配送業者が荷物を受け取った証明になるわけでもありません。

連携レイヤー主な役割確認事項
チェックアウト料金購入者に表示する配送方法と料金を決定します。発送元、配送先、商品データ、サービス対象条件、代替動作。
ラベルとフルフィルメント注文を配送に変換し、発送に必要な書類を作成します。配送業者アカウント、荷物の選択、プリンター互換性、配送情報の書き戻し。
購入後の追跡配達イベントを収集し、配送状況を確認できるようにします。追跡番号の取得、配送業者の識別、更新情報の配信、例外処理。

BigCommerceの公式アプリマーケットプレイスは、パッケージ化された連携を探す際の出発点です。開発者向けドキュメントは、カスタム接続を検証するための出発点です。マーケットプレイスの掲載情報だけで、アプリが利用するすべての国、配送業者サービス、チェックアウト設定、フルフィルメントワークフローに対応していると判断してはいけません。

ワークフローを中心に連携方法を選ぶ

ルールが単純な場合はプラットフォームの配送設定を使用する

配送オファーが単純な場合は、まずストアで利用できる既存の配送設定を確認しましょう。別のシステムを追加する前に、配送先、購入者に表示する方法、それらの方法に適用する商業上のルールを定義します。

たとえば、国内標準配送料金を提示するストアでは、外部の料金エンジンよりも、配送ゾーンと除外条件を明確にする必要があるかもしれません。一方、複数の拠点から大型商品を発送するストアでは、別の問題が生じます。単純な料金では、フルフィルメントコストの重要な違いが隠れてしまう可能性があります。

最適な対象：荷物が予測可能で、フルフィルメントの複雑性が限定され、既存の設定で配送ルールを表現できるマーチャント。別のアプリに設定が多いというだけでなく、必要なロジックを確実に表現できない場合に、この方法から先へ進みましょう。

繰り返し行うフルフィルメント作業にはパッケージ化された連携を使用する

スタッフが住所のコピー、サービスの選択、ラベルの購入、追跡番号の入力を繰り返し行っている場合は、パッケージ化された配送連携を検討する価値があります。その価値は、引き継ぎを減らし、注文記録を実際に発送した内容と一致させることにあります。

すべてのラベル連携がチェックアウト料金も提供すると考えてはいけません。同様に、注文をインポートするアプリが配送情報をBigCommerceに書き戻せるとも限りません。プロバイダーには、利用するワークフローを使って、必要な各方向のデータ移動を実演してもらいましょう。

最適な対象：独自の連携を保守せずに、確立された運用インターフェースを求めるチーム。重要な倉庫ルールに手作業の回避策が必要で、時間短縮効果が失われる場合は適していません。

別のシステムがフルフィルメントを管理している場合はカスタム接続を使用する

注文管理システム、倉庫プラットフォーム、またはサードパーティ物流業者がすでに発送を管理している場合、カスタム連携が適していることがあります。この構成では、BigCommerceはすべての配送作業における運用上の唯一の情報源ではなく、販売チャネルとなる場合があります。

住所、荷物の決定、ラベル購入、配送作成、追跡更新のそれぞれをどのシステムが管理するかを定義します。次に、関連するドキュメントで必要なAPI操作、認証要件、権限、プラットフォーム上の制約を確認します。

最適な対象：実際のワークフロー要件があり、それを保守できる技術力を持つマーチャント。監視、サポート、将来の変更まで含めると、カスタム開発が自動的に最も安価な方法になるわけではありません。

料金：チェックアウト時の約束を配送業務と一致させる

料金連携は、単に数値を返すのではなく、実際に履行できる配送オファーを生成する必要があります。プロバイダーをテストする前に、サービス対象条件とコストを決める発送元、配送先、商品、梱包の入力情報を文書化します。

  • 発送元：どの倉庫またはフルフィルメントパートナーが注文を発送しますか？
  • 商品データ：重量と寸法は正確ですか。また単位は統一されていますか？
  • 梱包：計算では個別の商品、選択した箱、推定パッケージのどれを使用しますか？
  • 配送先：遠隔地、私書箱、サービス対象外の地域にはどう対応しますか？
  • 商業上のルール：計算された金額を請求しますか、送料を補助しますか、それともプロモーションのしきい値を適用しますか？

チェックアウト時の料金とラベルコストが異なる場合があります。これは、フルフィルメント時に使用する荷物、サービス、発送元、アカウントがチェックアウト時の想定と異なるためです。料金計算が間違っていると判断する前に、テスト注文の両方の側面を比較してください。

失敗時の動作も定義しましょう。料金リクエストが失敗した場合、チェックアウトには設定済みの代替方法を表示しますか、影響を受けた方法を削除しますか、それとも注文を停止しますか？適切な選択は、チームが代替方法を履行できるかどうかによって決まります。発送できない注文を受け付ける代替料金は、正常な復旧とはいえません。

国際注文では、輸送費と関税・税金を分けて考えます。担当するサービスが関連料金を明示的に計算し、フルフィルメントプロセスが提示された支払い方式に対応している場合を除き、料金をすべて込みの着地費用として説明してはいけません。

ラベル：発送サイクル全体を評価する

ラベル購入は、最初の印刷に成功したかどうかだけでなく、注文のインポートからキャンセルまでを通してテストする必要があります。運用上の問題は、連携によって倉庫作業とストア記録が同期され続けるかどうかです。

次の受け入れ確認を行います。

  1. 注文のインポート：正しい注文がフルフィルメントに利用可能となり、編集が予測どおり処理されることを確認します。
  2. 荷物の作成：単一荷物、複数荷物、一部の商品だけを発送する注文をテストします。
  3. サービスの選択：購入者のチェックアウト方法が、倉庫スタッフが購入するサービスにどのように対応するかを確認します。
  4. 印刷：ラベルサイズ、ファイル形式、印刷設定が実際の倉庫設備で機能することを確認します。
  5. 配送情報の書き戻し：正しい追跡情報と発送済み商品がBigCommerceの注文に反映されることを確認します。
  6. 再印刷と無効化：スタッフが重複購入を避ける方法と、未使用ラベルの処理方法を、適用されるプロバイダーのルールに基づいて決めます。

特に有用なテストは、ラベル購入には成功したものの、その後の注文更新に失敗するケースです。スタッフには、別のラベルを購入せずに注文を更新できる復旧手段が必要です。洗練されたデモと、信頼できる本番ワークフローの違いが現れるのはこの部分です。

顧客通知を誰が管理するかも確認してください。配送連携と別の接続システムの両方が発送メッセージを送信すると、顧客に重複または矛盾した更新情報が届く可能性があります。

追跡：配送記録と配達状況の可視化を区別する

注文に追跡番号を書き込むことで、記録管理の問題は解決できます。後から配送業者のイベントを収集することで、可視性の問題が解決されます。ビジネスには両方が必要かもしれませんが、それぞれを分けて評価する必要があります。

有用な追跡ワークフローでは、注文、配送、荷物、配送業者、追跡番号の関係が維持されます。1つの注文に複数の荷物がある場合や、荷物が複数の配送業者を経由する場合、この関係が重要になります。

開発者主導の追跡レイヤーとして、17TRACK Tracking APIは評価対象となる選択肢です。公式APIドキュメントは、カスタムワークフローにおける追跡登録とイベント配信を評価するための基盤を提供します。これは追跡の用途であり、チェックアウト料金の計算やラベル購入の代替ではありません。

APIが利用できるからといって、すぐに使えるBigCommerceコネクターが含まれていると考えてはいけません。ストアまたはフルフィルメントシステムから追跡サービスへ配送情報を移動する方法、更新情報を宛先へ届ける方法、接続を保守する担当者を明確にしてください。

実装前に、実際に利用する配送業者とサービスへの対応、関連するサブスクリプション条件、更新情報の配信設定を確認します。その後、スキャンの遅延、認識されない番号、重複した更新、配達例外をテストします。追跡連携は、まだ発生していない物理的な配送業者のスキャンを作り出すことはできません。

社内で追跡の担当者も決めてください。停滞した配送を調査し、配送業者または顧客に連絡するタイミングを判断する責任者がいなければ、例外ダッシュボードの運用上の価値は限られます。

表示価格だけに頼らず総コストを比較する

これらの連携レイヤーは異なる作業を行うため、単一の宣伝上のサブスクリプション料金ではなく、必要なワークフローに対してコストを比較します。

  • ソフトウェア料金：サブスクリプション、利用枠、超過料金、個別に請求される機能を確認します。
  • 配送料金：ソフトウェア料金と送料および配送業者による調整額を分けます。
  • 導入：設定、データクリーンアップ、サービスマッピング、テスト、スタッフ研修を含めます。
  • 継続的な運用：手動修正、同期失敗、サポート担当を考慮します。
  • 解約要件：未完了の注文に影響を与えずに配送記録を取得し、接続を削除する方法を確認します。

各プロバイダーに、どのイベントが課金対象の利用量として数えられるか説明してもらいます。注文、ラベル、荷物、登録された追跡番号、APIリクエストは同じ単位ではありません。コストを見積もる際は、自社業務の代表的な期間を使用します。

切り替える前に小規模なエンドツーエンドのパイロットを実施する

最も確実な選定方法は、現実的な注文を使った管理されたパイロットです。通常の国内荷物、複数商品の注文、分割配送、ビジネスに関係する国際配送または特殊な配送タイプを含めます。

各テストについて、チェックアウト時のオファー、選択したサービス、ラベルの結果、配送記録、追跡先、顧客通知を記録します。住所の拒否や同期の中断など、少なくとも1つの失敗ケースも追加します。

明確な責任分担を設定します。Eコマースチームはチェックアウト動作を承認し、倉庫スタッフは梱包と印刷を承認し、カスタマーサポートは配送状況の可視性を承認し、技術担当者は権限と復旧手順を承認します。各接続が受け取る顧客データを確認し、目的に必要なアクセスだけを付与します。

実務上の推奨：業務が許す限り、構成はシンプルに保ちましょう。要件を満たす場合は既存の配送設定を使用し、反復作業を減らせる場合はフルフィルメント連携を追加し、配送状況の可視化に独自のワークフローが必要な場合は専用の追跡レイヤーを導入します。重複する機能を当然のように購入するのではなく、各レイヤーを意図的に接続してください。

よくある質問

料金、ラベル、追跡に別々の連携が必要ですか？

必ずしもそうではありません。1つの連携が複数の機能をカバーする場合もあれば、別の連携が1つの機能だけを処理する場合もあります。注文の読み取り、配送情報の書き戻し、後続の追跡更新の配信を含め、必要な各機能を個別に確認してください。

ラベル連携によってチェックアウト時の配送料金は自動的に変更されますか？

そうとは限りません。ラベル購入はフルフィルメント中に行われますが、チェックアウト料金は注文前に提示されます。連携がチェックアウト料金機能を提供しているか、またストアの設定で機能するかを確認してください。

自分の配送業者アカウントを接続できますか？

これは連携、配送業者、アカウントの利用資格、配送地域によって異なります。対応するアカウントとサービス、自分のアカウント料金を利用できるか、送料とその後の調整額を誰が請求するかを確認してください。

17TRACKはBigCommerceのラベルツールを置き換えられますか？

Tracking APIは、ラベル購入の代替ではなく、追跡状況の可視化を目的として評価してください。カスタムワークフローによって配送情報を追跡サービスに接続し、チェックアウト計算とラベル作成は、それぞれの作業を担当するシステムに任せることができます。

追跡番号を受け取った後も、顧客の画面で配送状況が進まないのはなぜですか？

荷物が最初の配送業者スキャンを受ける前に、追跡番号が存在する場合があります。そのほか、番号の誤り、配送業者の識別問題、イベント情報の反映遅延なども考えられます。更新がないことをソフトウェアの障害と判断する前に、フルフィルメントから配送業者への引き渡しと配送業者情報を確認してください。

出典

Loading