前提条件
  • Genesys Cloud CX 1、Genesys Cloud CX 2、またはGenesys Cloud CX 3ライセンス
  • いずれかに割り当てられた次の権限ユーザー 役割 ：
    • 建築家>UI(UI)>表示
    • 建築家> 流量>追加、表示、編集、削除
    • 言語理解 > すべて
    • 言語理解>マイナー>追加、削除、実行、アップロード、表示
    • 言語理解>マイナーインテント>表示 。
    • 知識 >> 全て
    • 分析 >> 知識集約 >> 全て
    • Analytics >Bot Flow Session >View 

この包括的なガイドでは、Architect ダイアログ エンジンのボット フローを使用してボットを準備および実装するプロセスについて説明します。 価格、適切な前提条件、および権限について学習します。 Architect での設計プロセスおよび Bot 作成について理解する。 その後、ボットを完了、維持、強化する方法を学びます。

ボットの概要

顧客とコミュニケーションを取るための会話ツールとしてボットを使用します。 ボットは自然言語理解(NLU)と人工知能(AI)を使用します。

ボットには、その知性を左右するさまざまなレベルのインテリジェンスがあります。 基本的な質問と回答のボット、またはより高度な会話型ボットを実装して、会話の方向を制御し、顧客に選択の柔軟性を提供することができます。 作成する Bot は、顧客とのやり取りの方法、Bot が提供するサービス、提供するカスタマー エクスペリエンスの種類によって異なります。

Architect ダイアログ エンジンのボット フローを使用してボットを構築するための環境を準備する

このセクションでは、価格の詳細、適切な許可、Architect のダイアログ エンジンのボット フローを使用したボット構築の基本概念について学習します。

価格

Genesys Cloud の購読者は、Architect の Genesys ネイティブ Bot フロー構築ツールである Architect Dialog Engine を、Genesys AppFoundry(Genesys AppFoundry). Dialog Engine ボット フローの料金は、ボットの会話が音声またはデジタル チャネルのどちらで行われるかによって異なります。 数量割引については、カスタマーサクセスマネージャーまたは営業担当者にお問い合わせください。 

  • Genesys は、ダイアログ エンジンのボット フローが実行される 1 分ごとに 15 秒単位で音声チャネルで会話を課金します。
  • Genesysは、セッションごとにデジタル(チャットおよびメッセージングチャネル)で会話をチャージします。 各セッションには、ボットの会話に最大 8 つのダイアログ ターン、またはリクエスト応答ペアが含まれます。 ボットの会話に 8 ターン以上ある場合、Genesys は 8 ターンのグループごとに追加のセッションを課金します。

必要な権限

組織の適切なメンバーに、次の権限がユーザーの役割に割り当てられていることを確認します。

  • 建築家>UI(UI)>表示
  • 建築家> 流量>追加、表示、編集、削除
  • 言語理解 > すべて

詳細については、以下を参照してください。 Architect 権限の概要.

構築プロセスを開始する前に、Architect のダイアログ エンジンの概念と機能を理解することが重要です。 

もっと詳しく知る：

Architect のダイアログ エンジンの Bot フローで Bot を構築

このセクションでは、Architect ダイアログ エンジンを使用してボットをデザイン、作成、および保守する方法について説明します。これには、以下のプロセスが含まれます。 検出、構築、トレーニング、テスト、起動、最適化、保守。

検出フェーズでは、ボット ビルダー、ビジネス アナリスト、開発者、エージェント、製品マネージャが協力して、範囲と初期基準を決定します。 これらの役割は柔軟性があり、組織によって重複したり、組み合わせたりする場合があります。 この図は、組織のニーズに合わせてカスタマイズできる、発見プロセスの側面を概説しています。

発見フェーズを完了する際、次のコンセプトについて考えてください。

なぜボットを構築する必要があるのですか?

  • ボットはNPSを増加させ、顧客の待ち時間を次のように短縮します。
    • 顧客の要望に迅速に対応する。
    • 顧客を正しいセルフサービスプロセスに接続することで、封じ込め率を改善します。
    • ファーストコンタクトの分解能と転送速度の向上 代理人に上申すること。
  • ボットは、顧客がメッセージングを行う理由を特定するなど、日常的なタスクを実行することでエージェントの処理時間を短縮します。
  • ボットは時間外サービスの可用性を高め、ピーク時に簡単に拡張できます。

発見フェーズを終えて、ボットを構築する準備が整いました。

ボットはどのように機能しますか?

まず、ボットは顧客の意図を特定する必要があります。 たとえば、ユーザーは何を求めているか? 何かを注文したり、質問をしたり、情報を得たりしますか? この目標を達成するために、ボットは、発話と呼ばれるユーザーから重要な情報を探します。 発話は、ユーザーの意図を示す言葉やフレーズです。 各発話には、番号、肯定的または否定的な回答などのスロットまたはキーワードが含まれます。

スロットは動的です。つまり、同じ発話でも異なるスロットを持つことができます。 たとえば、「チキンタコスが欲しい」、「ビーフタコスが欲しい」などです。 各スロットには、事前定義されたスロットタイプが含まれています。 このスロット タイプは、スロットに含まれる情報のタイプを定義します。

Architect ダイアログ エンジンに内蔵スロット タイプが含まれている; たとえば、タコスの数、カスタムスロットタイプを作成できます。; タコフィリングなど。

例

あるお客様が「チキンとワカモレのタコスを注文したい」と言い、ボットが意図とスロットを1回転でいっぱいにします。 あるいは、お客様が「タコスを注文したい」と言うかもしれません。 次に、ボットは「どのようなフィリングを希望しますか?」と尋ね、スロットを完成させて顧客の意図を決定します。

ボットが顧客の意図を特定したら、適切に対応します。 ボットは学習によって、たとえば、顧客が求める前に充填を推薦したり、顧客が求めるものを決定したり、顧客にアップセルするなどすることができます。

画像をクリックして拡大します。

検出フェーズは通常、次の主要なアクションで構成されます。

  • ボットのビジネスメリットの測定基準と成功基準を定義します。
  • 意図を定義する。
  • オプションで、ボット フローのスケッチを作成できます。
  • ボットとの対話中にユーザーが遭遇する可能性のある問題領域を特定します。

発見フェーズを終えて、ボットを構築する準備が整いました。

画像をクリックして拡大します。

構築フェーズの主なステップには、次のアクションが含まれます。

  • 意図、発話、スロットなど、ボットの自然な言語理解の側面を構築します。 このステップでは、プロセスのガイドとして、ハイレベルな情報しか作成できません。 たとえば、2 つの発話を含む 1 つの意図で開始します。 
  • ボットフローを構築します。 たとえば、ボットが「AppDate」スロットと「AppTime」スロットで「予約予約」インテントに遭遇した後に予約を検索するためのデータアクションを構築します。

もっと詳しく知る：

ボットを構築したら、トレーニングとテストの準備ができました。

ボットビルダーは通常、ボットのトレーニングとテストを監督します。 しかし、一部の企業では、スピーチサイエンティストがこのプロセスの管理を支援するという利点があります。 

画像をクリックして拡大します。

このステップでの重要なアクションは次のとおりです。

  • 意図と発話でボットをトレーニングします (このステップでは、意図ごとに約 20 ～ 30 のトレーニング発話など、完全な構成があることを確認します)。
  • 意図と発話をテストし、ボットのパフォーマンスを最適化し、修正後に再トレーニングします。
  • 全体的な Bot フローをテストします。

もっと詳しく知る：

このプロセスが完了したら、ボットの品質保証テストを実行する準備が整います。

組織の品質保証チームは通常、ボット ビルダーや場合によってはエージェントから提供された情報に基づいて、このステップを実行します。

画像をクリックして拡大します。

このステップでの重要なアクションは次のとおりです。

  1. ユーザーインタラクションをシミュレーションし、ユーザーエクスペリエンスを確認
  2. 構成済みの目的をテストし、Bot スロットの精度を確認します。 特に音声の場合は、テスターが設定された言語と一致していることを確認してください。
  3. エンド・ツー・エンドのフロー・テストを実行します。

ボットの品質保証テストプロセスがあるかもしれません。 その場合は、確立された品質保証方法に従ってください。 

もっと詳しく知る：

完了すると、ボットを起動する準備が整います。

このステップには、通常、ボット構築プロセスに既に関わっている組織のメンバーが関係します。 プライマリ Bot ビルダーが通常、その役割を果たします。 また、このプロセスは「本稼働」ステージでもあります。

画像をクリックして拡大します。

このステップでの重要なアクションは次のとおりです。

  • ボットの起動の成功を評価し、必要に応じてロールバックして必要な変更を加えます。
  • 利用者のジャーニーと意図とスロットの精度について監視されるライブのユーザーインタラクションを監視します。
  • ボットの問題を特定し、必要に応じて修正を実装します。

ライブの顧客の発話は、 [学習]タブ.

意図、発話、およびスロットのパフォーマンスを測定するために、組織ですでに別のレポート機能が確立されている場合があります。 今後の Architect ダイアログ エンジンの反復には、レポート機能が含まれます。

ボットを起動し、リアルタイム シナリオで実装した後、ボットを最適化するためのデザイン拡張を実行できます。

もっと詳しく知る：

ボット ビルダーは通常、この手順を実行しますが、一部の組織ではスピーチ サイエンティストを採用しています。 通常、ボット最適化調査は、ボットが稼働してから数週間後に行われます。

画像をクリックして拡大します。

このステップでの重要なアクションは次のとおりです。

  • 利用者のジャーニーと意図とスロットの精度について監視されるライブのユーザーインタラクションを監視します。
  • ボットの問題を特定し、必要に応じて修正を実装します。
  • 意図、発話、スロットを微調整します。
  • レポートを分析します。
     メモ：   意図、発話、およびスロットのパフォーマンスを測定するために、組織ですでに別のレポート機能が確立されている場合があります。 今後の Architect ダイアログ エンジンの反復には、レポート機能が含まれます。

    ボットの定期的なメンテナンスチェックを定期的に実行します。

    メンテナンス

    通常は、ボット ビルダーとプロダクト マネージャーがこの手順を実行します。 ボットのメンテナンスが進行中です。

    画像をクリックして拡大します。

    このステップでの重要なアクションは次のとおりです。

    • 定期的にユーザー・エクスペリエンス、意図、スロットの精度をチェックします。
    • ボットの問題を特定し、必要に応じて修正を実装します。
    • 将来のプロジェクトの候補者を特定する。
    • レポートを分析します。
       メモ：   意図、発話、およびスロットのパフォーマンスを測定するために、組織ですでに別のレポート機能が確立されている場合があります。 今後の Architect ダイアログ エンジンの反復には、レポート機能が含まれます。