トランザクションの会話の設計（Dialogflow）

取引フローでユーザーを案内する会話を設計します。ここで説明するサンプルは、独自の取引アクションを設計する際のガイドとして利用できます。

例

設計のヒント

  • 対話が自然な会話に聞こえるように設計します。実際に人が話しているようにします。

  • TTSまたは音声で話されているテキストは、チャットのふきだしに表示されるテキストと完全に一致する必要はありません。チャットのふきだしが音声対話の補助になれば問題ありません。

  • 訪問者に挨拶して、会話に参加させましょう。訪問者が何を必要としているかを尋ね、いくつかの候補ワードを提示します。

  • カートに商品を追加するよう指示する前に、actions.intent.TRANSACTION_REQUIREMENTS_CHECK を使用してユーザーが Google アシスタントに支払情報を設定していることを確認します。

  • モバイルやウェブの場合と同様に、さまざまな問題に対処できるよう準備します。たとえば、指定されたサイズや色がない場合に類似の商品を提案する、在庫が補充されたときに通知を受け取れるようにユーザーに登録を促す、といったことが考えられます。

  • 注文概要は、API を介して渡されたデータで作成されます。[Google でお支払い] ラベルは、Google が支払いを行っていることをユーザーに示すものです。

  • 自宅の住所などの情報をユーザーから収集する場合は、こうした情報が必要な理由や情報を提供するメリットについて説明します。

  • Google は、ユーザーの設定に基づいて購入承認方法（認証不要、パスワード、指紋など）を提示します。リスク アセスメントのため、カードの CVV を確認するような認証ステップを行うこともあります。

  • 支払いが完了したら、必ず領収書と注文確認書を送付してください。販売の最終責任者が Google ではなく自分であり、注文に対するフォローアップを行うことをユーザーに通知する必要があります。

  • デフォルトでは、画面表示が使用できるサーフェス（Android スマートフォンなど）または音声のみのサーフェス（Google Home など）のいずれでも取引を実行できるようになっています。

    • 音声のみの取引を効果的にサポートするため、取引をスムーズに完了できるように優れた会話を設計する必要があります。

    • 取引のインテントによっては画面が必要になることがあります。たとえば、新しい配達先の追加、支払情報の修正、アカウント リンクなどでは画面が必要になります。そのような場合は通常、会話が自動的にスマートフォンに転送されます。画面に表示することが望ましいコンテンツ（たとえば、カード作成のためのリッチ レスポンスの提示、加盟店の利用規約またはプライバシー ポリシーの表示など）を会話に追加する場合は、現在のサーフェスが SCREEN_OUTPUT または WEB_BROWSER 機能をサポートしているかどうかを確認し、サポートしていない場合は新しいサーフェスに転送します。

    • アクションで音声のみの取引をサポートしない場合は、Actions Console で [Deploy]（デプロイ）> [Surface capabilities]（サーフェス機能）に移動して [Do your Actions require a screen output]（画面出力を必須にしますか）を [Yes]（はい）に設定することで、画面を必須にします。