ビジネス要件とストアフロントの比較

学習の目的

この単元を完了すると、次のことができるようになります。

• 実際のストアフロントと比較する必要のある内容について説明する。
  
• スケジュールへの影響に対処する最適な方法を説明する。
  
• 認証の異なる点を修正することの利点を説明する。
  
• 通常の注文手続きの 3 つの要素を挙げる。
  
• 商品タイル、商品情報、および商品情報クイックビューバージョンの違いを説明する。
  

Commerce Cloud は Agentforce Commerce、B2C Commerce は Agentforce Commerce for B2C に名称変更されました。アプリケーションやドキュメントでは、Commerce Cloud や B2C Commerce という名称が使われている場合があります。

はじめに

計画から実装まで、チームと共にここまでがんばりました。開発は完了し、テストもほとんど終わりました。いよいよ佳境に入ります。

立ち上げが近づいたタイミングで、一歩離れて結果を確認します。新しいストアフロントはマーチャントのビジネス要件を満たしているでしょうか? また、Business Manager は適切に設定されているでしょうか?

この単元では、ビジネス要件の確認を扱います。Business Manager については後で取り上げます。

ここでは、機能仕様ドキュメント (FSD) にディスカバリーフェーズで書き留められたビジネス要件を、しっかり確認する必要があります。このドキュメントと実際のストアフロントを合わせて確認して、目的を達成していることを確認します。

違いがある場合

絶対にありえないということはありません。デベロッパーとマーチャントの会話によって、ドキュメントに書き留められてない変更が生まれることがあります。たとえば、検索結果ページに、機能仕様でページネーションボタンが要求されている一方で、土壇場で要請のあった無限スクロールが適用されていることがあります。よいアイデアですが、それは変更です。この確認作業では、見つからないすべてのモジュール、項目、ボタン、およびデータについて、説明する必要があります。

それによって、立ち上げが遅れるかもしれないと思うでしょう。

落ち着いてください。スケジュールへの影響に対処する最適な方法は、違いの特定、ドキュメントへの書き出し、およびそれらを解決する計画の策定です。各項目に影響力のスコアと優先度を指定してください。

たとえば、表面的な問題によって立ち上げを中止することはありませんが、カタログフィードがない場合や、Bill Me Later および PayPal の支払方法、またはクレジットカードのセキュリティコード項目が表示されない場合は、立ち上げを中止することになります。買い物客が支払うことができなければ、物事が進みません。

立ち上げ日の遅れの必要性について説明することは難しいかもしれませんが、詳細な計画と共にきちんと説明すれば、長い目で見たときにストレスを軽減することになります。

この単元の目標は、新しいストアフロントの機能が要件を満たしているか判断する方法を学習することです。満たしていない場合、次にやるべきことがあります。

これらのエリアを確認しましょう。

• 認証
  
• ホームページおよびナビゲーション
  
• カテゴリおよび検索結果
  
• 商品タイルおよび商品情報
  
• クイックビュー
  
• 買い物カゴと注文手続き
  

認証

認証では、買い物客が自分の身元を証明します。通常、買い物客はメールアドレスかユーザー ID を入力して、パスワードを入力します。デザインを確認し、ドキュメントと比較する必要があります。

買い物客がストアフロントで次を実行できるかどうか確認することから始めます。

• アカウントを作成する
  
• アカウントにログインする
  
• アカウントからログアウトする
  

買い物客の状況によって、ユーザーインターフェースを変更しますか? たとえば、次のように表示しますか?

既知の買い物客とは、多くの場合 Cookie により、ストアフロントで特定できる買い物客を指します。ログインはまだしていません。次に考慮すべき点は、認証をストアフロントのどこで要求するか、それがドキュメントと一致するかということです。認証すべきタイミングの候補はいくつかあります。

• 買い物客がアカウント詳細にアクセスするとき
  
• 注文手続きまたは支払時
  
• 買い物客が注文ステータスを見るとき
  

ここでの違いを確認し、ドキュメントに書き出し、最終的に修正することで、強固なセキュリティにつながります。

ホームページおよびナビゲーション

ストアフロントのレイアウトをしっかり観察する必要があります。必要なホームページおよびナビゲーション要素は何ですか? 回答には、通常、次のストアフロント要素が含まれます。

• ヘッダー—すべてのページの上部のエリア。
  
• フッター—すべてのページの下部のエリア。
  
• グローバルナビゲーション—すべてのページで簡単なナビゲーションを表示するエリア (目次を含む左側のフレームなど)。
  
• ホームページ—買い物客が最初にストアフロントを開いたときに表示され、たとえば、[ホーム] をクリックしたときに表示される。
  

ヘッダー

ヘッダーは複数のユーザー向けに機能を提供します。この場合は、買い物客とマーチャンダイザーです。両方のユーザー種別のヘッダーを確認する必要があります。

次に例を示します。

ベストプラクティスは、マーチャンダイザーが Business Manager 内でヘッダー要素を変更できるようにすることです。ストアフロントコードを記述して、これらの変更を自動的に表示するべきですが、立ち上げの準備状況評価の一環として、これらの要素をドキュメントと比較する必要があります。

フッター

フッター情報は、重要であるものの、ページの下部までスクロールダウンしなければなりません。標準ストアフロントフッターには、ニュースレターサインアップリンクやサイトマップへのリンク、連絡先情報、ユーザーのアカウント、法的事項などの要素が含まれます。フッターは、すべてのページで表示し、コンテンツアセットへのリンクのみを含めるようにしてください。マーチャンダイザーが、フッターを変更することなく、リンクされたコンテンツアセットを変更できるようにしてください。

グローバルナビゲーション

グローバルナビゲーションは、ナビゲーションの階層構造における定義した数のレベル表示などの要件を満たす必要があります。これは 3 つのレベルの例です。

• Sale (セール)
  

• Boots
  

• Leather (レザー)
  
• Casual (カジュアル)
  
• 勤務先
  

ヘッダーと同じように、マーチャンダイザーは、次のような特定の要素を自動的に変更できるようにしたいと考えます。

• ドロップダウンの表示形式 (縦方向または横方向)
  
• カテゴリ属性に基づいて表示するコンテンツ
  
• カテゴリの順序
  

ヘッダーに配置するか独自のエリアに配置するかにかかわらず、キーワード検索機能はすべてのページで使用できる必要があります。

ホームページ

マーチャンダイザーがコンテンツスロット経由で、ホームページのすべてのコンテンツを変更できるようにする必要があります。このページに静的な情報は含めないでください。ここは買い物客とつながる最初の場であり、最初にマーチャンダイザーが商品を売り込むべき場です。

カテゴリおよび検索結果

カテゴリおよび検索結果ページを設計するときに考慮すべき点は次のとおりです。

• カテゴリまたは検索結果ページで想定する買い物客の体験はどのようなものか? たとえば、タイル表示からリスト表示に切り替えて戻ることを想定しているか?
  
• 複数の結果の間の改ページは、ドキュメントのとおり機能しているか? たとえばストアフロントは、無限スクロール用と、リンクまたはボタンによる移動用のどちらで設計されているか?
  
• ブレッドクラムは適切に機能するか? 想定している動作をあらゆる面から確認します。たとえば、ユーザーパスを表示するか? パスから「ホーム」を除外するか?
  

商品タイル、詳細、およびクイックビューの比較

商品情報は、商品タイル、商品情報ページ、またはクイックビューウィンドウによって、異なって表示されます。それぞれに独自の用途とサイズ制限があります。

各種類の表示を確認する必要があります。

この表は SFRA に基づくサンプルですが、実装や設計によって異なることがあります。ここで確認すべきその他の項目には、モバイルでの動作が含まれます。たとえば、クイックビューはモバイルデバイスでは使用できません。

買い物カゴと注文手続き

買い物カゴページや注文手続き時に表示すべき情報は何ですか? まず、買い物カゴの話から始めましょう。

買い物カゴ

買い物客が購入したすべての項目が、正しいサイズ、色、および数量でストアフロントに表示されるか確認します。項目を編集して、購入を続けるために戻れるようになっていますか?

また買い物客が、ゲストユーザーまたはログインユーザーとして、クーポンコードを入力して、注文手続きに進めるようにしてください。

注文手続き

他のストアフロントの機能以上に、注文手続きは基盤となるデバイスに対応して、デバイスの機能を最大限活用し、買い物客のインタラクションを促進できる必要があります。詳細は、「Salesforce B2C Commerce 機能コンサルティング戦略」モジュールを参照してください。

通常の注文手続きには 3 つの要素があります。

• 請求—指定した支払いプロセスが正確であり、必要な決済プロバイダーが含まれていることを確認します。
  
• 配送—指定した配送方法と住所検証プロセスが、すべて正確であり、機能することを確認します。
  
• 注文の確認—注文の詳細が正確であり、買い物客が新しいアカウントを作成できることを確認します。
  

注文手続きプロセス全体が正確で、円滑に機能し、可能な限り簡潔であることを確認します。注文手続き時のストレスは、買い物カゴの放棄につながります。

次のステップ

FSD と実装されたストアフロントの比較に必要な時間を取りました。流れに沿って、違いを特定し、ドキュメントに書き出し、それらを解決する計画を策定しました。各項目に影響力のスコアと優先度を指定しました。ホームページから注文手続きの商品表示まで、すべてを確認しました。

次は、ストアフロントの Business Manager 設定を確認して、すべての立ち上げ準備ができていることを確認します。立ち上げの準備状況確認も半分完了しました。凄いと思いませんか?

リソース

• Trailhead: Salesforce B2C Commerce
• Trailhead: Agentforce Commerce for B2C (マーチャンダイザー向け)