シナリオ：eコマースストアの導入

概要

e-コマースという用語は、販売者と購入者がオンライン・マーケットプレイスを使用して商品とサービスを売買することに同意するビジネス・モデルを指します。 通常、この取引は、コンピューター、タブレット、スマートフォン、およびその他のデバイスなどの電子メディアを使用して行われます。 オンライン・ショッピング・セグメントは新しい概念ではありません。 人気は引き続き加速しており、現在ではショッピングのための「go-to-method」の一つとなっている。

この市場部門で利用できる商品やサービスの種類は無限にあります。 電子機器、書籍、食料品、ファッション、家具、その他すべての消耗品など、ブリック・アンド・モルタル・ストアで見られるほとんどすべての商品をオンラインで発見することができます。 現在では、サービスは一般的なオンライン・ショッピング体験でもあり、ショッパーは e-コマース・トランザクションの一部として、レッスン、コンサルティング、またはアドオン・サービスを予約することができます。

e-コマースの利点

セラーは、オンライン・マーケット・スペースをホストするサーバーのクラスターを立ち上げるために、より多くのリソースに投資する必要があります。 ただし、オンライン・スペースは、ブリック・アンド・モルタル・ストアに必要な投資と比較して、サーバー・サイトがホストされている場所に物理的な制約を課しません。 また、売り手は、買い物客のための十分なスペースを確保できるかどうかを心配する必要もありません。 物理的な制約がないと、オンライン・マーケットプレイスに入ることができるショッパーの数は、そのセラーのオンライン・マーケットプレイスがショッパーによって容易に発見される場合、実質的に無限で拡張性の高いものになります。

運用コストを考慮すると、物理的なブリック・アンド・モルタル・ストアのセットアップと比較して、サーバー・ハードウェアの保守コストは最適化されています。 どの店舗の場所でも成功が確実ではないことを考えると、オンライン・ストアフロントをホストするための費用は明らかに経済的で、スケーラビリティーの面で非常に柔軟性があります。

e-コマースの課題

新しいオンライン・ストアフロントに大量のオンライン・ショッパーが表示されることは確かに利点ですが、2 つのビジネス上の課題が存在します。 まず、ショッピング・サイトが存在することをショッパーに認識させる必要があります。 第 2 に、ショッパーのシームレスな商品検索エクスペリエンスを促進する必要があります。 同種商品の検索では、ほとんどのオンライン・ショッパーは、必要な商品を見つけるために Web サイトに入り込む忍耐力がありません。 これらのショッパーは、検索の最初の 30 秒以内に商品を見つけることができないと、失望します。 専門商品またはブランド商品の場合、ショッパーは通常、もう少し永続性があります。 このショッパーは、必要なものを検索するのにより多くの時間を要し、代替手段を見つけるためにのみ別のオンライン・ストア・サイトに移動します。

オンライン・ショッパーのドロップ率は、オンライン・マーケティング・ファネル全体にわたり、商品検索から始まり、商品詳細ページ、カート・ページ、チェックアウト・ページ、および販売オーダーを移動します。

この図は、e-コマース・コンバージョン・ファネルの概念を示しています。これは、オンライン・ショッパーが望むものを素早く表示することで、ショッパーの保持の重要性を強調しています。

前の図に示されている売上コンバージョン率は、式の半分にすぎません。 e-コマース・セラーは、商品を履行できるかどうかについても対処する必要があります。 フルフィルメントを確保するために、セラーは、フルフィルメント・ネットワーク全体に十分な在庫またはキャパシティーが存在する場合にのみオーダーが受け入れられることを確認する必要があります。 そうしないと、オーダーが履行されない可能性があり、セラーのブランド・レピュテーションが損なわれ、ショッパーの信頼レベルが低下します。 販売者がその日に履行できるアイテムのみに表示を制限し、商品の配達日に関する透明性を提供することで、プラスのショッピング・エクスペリエンスをさらに向上させることができます。 セラーは、事前購入キャプチャー・プロセスの早い段階で、商品のソース・ロケーションとショッパーが選択した運送会社サービスを認識することで、より深い洞察を得ることができます。

配信オプションの設定

e-コマース販売の初期段階では、ほとんどのショッピング体験には、ショッパーのドアに直接出荷された商品が含まれていました。 買い物客が次世代のEコマース体験に注目するにつれ、好みの配送方法も定まってくる。 これらの優先フルフィルメント方法には、出荷、ストアでのオーダーのピックアップ、カーブサイド・ピックアップ、キオスクからのピックアップなどがあります。 これらのフルフィルメント方法のそれぞれが、セラーの複雑さを増します。 セラーは、商品を出荷するだけではなく、商品をショッパーのピックアップに使用できるようにするために、フルフィルメント・コストを考慮する必要があります。

良好なショッピング体験を実現するための主な要因

顧客体験を向上させるために必要ないくつかの重要な要因を以下に示します。

Sterling Intelligent Promising が e-コマースの成功を加速する方法

e-コマースの人気が高まる中、 Sterling Intelligent Promising の主な目的は、セラーの e-コマースの変革を加速することです。 この変換は、構成時間の最小化と、e-コマース・フルフィルメント・ワークフローをサポートするための柔軟なツールの提供という、2 つの主要な製品側面で促進されます。 Sterling Intelligent Promising は、フロントエンド・ストア・キャプチャー・アプリケーションではなく、アイテムをいつどこで販売できるかを決定する重要なフルフィルメント・ツールです。 この情報により、ショッパーは、バックオーダー・イベントのリスクが最小限に抑えられるため、ストア・サイトで自信を持ってオーダーを行うことができます。

Sterling Intelligent Promising は、以下の要因を使用して、リアルタイムのフルフィルメント見積もりを提供できます。

Sterling Intelligent Promising は、以下のステップで構成されるエンドツーエンドの e-コマースの注文前および注文後のキャプチャー・ワークフローをサポートすることもできます。

Sterling Intelligent Promising を使用した e-コマース・ショッピング・エクスペリエンスの向上

e-コマース・ワークフローを実装するには多くの方法がありますが、 Sterling Intelligent Promising では、オンライン・マーケットプレイスでの顧客体験を向上させるために約束 API をどのように使用できるかについて、以下のガイドラインを提供しています。

製品の検索

商品検索は、セラーが提供する商品カタログのサイズに基づいて、さまざまな方法で実装できます。 これを実装する最も簡単な方法は、ショッパーがジーンズなどの商品カテゴリーを選択し、商品リスト・ページにリダイレクトして商品のリストを表示できるようにすることです。 対照的に、大規模な組織では、多くの場合、複数のセラーまたは大規模なカタログが関与します。 このシナリオでは、表示される商品のリストをショッパーが絞り込むのに役立つ、オンライン・マーケットプレイスでの複雑な検索機能が必要になる可能性があります。

お客様のアプローチにかかわらず、セラーにとって最も困難な作業は、即時の可用性または短期のデリバリー・ウィンドウのいずれかを持つ製品のみに製品を絞り込むことです。 ショッパーが商品を検索し、最初のいくつかの検索結果にリストされている各商品が使用できないことに気付くと、エクスペリエンスが低下します。 このフィルタリングされていない行動は、ブランドおよびショッピング体験全体に悪影響を及ぼします。 したがって、最初にリストされたアイテムが最も高い優先順位である以下の順次基準に基づいて、商品リストに優先順位を付ける必要があります。

最も重要な基準は、製品の納期と製品の納期です。 商品の格付けが 100% であっても、配達日と在庫状況の日付がショッパーの期待値と一致しない場合、セラーはショッパーが希望する日付に確実に配達することはできません。 そのため、最適ではない検索結果を検索システムで除外する必要があります。

EC事業者は、商品カタログに基づいて毎日の検索インデックスを作成し、指定された納期内に配送可能な在庫商品のみが対象となるようにすることができます。 このフィルタリングにより、買い物客は常にすぐに購入できる商品を確認できるようになります。 この動作をサポートするために、セラーは Calculate item delivery date API を利用して、最も早い納期または日付によるオーダーのリストを事前計算することができます。 その後、セラーは、日次検索索引が作成されるときに、その情報をフィルター基準として使用することができます。 検索索引は事前にコンパイルされているため、 Calculate item delivery date API には、将来の期間に基づいて配信日を見積もるための参照時間の概念が用意されています。 たとえば、明日検索インデックスを実装する予定の場合、インデックスを事前に構築できるように、システムは明日の時刻を基準としてAPI Calculate item delivery date を起動する必要があります。

Calculate item delivery date API について詳しくは、 アイテムの配達予定日を参照してください。

Calculate item delivery date API の応答時間は高速ですが、セラーがページのロード時に配信日を検索することはお勧めできません。 Web サーバーは、ショッパーのエクスペリエンスに影響を与える可能性がある、より多くのフィルタリングおよびランキング・ロジックを実行する必要があります。 シームレスなショッピング体験を提供するために、商品検索の全体的な応答時間を改善するために、事前に配送予定日の事前計算を実行します。

スケーラビリティーとパフォーマンスをさらに向上させるために、セラーは分散ストア Web サーバーを使用し、各 Web サーバーが中央サーバーではなくローカル検索索引を処理することをお勧めします。 Sterling Intelligent Promising a は、多数の並行トランザクションとほとんどのフルフィルメント要求のみの照会をサポートしますが、ローカル索引キャッシュをデプロイすると、見積もり要求の数が最小化されます。 また、ローカル索引は、カートへのアイテムの追加、数量の変更、およびトランザクションのチェックアウトなどの重要なトランザクションのみに要求を制限します。

この図は、ショッパー検索索引ワークフローの単純な構造を示しています。

検索ページのコンポーネント

これらのコンポーネントは、検索ページを作成するために使用されます。

「製品リスト」ページ

商品リスト・ページには、商品の検索結果に基づいて、お勧め商品のリストが表示されます。 ページには、リスト・ビューまたはグリッド・ビューで商品が表示される場合があります。 通常、e-commerce ストア・サイト全体で同じタイプのビューが使用されます。 ショッパーはオンラインで商品と対話できないため、セラーは、リスト内の各アイテムの配達日を表示することによって、この不可能に対する補償を行うことができます。 配送予定日は、商品の待機が許容されることをショッパーに納得させるのに役立ちます。

商品リスト・ページのアイテムごとに、セラーは最も早い配達予定日を表示し、その配達日を満たすために商品をいつオーダーする必要があるかを示すことができます。 これらの日付を表示すると、ショッパーが商品を購入する際の緊急性が分かります。 配送予定日が表示されている場合、セラーは、標準配送やエコノミー (無料) 配送など、複数の配送グループの配送日付を表示できます。

配送グループは、ショッパーが使用できる配送オプションであり、配送予定日を指定します。 セラーは、e-コマース Web サイトでオプションとして提供できる 1 つ以上の配送グループを構成できます。 通常、出荷グループは、配達までの指定された日数を満たす 1 つ以上の運送会社サービスで構成されます。 セラーは、配送速度または契約配送コストによって運送会社サービスを編成できます。 運送会社サービスについて詳しくは、「 運送会社サービス」を参照してください。 出荷グループについて詳しくは、「 出荷グループ」を参照してください。

このイメージは、商品リスト・ページのセクションを示しています。このセクションには、出荷グループの配達日と、時間別オーダーおよびピックアップ・オプションが表示されています。

セラーは、 Calculate item delivery date API を使用して、2 つのサンプル配送グループ (Standard およびエコノミー・プラス) の配送情報の見積もりを取得できます。 配送予定日は、配送グループおよびアイテムごとに 2 つのキー値を返します。最も早い配送日と、オーダーを発注する必要がある日付です。

セラーは、各アイテムの輸送期間を表示することもできます。 この代替方法は、アイテム配達日の計算 API に含まれています。

例

2 つのドレスが複数のサイズで使用可能な場合、これらのドレスはバリエーションのあるアイテムとも呼ばれます。 各バリエーションには、固有の在庫管理単位 (SKU) ID があります。 バリエーションのあるアイテムは、1 つ以上のモデルまたはサイズで構成される販売不可の親アイテムです。 各子アイテムは、独自の在庫を持つ販売可能単位です。 親アイテムを使用すると、セラーは同じ設計またはモデルを持つ SKU のコレクションを容易に追跡できます。 例えば、小サイズの赤色のドレスと中サイズの赤色のドレスは、それぞれ SKU が異なります。 出荷情報を正しく表示するために、セラーは、各 SKU の最も早い配達日や最も早いオーダーの日付など、いくつかの情報を必要とします。

この例では、赤いドレスには 2 つのサイズがあり、セラーは 2 つの配送速度を提供します。 表示された情報を取得するには、セラーは、それぞれの子 SKU および出荷グループに対して以下の 4 つの API 要求を行う必要があります。

次に、結果セットがセラーの Web サーバーによって絞り込まれ、ドレス・サイズの中から最も早い日付が導出されます。 対照的に、バリアントを持たないアイテムの場合、セラーは出荷グループごとに 1 つの API 要求のみを行う必要があります。

バリエーションのあるアイテムの数によって複雑さが増します。 リアルタイムの見積もり呼び出しの数を最小限に抑えるために、セラーは配信情報を Web 索引キャッシュの一部として保管することをお勧めします。 この方法では、ページのロードごとに情報を再計算することなく、情報をすぐに使用できます。 ほとんどのショッパーが必要とするのは、商品リスト・ページでのおおよその配送見積もりのみです。 ショッパーが商品詳細ページに到達すると、より正確な見積もりが表示される可能性があります。 この戦略は、セラーの Web サービス負荷とショッパーのエクスペリエンスの両方に役立ちます。

詳しくは、 Calculate estimated item delivery APIを参照してください。

「商品詳細情報」ページ

このイメージは、出荷グループの見積もりおよび使用可能なピックアップ・オプションを表示する、商品詳細ページのセクションを示しています。

カートに追加

ショッパーは、後でアイテムをチェックアウトまたは購入できるように、カートにアイテムを追加します。 カートへの追加はコミットされていない購入であるため、セラーは通常、ビジネス・ルールを使用して、チェックアウト・プロセスが終了するまでアイテムが使用可能であることを保証します。 これらのルールは、短期間のアイテムの「ソフト予約」を保証しますが、その期間を超えるとカートの放棄と見なされ、アイテムの予約が解放されます。 他のセラーは、チェックアウト・フェーズの前にのみ、このステップを省略してアイテム予約をキャプチャーすることを選択できます。

分配グループは、市場のターゲット・リージョンまたはセグメントに寄与する出荷ノードの論理コレクションです。 セラーは、単一の出荷ノードにアドレッシングする代わりに、その地理的地域に基づいて分配グループを参照することができます。 例えば、「東海岸グループ」などです。 分配グループは、ネットワークとも呼ばれます。

コミットされていない状態のアイテムの場合、セラーは、より柔軟にネットワーク・レベル (分配グループ) の予約を行うことができます。 ネットワーク・レベルで予約を行うと、アイテムは短期間予約されますが、出荷ノードには明示的に適用されません。 この方法でも、セラーは、分配グループ内の少なくとも 1 つの出荷ノードでアイテムが使用可能であることを確認できます。 ただし、ノード・レベルの予約は、ノードで使用可能な在庫から差し引かれるため、推奨されません。これは、他のショッパーのアイテムの全体的な在庫状況レベルに影響します。

セラーは、 Create Reservation APIを使用してネットワーク・レベルの予約を行うことができます。 ネットワーク・レベルでアイテムを予約するには、Web サービスが分配グループ ID を渡す必要があります。 ノードで予約するために、セラーは出荷ノード ID を渡します。 予約が行われるときには、指定された期間 (5 分など) が経過した後に予約の有効期限が切れるように、セラーに期限切れまでの時間コンポーネントを含めることをお勧めします。 予約の有効期限が切れると、予約済みの数量が可用性プールに戻され、予約は自動的にキャンセルされます。 セラーは、要求ごとに Web サーバーが期間をハードコーディングする必要がないように、デフォルトの予約有効期限を設定することもできます。 デフォルトの予約有効期限は、 Update settings APIを使用して設定できます。

このイメージは、要求された数量が使用可能な在庫より大きい場合の警告メッセージの例を示しています。

カート

ショッパーがストア・サイトをブラウズすると、アイテムがカートに追加されます。 多くの場合、カートに追加されたアイテムは相互に類似しているか、関連アイテムであるため、ショッパーはチェックアウト前にそれらのアイテムを比較し、商品の選択を絞り込むことができます。 商品に加えて、ショッパーは、使用可能な数量と、各カート明細の配達を受け取るまでの時間に関心がある場合があります。 ショッパーは、各カート明細の配達予定日を表示することにより、どのアイテムを希望するかを簡単に比較できます。 例えば、ショッパーがブルー・ドレスとレッド・ドレスのどちらを選択するかを決定するユース・ケースなどです。 赤のドレスが明日に到着し、青のドレスが 2 週間後に到着した場合、セラーはスケジュールされたニーズに基づいて赤のドレスを選択します。

商品詳細ページとは対照的に、カートとの違いの 1 つは、各カート明細がアイテムの数量で構成されていることです。 Calculate item delivery date API は、単一の可用性および有効なキャパシティー・ウィンドウを考慮するため、カート明細の正確な見積もりを提供することはできません。 このため、 Sterling Intelligent Promising には、このユース・ケースをサポートするための Calculate checkout assignments API が用意されています。 この API は、要求された数量の出荷速度に基づいて最も早い配達日を決定するために必要な複雑な計算に対応します。 セラーは、同じカート明細のアイテム数が増加すると、全体の配達日が変更される可能性があることに気付くかもしれません。 日付が変更される可能性があるのは、各出荷ロケーションにすべての要求数量があるわけではないか、または出荷可能日が異なる可能性があるためです。

セラーは、各カート明細の配送予定日を表示することをお勧めします。 その後、ショッパーは個々のカート明細を比較して、どのアイテムが配達承諾基準を満たしているかを判別することができます。 一部のセラーは、ショッパーが最初から何を求めていたかを正確に把握しているという前提で、すべてのカート明細を見積もりに含めることができます。 このユース・ケースは、カタログが小さく、主にフラグシップ・アイテムまたは限定的な商品選択を提供するセラーに適しています。

カート見積もりの場合、セラーは、商品詳細ページに表示できるものと同様の情報を表示することを選択できます。 この情報には、出荷速度と関連付けられた最も早い配達日、および近くのストアでアイテムをピックアップできる最も早い日付が含まれます。

このイメージは、使用可能な在庫を超える要求を含むカート・ページの例を示しています。

配信情報の見積もりを取得するには、 Calculate shipment assignments APIを使用します。 Calculate shipment assignments API は、最も早い配達見積を提供し、カート明細項目の要求された数量全体のアカウントを提供します。 この API は、ネットワークで履行できないバックオーダーまたは数量に関する情報も返します。 このため、セラーは、数量が完全であるかどうかを事前に確認し、バックオーダー金額をショッパーに報告する必要があります。 この通信により、ショッパーは、オーダー取得フェーズに移行する前にフルフィルメントできない数量を認識することができます。

この見積もりは、 Calculate item delivery date API と Get node availability by dates APIの組み合わせを使用して導き出すこともできます。 予定配達日は、報告された最も早い配達日を満たすフルフィルメント出荷ノードも提供します。 この情報を使用することにより、セラーは Get node availability by dates API を使用して、ターゲットの出荷ノードで使用可能な数量を識別できます。 アイテムの在庫しきい値に基づいて、セラーは、アイテムの在庫状況が限定されていることを示す短メッセージを表示して、バイヤーに早期に購入するよう促すことができます。

チェックアウト

ショッパーがショッピング・カート内のアイテムのリストを完成させた後、カートをチェックアウト・フェーズに転送できます。 チェックアウト時に、ショッパーはカートの最終レビューを行います。これは、複数のカート明細とアイテム数量で構成されます。 ショッパーがアイテムの購入にコミットされる可能性が高いため、セラーはカート全体の配送見積もりを提供する必要があります。 この配達見積により、ショッパーは、アイテムの全体的な配達日を認識することができます。

カート・ページとチェックアウト・ページの違いは、カート・ページには、フルフィルメント見積もりを取得するために一緒に考慮されるすべてのカート明細が含まれていることです。 複数のカート明細と複数の数量が一緒に考慮される場合、在庫状況が低いときに、カートに分割出荷が必要になる可能性があります。

チェックアウト・ページで、ショッパーは、希望する配送速度、配達方法、およびフルフィルメント・プリファレンスを選択できなければなりません。 ショッピング・エクスペリエンスがさらに強化されるのは、セラーが、カート・アイテムおよび数量の正確な配送見積もりを提供することにより、ショッパーにコミットメントの感覚を提供する場合です。 フルフィルメント・プリファレンスは、セラーによって事前定義することも、ショッパーのオプションとして提供することもできます。 フルフィルメント・プリファレンスは、ショッパーが配達済みアイテムを受け取る方法を示します。例えば、すべてのアイテムが一緒に配達されたり、使用可能になるとすぐに配達されたりします。 「最も早い配達」とは、アイテムが使用可能になるとすぐに出荷ノードから出荷されることを意味します。 一括配達とは、すべてのカート・アイテムが同じ最も早い配達日に到着するようにスケジュールすることを指します。

コスト・ベースの有望な商品によって、ショッピング体験はさらに充実したものになる。 売り手は、正確な配送見積もりを提供できるだけでなく、最も低い総合コストで注文を満たすことができるようになった。 買い物客は、フルフィルメント・オプションとしてコスト最適化を適用を選択することができます。 買い物客がこのオプションを選択した場合、販売者はカート商品の配送を約束し、購入ごとの配送割り当てを計算することで、サービス全体のコストを最小限に抑える。 購入者が「 コスト最適化オプションを適用」を選択した場合、 「Get Optimized Checkout Plan (Pre-Purchase) 」APIは、カートの配送日を算出する際に、サービス提供コストを最小限に抑えるよう考慮します。 コストベースの約束に関する詳細については、 「コストベースの約束」 を参照してください。

「Get Checkout Shipment Plan」 は、カートの最短配送日を算出する際、これらの要素をすべて考慮に入れています。

カートページと同様に、販売者は、購入者が在庫不足を把握できるよう、チェックアウトプロセスの早い段階で Get Checkout Shipment Plan (Pre-Purchase) APIから報告されたバックオーダー数量を確実に反映させる必要があります。 このコミュニケーションにより、負のフルフィルメント体験を最小化できます。

このイメージは、出荷とピックアップの間の配達方法に基づく配達日と明細の内訳を含む出荷グループを示すチェックアウト・ページを示しています。

「Get Checkout Shipment Plan（購入前）」 APIは、購入者が必要とする主要な情報をサポートするために、以下の情報を返します。

カートまたはカート行の商品は、複数の配送に分割される可能性があります。そのため、「Get Checkout Shipment Plan」の購入前レスポンスには、最も早い配送日と最も遅い配送日の両方が含まれます。 このため、セラーは両方の値を使用することも、最も早い配達日のみを使用することもできます。 後者のシナリオでは、配達明細が出荷詳細ページに表示されます。

ピックアップ・オプションをサポートする予定のセラーは、カートを 2 つの異なる要求に分割する必要があります。1 つは出荷配達方法用、もう 1 つはピックアップ配達方法用です。 「Get Checkout Shipment Plan」 では、同一のリクエスト内で受け取りと配送を組み合わせることはできません（購入前段階では未対応です）。 ピックアップの性質は、最後の 1 マイルの配達を含まないため、出荷とは異なります。 また、ほとんどのセラーは、ショッパーの優先ストア・ロケーションに基づいて在庫状況日を発行します。 例えば、ショッパーのカートが 1 つの出荷明細と 1 つのピックアップ明細で構成されている場合、セラーは、出荷とピックアップの間でカートを明示的に分割する必要があります。 このようにして、配信方法ごとに分離された要求を行うことができます。

この例では、カートはピックアップと出荷に分割されます。

販売者は「 Get Checkout Shipment Plan（購入 SHIP1 前のカート）」を利用しています。 カート PICK1 行については、販売者は Get network availability by date API を呼び出して、選択された出荷ノードの在庫可能日を取得し、指定された店舗の在庫を確保する必要があります。 この段階では、販売者は「 Get Checkout Shipment Plan（購入前 API）」によって提供される割り当てられた出荷ノードに対して予約を行うことで、「確定予約」を行いたいと考えるかもしれません。

ユーザーが支払いを行い、チェックアウト・トランザクションを完了すると、セラーは、 Order Management System またはチェックアウト・プロセスからのレコード要求を使用してオーダーを作成できます。 この例では、カート明細 (SHIP1 および PICK1) ごとに 1 つずつ、2 つの需要がチェックアウト・プロセスで作成されます。 PICK1 シナリオの場合、セラーは、需要要求の出荷日としてショッパーのピックアップ日を使用する必要があります。 詳しくは、 出荷の詳細の確認を参照してください。

出荷の詳細の確認

ショッパーがチェックアウト・フローの最終ステージ (支払キャプチャーなど) に入ると、セラーはカート明細の出荷明細を表示することをお勧めします。 この出荷の内訳は、配送予定のパッケージ数をショッパーが把握するのに役立ちます。 フルフィルメント・プリファレンスによっては、複数の出荷が存在する場合があります。

カートに複数のカート明細があり、それぞれにさまざまな数量がある場合、ショッパーはセラーから複数のパッケージを受け取る可能性があります (特に、それらが異なる出荷ノードからのものである場合)。 以下に、出荷の内訳のシナリオ例をいくつか示します。

• 1 つのカート明細は、1 つの出荷で 1 つの出荷ノードによって履行されます。
• 複数の数量を持つ 1 つのカート明細を、異なる出荷ノードから異なるパッケージで出荷することができます。
• 複数のカート明細で 1 つの出荷を共有できます。
• 複数のカート明細で複数の出荷を共有して、完全な要求数量を満たすことができます。 例えば、 Line1 と Line2 は、可用性スケジュールに基づいて Shipment1 と Shipment2 を共有できます。

この例では、出荷ノードの在庫状況が限られているため、 Sterling Intelligent Promising は、最も早い配達フルフィルメント・プリファレンスに基づいてカートを 2 つの出荷に分割することで、在庫状況を最適化します。 各出荷は、出荷に割り当てられている数量を示します。

ショッパーがオーダーを確認する前に、セラーは、チェックアウトが完了するまで簡単な在庫予約を作成する必要があります。これにより、在庫が別のプロセスによって消費されることはありません。 上記のイメージは、現在のチェックアウト画面の有効期限が切れるまでの時間も示しています。 有効期限が切れた後、セラーは、新規予約を作成して予約を更新する必要があります。 いずれかの要求アイテムに不足がある場合、その数量が使用できなくなったことがショッパーに通知されます。

オーダーが確認された後、セラーには、オーダーを取得するための以下の 2 つのオプションがあります。

• 「Get Checkout Shipment Plan（購入前） 」で提供される割り当て（コミットメント日、出荷拠点、運送業者サービスを含む）を使用してください。
• Order Management System を使用して、コミットされた配達日をメモし、ショッパーに提示されたとおりに表示されるようにします。

「Get Checkout Shipment Plan（購入前 ）」で提供される割り当て機能を利用するには、販売者は以下のすべての手順を実行する必要があります：

1. 割り当てられた数量および出荷ノードの割り当てに対して、 Adjust Demand API を使用して在庫需要を作成します。
2. この API を使用して予約を取り込み、予約 ID を渡します。
3. 割り当てられた出荷ノードで運送会社サービスを使用して、フルフィルメント要求を処理します。 セラーは、外部統合ソリューションまたは Order Management System を使用して、出荷ノードのタスクおよび操作を管理できます。

使用されている方法に関係なく、配送日がショッパーに提示されているため、この日付が確約日になります。 セラーは、顧客の不満を避けるために、この日付に違反していないことを確認する必要があります。 この確約日はデリバリー・ベンチマークとして使用されますが、セラーはこのデータを使用して、より多くの需要がシステムに到着する際にフルフィルメント最適化の別の層を実行することもできます。 このようにして、セラーは、すべてのノードにわたって最適な出荷バランスを達成することができます。 カート明細が出荷ノードに割り当てられている場合でも、配達日が維持されていれば、セラーは、低コスト・オプションの出荷ノードおよび運送会社サービスの割り当てを変更できます。

特定の在庫要件に対応したタグ対応チェックアウト

タグ識別子を使用するタイミング

タグ付きとタグなしのチェックアウトリクエスト

応答には、トレーサビリティのためのタグ識別子が含まれています

例：特定の修正要件を持つVIP顧客

batchNo: "VIP-PREM"
lotNo: "LOT-B"
revisionNo: "REV-2"

このAPIは、タグ付けされていない在庫100単位や小売業者固有の在庫など、その他のすべての在庫を無視し、VIPバッチからのみデータを取得します。 この応答により正確な識別子が確認されるため、倉庫が正しい製品をピッキングし、顧客が互換性のあるハードウェアのバージョンを受け取ることが保証されます。

フルフィルメントの正確性への影響

詳細については、 「シナリオ：特定の在庫要件に合わせたタグ対応のチェックアウト割り当て」 を参照してください。

約束サービスの前提条件チェックリスト

Sterling Intelligent Promising が正しく機能していることを確認するために、 IBM では、テナント・アカウントについて以下のすべての構成データが存在することを確認することを推奨しています。