> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/bijinesusbisu/zoom-contact-center/expert-insights/engagement-brief-hero-use-cases.md). # エンゲージメント概要ヒーローのユースケース ## 概要 Engagement Brief は、顧客エンゲージメントが終了した後に Zoom コンタクトセンターが作成する AI 生成のドキュメントです。自動生成するように設定することも、エージェントが手動で起動することもできます。Engagement Brief は、会話の文字起こし、共有メディア、セッションのメタデータを構造化された共有可能なレコーディングに要約します。これにより手作業のメモ取りが不要になり、Engagement Brief はあらゆるやり取りのための決定版レコーディングシステムになります。 ## 前提条件 ### Zoom コンタクトセンター パッケージ要件 Engagement Brief を生成するには、エージェントに Zoom コンタクトセンターのユーザーアカウントへ Elite パッケージが割り当てられている必要があります。この要件は、会話中に複数のエージェントが関与していた場合でも、エンゲージメントを終了するエージェントにのみ適用されます。 {% hint style="info" %} 覚えておいてください。Engagement Brief は、エンゲージメントを終了するエージェントのアカウントに Elite パッケージが割り当てられている場合に、エンゲージメント終了時点で生成されます。 {% endhint %}
## 設定と使用方法 Engagement Brief 機能を設定する方法と使用する方法の詳細な説明は、このドキュメントの範囲外です。 {% hint style="info" %} この機能を設定する方法と使用方法については、以下のリンクからオンラインで利用できるヘルプセンターのドキュメントを参照してください。 * [Zoom コンタクトセンター Engagement Brief の有効化](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085600\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953) * [Zoom コンタクトセンター Engagement Brief の生成](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085601\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953) {% endhint %} ## 追加の考慮事項 ### 変数 エンゲージメントの終了時に、会話の文字起こしは、Zoom コンタクトセンターのグローバル変数とカスタム変数を含む他のエンゲージメントメタデータとともに処理のために送信されます。Engagement Brief が生成される際には、変数の内容も考慮されます（たとえば、変数に顧客のアカウント番号や保険証券番号が含まれる場合があります）。 モデルが変数の目的を理解できるようにするには、変数に意味のある名前と説明を付けることが重要です。最良の結果を得るには、一般的すぎる、または曖昧な変数名の使用を避ける必要があります。 {% hint style="info" %} 変数の設定はこのドキュメントの範囲外です。詳細については、以下からオンラインで利用できるヘルプセンターの記事を参照してください [このリンク](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0059058\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953). {% endhint %} エンゲージメント後処理の条件を満たすには、変数は次の条件を満たす必要があります： * STRING、メール、またはURL型であること。 * 機密データをマスクするように設定しないこと。 Engagement Brief を生成する際、最大50個の変数がエンゲージメント後処理に含まれます。 ### テンプレート Engagement Brief テンプレートは、エンゲージメント後に AI が概要を生成する際に使用する構造とセクションを定義します。テンプレートは、Zoom 管理ポータルのコンタクトセンター管理 → アセットライブラリ → Engagement Brief テンプレート に移動して、アセットライブラリで設定します。
#### 設計ガイドライン 最良の結果を得るには、次の設計原則に従うことをお勧めします： * テキストと見出し（H1〜H4）を組み合わせて、セクション階層を定義します。 * エンゲージメントの内容に基づいて AI が入力できる説明テキストフィールドを使用します。 * 生成された概要でフィールド名と内容を明確に分けるため、各フィールドの末尾には終端文字を付け、その後にスペースを入れます（例：「: 」）。 * フィールドは簡潔に保ち、指示文ではなく説明的な表現を使用してください。たとえば、「お客様の感情:」を「お客様がどのように感じたかを記述してください。」の代わりに使用します。 {% hint style="info" %} 定義したヘッダーは、生成された概要にそのまま表示されます。 {% endhint %} #### 例 以下は、Engagement Brief が生成される際に AI が明確に識別できる説明フィールドが H1 見出しの後に続く 3 つのセクションからなる、シンプルな例です。
## ユースケースの例 次の2つのシナリオは、Engagement Brief がエージェントとその組織に即時かつ具体的な価値をどのように提供するかを示しています。 ### 技術的トラブルシューティング: エンタープライズソフトウェアサポート #### シナリオ エンタープライズソフトウェアプラットフォームを利用しているビジネス顧客が、ベンダー側のプラットフォーム更新後に API 連携が失敗したため、技術サポートに連絡します。ビデオ通話は約25分に及びます。サポート担当者は、設定の確認、API エラーコードの確認、サンドボックス環境での失敗の再現、そして最終的には更新によって導入された権限ポリシーの競合の特定まで、一連の診断手順を体系的に案内します。 セッション全体を通じて、消費者はビデオチャットでエラーのスクリーンショットを共有し、詳細なログファイルを提供します。通話の終了時点でサポート担当者は解決に至っていますが、このやり取りには、ケース管理、フォローアップ、今後のナレッジベース活用のために正確に記録する必要がある、バージョン番号、エラーコード、設定パス、5つの異なるトラブルシューティング手順といった詳細な技術情報が大量に蓄積されています。 #### Engagement Brief テンプレート 以下は Markdown 形式のテンプレート例で、この例を再現するために engagement brief テンプレートにコピー/貼り付けできます。 ```plaintext # エンゲージメントの詳細 - 時刻と日付: - 顧客名: # 顧客の問題 - 問題の説明: # 情報の記録 - エラーコード: - 設定の詳細: - トラブルシューティング手順: # 解決 - 問題は解決しましたか？ - もしそうなら、解決策は何でしたか？ - 次への手順: # 得られた教訓 - 記録された知識: ``` #### 通話文字起こしのサンプル |

\[00:00]顧客: こんにちは。API連携について通話しています。昨夜のプラットフォーム更新が適用された直後、今朝から動作しなくなりました。

\[00:38]担当者: こんにちは。それは残念です。こちらでお客様のアカウントを確認できます。エラーが発生しているAPIエンドポイントを教えていただけますか？

\[01:05]顧客: /v2/messages/send エンドポイントです。403 Forbidden が返されています。今からエラーの画面ショットをお送りします。

\[01:40]担当者: 画面ショットを受け取りました。ありがとうございます。403 を確認できます。通常、OAuth スコープの問題を示しています。現在、アプリにどの OAuth スコープが認可されているか確認していただけますか？

\[03:10]顧客: チャット:write、チャット:read、users:read があります。これまでもずっとこれで、今朝までは問題なく動作していました。

\[03:45]担当者: 承知しました。昨夜の更新で、メッセージ送信エンドポイント向けに新しい権限モデルが導入されました。現在は、チャンネルには チャット:write.public、DM には チャット:write.direct が必要です。従来の チャット:write スコープは廃止予定です。移行ガイドへのリンクをチャットで共有します。

\[05:20]顧客: はい、リンクを確認できました。では、新しいスコープでアプリを再認可する必要がありますか？

\[05:38]担当者: そのとおりです。手順をご案内します。まず、開発者ポータルに移動してください。ご案内できるよう、共有画面をしていただけますか？

\[06:00]顧客: もちろんです。共有画面を開始しました。

\[14:50]担当者: いいですね。新しいスコープが一覧に表示されているのが確認できます。「アプリを再インストール」をクリックし、OAuth フローを進めてください。完了したら、もう一度エンドポイントにリクエストを送ってみてください。

\[17:30]顧客: できました！200 レスポンスが戻ってきました。本当にありがとうございます！

\[17:45]担当者: よかったです！解決内容をケースに記録します。影響を受けるエンドポイントがあと 2 つあります。チャット:write.public と reactions:write です。6月30日に廃止される前に、それらを確認することをお勧めします。お送りするケース概要にすべて記載します。

\[24:10]顧客: 完璧です。とても丁寧に対応していただき、ありがとうございます！

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | #### エンゲージメント概要のサンプル この概要サンプルは、このユースケース内で詳述されているテンプレートと会話に基づいて生成されました。 {% file src="/files/0cbd1b39165fa7e0b6664eae382510ed047b6117" %} #### エンゲージメント概要が役立つ仕組み このように技術的な内容が豊富なサポート対応では、通常、サポート技術者にとってドキュメント作成の負担は大きなものになります。対応を終えた後、キューを管理しながら、次の情報を思い出してレコーディングする必要があります。 * 正確なエラーコード * 実施したトラブルシューティング手順 * 必要な具体的なスコープ変更 * やり取りしたリンク * 6月30日にフラグが付いたフォローアップ項目 Engagement Briefは、会話全体の文字起こし、セッション中に共有されたスクリーンショットとログファイル、そしてZCCのセッションメタデータを構造化されたドキュメントにまとめることで、この負担を軽減します。その結果できあがるBriefには、問題の説明、解決までの経路、次のアクション、そしてやり取りのタイムラインが記録されます。これは、上司が監査に必要とする情報、同僚が後続チケットを引き継ぐために必要な情報、またはナレッジベース管理者が再利用可能な解決記事を作成するために必要な情報そのものです。サポート技術者は、通話の間ずっとお客様に集中でき、終了時にやり取りを記録することを気にする必要がありません。 ### 予約受付: 自動車サービスセンター #### シナリオ 車のオーナーが自動車サービスセンターのカスタマーサービス窓口に連絡し、オイル変更とブレーキ点検を含む定期メンテナンスをスケジュールします。担当者は、こうした通話を毎日何十件も処理します。受付プロセスは構造化されていますが、細かな項目が多いです。担当者が収集しなければならないのは次の内容です: * お客様の氏名と連絡先情報 * 車両のメーカー、モデル、年式、現在の走行距離、VIN * 依頼されたサービスを確認する * 空き状況を確認する * お客様が言及したリコール通知など、関連する履歴を記録する 通話の শেষে、担当者は社内サービス注文フォームを完成させ、予約内容の書面による確認をお客様に送付する必要があります。これを各通話ごとに手作業で行うのは時間がかかり、文字起こしエラーのリスクも生じます。VINの誤りや入力ミスの電話番号は、サービス当日に遅延を引き起こす可能性があります。 #### Engagement Brief テンプレート 以下は Markdown 形式のテンプレート例で、この例を再現するために engagement brief テンプレートにコピー/貼り付けできます。 ```plaintext # 顧客詳細 - 顧客名: - 連絡先情報: # 車両情報 - 車種: - 車両年式: - 現在の走行距離: - 車両識別番号: # サービス詳細 - 依頼されたサービス: - 希望の予約枠: - 関連履歴: ``` #### 通話文字起こしのサンプル |

\[00:00]担当者: 自動車サービスセンターにお電話いただきありがとうございます。本日はどのようなご用件でしょうか？

\[00:06]お客様: こんにちは。オイル交換をスケジュールして、ブレーキ点検もお願いしたいです。軽いきしみ音が聞こえる気がしていて。

\[00:18]担当者: もちろんです！手配できます。まず、お名前とご連絡先番号を教えていただけますか？

\[00:24]お客様: はい、ソフィアです。番号は 415-555-0192 です。

\[00:35]担当者: ありがとうございます。では、お車の年式、メーカー、車種を教えてください。

\[00:40]お客様: 2021年式の Camry SE です。

\[00:46]担当者: 承知しました。現在の走行距離は、おおよそどのくらいでしょうか？

\[00:50]お客様: 約 38,500 マイルです。

\[00:54]担当者: ありがとうございます。VIN はお手元にありますか？フロントガラスの近く、ダッシュボードでも確認できます。

\[01:10]お客様: はい、4T1B11HK0MU512347 です。

\[01:22]担当者: ありがとうございます、確認できました。ではサービス内容ですが、スタンダードの合成油オイル交換と、ブレーキの総合点検です。さらに、燃料ポンプモジュールの未対応リコールもあります。今回の訪問でそちらも対応しますか？費用はかかりません。

\[01:42]お客様: えっ、それは知りませんでした。はい、それもお願いします。

\[01:48]担当者: かしこまりました。今週土曜日の午前9時か11時に空きがあります。どちらがよろしいですか？

\[01:55]お客様: 午前9時で大丈夫です。

\[02:00]担当者: 承りました。2021年式 Camry SE、VIN 4T1B11HK0MU512347 で、土曜日午前9時のご予約を確定しました。サービス内容は、合成油オイル交換、ブレーキ点検、燃料ポンプモジュールのリコール修理です。まもなくメールとテキストで確認をお送りします。ほかにお手伝いできることはありますか？

\[02:18]お客様: いいえ、以上です。ありがとうございます。

\[02:22]担当者: どういたしまして。土曜日にお待ちしています！

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | #### エンゲージメント概要のサンプル この概要サンプルは、このユースケース内で詳述されているテンプレートと会話に基づいて生成されました。 {% file src="/files/11e197cd58f5a4751c9f092fd5722a86f20cf8f7" %} #### エンゲージメント概要が役立つ仕組み このような高頻度の受付ワークフローでは、わずかな非効率でもすぐに積み重なります。Engagement Brief がなければ、担当者は通話から VIN、走行距離、サービス内容、予約枠、リコールコードなどのあらゆる詳細を手作業でサービスオーダーフォームに転記し、その後でお客様への確認を作成して送信しなければなりません。文字起こしのミスが起こるリスクは現実的であり、そのプロセスは通話の合間の時間を削ってしまいます。 Engagement Brief があれば、これが変更されます。通話が終了すると、Engagement Brief は 文字起こし と ZCC 変数から直接取得した、お客様の連絡先情報、車両情報、依頼されたサービス、予約詳細をあらかじめ入力した構造化されたドキュメントを生成します。担当者は内容を確認して正確性をチェックし、必要であれば簡単に編集してから対応を終了できます。 内部のサービスオーダーは、担当者が次の通話を受ける前に実質的に完了しています。週に何百件もの予約を処理する中で、時間短縮の効果は大きく、データ入力ミスの削減は、お客様のサービス当日の体験をよりスムーズにすることに直結します。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/ja/bijinesusbisu/zoom-contact-center/expert-insights/engagement-brief-hero-use-cases.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.