# 元の要望を損なわずにユーザーのフィードバックを分類する

連携済みのサポートツールやプロジェクト管理ツールからフィードバックを読み取り、関連する報告をまとめ、元の会話を残した課題の下書きを作成します。

Canonical page: https://beeuni.ai/blog/ja/group-user-feedback-with-ai

フィードバックは、サポートのスレッド、チームのチャンネル、課題管理ツールに散在しています。同じ問題が異なる表現で報告され、1つのメッセージに複数の要望が含まれることもあります。また、長いスレッドが多数の別々の苦情のように見えることもあります。

エージェントに読み取らせるサポート受信箱、チャンネル、またはプロジェクトを選び、期間とフィルターを指定します。報告を分類する前に、取得したメッセージID、元のリンク、取得時刻を保存させましょう。そうすれば、新しい返信が届いても、レビュー対象となる入力を固定できます。

```
Read last month’s conversations in the connected support inbox about booking times.
Follow the replies in each matching thread. Save the source IDs and links.
Propose groups, distinguish feature requests from reported bugs, and count distinct accounts where IDs are available.
Compare the groups with issues in the connected project tracker.
Show likely existing matches and draft new issues for review. Do not send customer replies.
```

検索結果は出発点にすぎません。前後の会話を読むと、報告されたバグがすでに解決済みだったり、顧客が要望を変更していたり、一見別々に見える2つの報告が同じインシデントに関するものだと分かったりすることがあります。レビュー用ファイルには関連する抜粋を残し、レビューに不要な連絡先情報はコピーしないでください。

## 3件のメッセージ、2つの異なる問題

スケジュール管理製品について、以下の架空の例を考えてみましょう。

| ソースID | フィードバック | 分類案 |
| --- | --- | --- |
| F01 | 予約でどのタイムゾーンが使われているのか分かりません。 | タイムゾーンの表示 |
| F02 | 訪問者の現地時刻を表示してください。それと、確認メールが届きませんでした。 | タイムゾーンの表示、確認メールの未着 |
| F03 | 予約画面にはオフィスの時刻しか表示されません。 | タイムゾーンの表示 |

タイムゾーンのグループには、元のメッセージが3件あります。メールの問題は1件です。両方のグループを合わせると、言及は4件ですが、F02に2つの問題が含まれているため、メッセージは3件です。レポートで「要望」という言葉を使う場合は、メッセージ数、言及数、異なるアカウント数のどれを指すのか定義してください。

すべての分類の横に短い抜粋を添えてください。「予約画面にはオフィスの時刻しか表示されません」は、ラベルが分かりにくいという意味かもしれませんし、時刻変換機能がないという意味かもしれません。解釈を黙って決めるのではなく、レビュー用の列に曖昧さを記録しましょう。

## メッセージ数に加え、影響を受けた顧客数も数える

F01とF02が同じアカウントから、F03が別のアカウントから届いたとします。それでもタイムゾーンのグループにはメッセージが3件ありますが、把握できているアカウントは2つです。取得した記録にアカウントIDが含まれていなければ、アカウント数は不明です。文面が似ているからといって、2件のメッセージが同じ人から届いたとは判断できません。

サポートチケットから分かるのは、人々がサポートに問い合わせた内容です。問題に直面した顧客の割合までは分かりません。「今回のレビュー対象となった10アカウントのうち2つ」という数字も、選ばれた会話についてのみ述べています。数値が何を対象としているのか読者に分かるよう、集計期間、フィルター、チャンネルを件数の近くに記載しましょう。

Beeuniに期間ごとのテーマの比較を依頼することもできますが、比較の条件はそろえてください。先月はサポートチケットだけで、今月はアプリ内アンケートも含む場合、件数の増加は新しいデータソースによるものかもしれません。傾向について結論を出す前に、サポート同士を比較できるよう、チャンネルのラベルを保持してください。

## 追加の確認で、一見明確なテーマが分かれることもある

架空のスケジュール管理製品の例を続けましょう。チームはF01とF03の投稿者に、どの画面を使ったのか、どの時刻を期待していたのかを尋ねます。1人は、表示時刻は正しかったものの、タイムゾーンのラベルが画面を下にスクロールしないと見えなかったと答えます。もう1人は、訪問者が別のタイムゾーンを選んでも、予約がオフィスの時刻のままだったと答えます。これらの報告は、別々の作業が必要であることを示しています。

「タイムゾーン」を上位のテーマとして残しつつ、ラベルの見やすさと、時刻変換が機能していない可能性を分けてください。返信は元のソースIDにひも付けます。1つ目の問題はデザイン変更が必要かもしれません。2つ目は、計算、保存された設定、表示のどこに問題があるのか特定するため、再現確認が必要です。グループ名を変更しても、どちらの報告も消えないようにしてください。

F02のメール未着についても、別途確認が必要です。予約が完了したか、どの確認メールを想定していたのかを尋ねましょう。確認メールが届かないと、言及数が少なくても、予定の詳細を見つけられなくなるおそれがあります。タイムゾーンの問題を頻度表の上位に残したまま、メールの問題を先に調査してもかまいません。その順序を選んだ理由を記載してください。

## 内容を問い直せるレポートを作る

- グループラベルとレビュー用フラグを付けた、注釈付きのソースファイル。
- グループごとのメッセージ数、把握できる場合は異なるアカウント数、代表的なソースIDを含む概要。
- 曖昧なコメント、相反する報告、重複の可能性をまとめた未解決リスト。

要望された機能と、報告された不具合は分けてください。「別のエクスポート形式を追加してほしい」と「既存のエクスポートが動かない」は同じ領域に関係するかもしれませんが、必要な対応は異なります。1つのメッセージに両方が含まれる場合は、両方のラベルを残してください。

新しい課題を作成する前に、エージェントに連携済みの課題管理ツールを検索させ、同じ動作に関する課題がないか確認します。既存の課題に新しいソースリンクを追加すればよい場合もあります。検索結果と課題文案を確認してから、必要な更新を具体的に指示してください。後からのレビューで新しいフィードバックと分類の変更を区別できるよう、取得したソースファイルも注釈付きレポートと一緒に保管してください。