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