この記事は、Finの回答問題に対する品質保証（QA）ワークフローの一環としてMonitorsを使用したいサポートチームメンバーやFinの設定・保守担当者向けです。Monitorsが会話を抽出し始めた後の対応方法、結果の解釈、人間の判断の適用、改善への転換について説明します。
セットアップ手順をお探しの場合は、Monitor setup guideをご覧ください。
注意：MonitorsはProアドオンの一部として利用可能です。
手動QAの問題点
Finの品質保証はかつて、会話の小さなサンプルをレビューし、異常と思われる点を探し、重要なパターンを見つけられることを期待するものでした。その方法は会話量が管理可能な場合には機能しましたが、現在はスケールしません。
Finは可能性を変えました。会話の一部を手動でレビューする代わりに、数千件を評価できます。問題はもはや発見することではなく、どの問題が実際に重要かを知ることです。
だからこそ、最も効果的なQAワークフローは人間のチームメンバーをAIに置き換えるのではなく、Finのパターン抽出能力と人間の判断を組み合わせてパターンを解釈し、有意義な改善に変えます。
Monitorsの仕組み
Monitorは、継続的に定義した基準に基づいて会話を評価します。これは継続的なQAのためのランダムサンプルか、低いCXスコア（Intercomの顧客体験評価）、繰り返されるエスカレーション、回答品質などのシグナルに基づくターゲット会話かもしれません。これらの会話はFin、人間のレビュアー、または両方によるスコアカードでレビューできます。
注意: スコアカードは会話を評価するための基準セットです。例えば、Finが完全な回答をしたか、適切なトーンを守ったか、適切にエスカレーションしたかなどです。
Intercomには、週次のFinレビュー、低回答品質、エスカレーション対応、ループ問題など、一般的なQAワークフローのテンプレートが含まれています。チームのニーズに合わせてMonitorsを一から作成することも可能です。
Monitorsはフィルタリング層のようなものです。膨大な会話の中から、誰かの注意が必要なものを絞り込みます。
なぜ人間のレビューが依然重要なのか
Monitorは単に会話のスコアが低いことを示すだけでなく、AI評価基準の場合は、具体的な基準とFinのスコア付けの理由まで示します。
しかし、会話間の関連付けはしません。
回答品質が低い10件の会話があり、それぞれ異なるAI生成の説明があるかもしれません。しかしよく見ると、そのうち7件は同じ古い記事に起因している可能性があります。
Finは個々の会話がなぜ低スコアかは教えてくれますが、7つの「なぜ」が実は同じ根本問題の異なる表れであることは教えてくれません。
その違いを認識するには製品知識と文脈が必要です。これは次の2つの結論の違いです：
「これらの会話は悪い結果に見える。」
「これらの会話はすべて同じ知識のギャップに起因している。」
このステップがなければQAはフラグ付けされた会話のリストになります。これがあればQAは実行可能な改善のリストになります。これがノイズと洞察の違いです。
Monitorsを使ったQAワークフローの実行方法
ワークフローは4つのステップです：
Monitorsを使ってパターンを抽出する
人間の判断を適用して実際に何が起きているか理解する
その発見を実行可能な推奨事項に変える
推奨事項を修正可能な担当者に届ける
1. Monitorsを使ってパターンを特定する
ここでMonitorsが大きな役割を果たします。会話を手動でサンプリングして有用なものを見つけるのではなく、Monitorsは基準に合うすべての会話を継続的に評価し、注意が必要なものを抽出します。
2. 文脈と製品知識を適用する
ここはFinが代替できないステップです。Monitorsは10件の会話が低スコアと教えてくれますが、それらが同じ問題の症状か、古いコンテンツが原因か、Finがもはや製品に合わないガイダンスに従っているかは教えてくれません。
その点をつなぐのは人間の製品専門家です。
3. 発見を推奨事項に変える
フラグ付けされた会話は行動項目ではありません。次の2つの結論を比較してください：
「この手順は会話を解決していない。」
「Fin Thoughts（会話のタイムラインに記録されるFinの推論）は、手順が顧客のプラン階層を適格性チェック段階で一貫して誤解し、誤った経路に進み解決に至っていないことを示しています。」
後者はチームに具体的な修正点を提供します。可能な限り、問題の症状を説明するだけでなく、問題を引き起こしている特定の記事、手順、またはFinのガイダンスルールを特定してください。
ヒント: 推奨事項は、受け取った人が問題を再発見せずに行動できるように構成してください。「請求会話の回答品質が低い」ではなく、「請求の返金記事に部分返金に関する情報が欠けており、これが少なくとも7件の最近の会話でFinが不完全な回答をする原因となっています。」と書きましょう。
4. 洞察を適切な担当者にルーティングする
洞察は誰かが行動して初めて価値を生みます。知識のギャップはhelp centerコンテンツ担当チームのものかもしれません。手順の問題はFinのガイダンスや会話設計を管理する人のものかもしれません。
すべての組織に専任のKnowledge ManagementやConversation Designチームがあるわけではありません。小規模チームでは一人が複数の役割を担うこともあります。重要なのは誰が担当かではなく、コンテンツの問題か手順の問題かを特定し、適切な改善を行うことです。
推奨事項が具体的であればあるほど、他の人が問題を再発見する時間が減り、解決に費やす時間が増えます。
これはMonitor内のIssuesを使って直接行うこともできます。
任意の会話のReviewサイドバーから、タイトル、タイプ（Content、Guidance、Procedure、Escalationなど）、担当者を指定してIssue ticketを会話を離れずに作成できます。同じ問題が複数の会話に現れた場合、同じIssueをリンクできるため、チームは会話ごとではなく根本原因ごとに1つのticketを管理できます。すべてのIssuesはFin AI Agent > Analyze > Monitorsの中央ビューに集約され、提出から解決までの状況を追跡できます。
詳細なセットアップ手順はMonitor QAレビューで見つかった問題の追跡と対応をご覧ください。
ヒント: Intercomでは、会話ノートを使って関連チームメンバーを@mentionしたり、フォローアップレビューのために会話にタグを付けて発見事項をルーティングできます。コンテンツの問題はチームのknowledge managementプロセスで直接対応し、手順やガイダンスの問題はFinの設定を管理する担当者に会話リンクと推奨事項を共有してください。
MonitorsがFinを時間とともに改善する方法
Monitorが同じ問題を繰り返し抽出する場合、それは通常、help centerの記事、Finの手順、または調整が必要なガイダンスに注意が必要な大きな問題の兆候です。
Monitorsは数千の会話からパターンを特定するのに優れていますが、どのパターンに実際に対応すべきかは教えてくれません。ここで人間の製品専門家が登場します。彼らは製品知識と文脈を使い、根本原因を特定し、発見を実行可能な推奨事項に変え、修正担当チームに確実に届けます。
Finがパターン検出に優れるにつれて、製品専門家の役割も進化します。問題を探す時間を減らし、データが示す内容を理解し、重要なことを判断し、有意義な改善を推進することに集中できます。