SaaSのNPSアンケートの自由記述を、機能の要望・不具合・使い方の質問・価格に分けて、プロダクトとサポートとカスタマーサクセスへ届くたびに振り分ける

処理の起点を決める

回答が届くたびに、1件ずつ動かします。 不具合の報告がサポートに届くまでの日数を縮めることが、この構成のいちばんの目的です。まとめて週に1回では、第3章の（a）が残ります。

New or Updated Form Response ではなく、New Form Response を使います。 回答の修正でも動く方を選ぶと、同じ記述からチケットが2つできます。 フォームの設定で回答の編集を許していない場合も、こちらで足ります。

自由記述が空の回答は、最初の Filter で止めます。 点数だけの回答も回答のシートには残るので、NPSの集計には影響しません。

入力データを集める

質を決めるのは、機能の領域の一覧です。 第3章の（c）は、領域の名前を人がその場で考えていたことから起きていました。プロダクトが決めた一覧をAIに渡し、その中から選ばせます。 一覧に無い領域を作らせません。

一覧には、領域ごとに短い説明を付けます。 「CSVの取り込み：経費や取引先のデータをファイルで一括登録する機能」のように書くと、「一括で入れるとき」のような言い換えも同じ領域に寄ります。

データの取得方法を決める

機能の領域の一覧は、1つのセルにまとめて持ちます。 Lookup Spreadsheet Row は一致した1行を返すので、領域を1行ずつ持つと、全部を1回で取れません。 一覧のシートに「領域の一覧」という行を1つ作り、そのセルに領域と説明を並べておきます。プロダクトが領域を足したら、このセルを直すだけで次の回答から使われます。

顧客台帳で顧客IDが見つからないときの動きを決めておきます。 Lookup Spreadsheet Row は一致する行が無いときの扱いを指定できるので、見つからなければ後続を止めずに企業名を「不明」とし、見直しの一覧に入れます。 事前入力のリンクを転送された人が答えると、こうなります。

AIへ渡す前に整形する

1. 自由記述が空なら終える … Filter で止めます
2. 極端に短い記述を分ける … 「特になし」「なし」のような記述は、AIに渡さず記録だけにします。一覧を作って Filter で照合します
3. 顧客台帳を引く … 企業名・プラン・担当を付けます。AIには企業名もプランも渡しません
4. 機能の領域の一覧を引く … AIへの選択肢として渡します
5. メールアドレスや電話番号が記述に書かれていたら、そのまま渡す … 消すかどうかはAIの前では決めず、第13章の方針に従います

3番目で、AIに企業名やプランを渡さないのは意図してのことです。 分類に要るのは記述だけで、大口の企業の回答だから重く扱う、という判断をAIにさせないためです。重みづけは、届いた先で担当が顧客台帳を見て行います。

AIに処理させる

させるのは、自由記述を話題ごとに切り分け、話題ごとに分類・機能の領域・確信度を付け、根拠の文を写すことです。

bug と how_to の見分けが、この分類でいちばん難しいところです。 「承認ボタンが押せない」は、不具合のこともあれば、権限の設定を知らないだけのこともあります。どちらもサポートに届くので、間違えても届け先は同じです。 分類を2つに分けているのは、サポートがチケットの優先度を決める材料にするためです。

最後の行が、要望台帳を使えるものにする条件です。 生成AIは、一覧に合う領域が無いと、それらしい新しい名前を作ります。unknown にさせ、見直しの一覧でプロダクトが領域を足すか決めます。

指示内容を固定する

Analyze and Return Data の指示の欄に、次のように書きます。

あなたは法人向けSaaSのカスタマーサクセス部で、NPSアンケートの
自由記述を社内の担当部署に振り分ける担当です。

【手順】
1. 自由記述を、話題ごとに切り分けてください。
   1つの文に2つの話題があれば、2つに分けてください。
2. 切り分けた話題ごとに、分類を1つ選んでください。
   bug / how_to / feature_request / pricing / praise / other
3. 話題ごとに、機能の領域を一覧から1つ選んでください。
   合うものが無ければ unknown としてください。
4. 話題ごとに、確信度を high / low で付けてください。
   bug と how_to のどちらか迷うとき、要望か不満か迷うときは low です。
5. quote には、その話題の根拠にした部分を記述からそのまま写してください。

【厳守事項】
- 機能の領域は、一覧にある名前だけを使ってください。
  新しい名前を作らないでください。
- 記述に書かれていない不具合の原因や、機能の有無を推測しないでください。
- 解約の可能性、要望を採用すべきかを書かないでください。
- 話題が1つしか無ければ、1つだけ返してください。
  分けすぎないでください。

【機能の領域の一覧】{feature_areas}
【NPSの点数】{score}
【自由記述】{comment}

「新しい名前を作らない」と「unknown にする」を両方書くのが要です。 禁じるだけだと、いちばん近い領域に無理に当てはめます。当てはまらないときの行き先を示すと、無理な当てはめが減ります。

「分けすぎない」も入れておきます。 「とても使いやすく、サポートの対応も早い」を2つの praise に分けると、件数を数えるときに評価が倍に見えます。

点数を渡しているのは、bug と pricing の見分けのためです。 「高い」は、低い点数なら価格への不満、高い点数なら「品質が高い」のこともあります。

出力形式を固定する

Analyze and Return Data の出力の項目を、次のように定義します。 見やすさのため JSON の形で示します。

{
  "topics": [
    {
      "category": "bug | how_to | feature_request | pricing | praise | other",
      "feature_area": "",
      "confidence": "high | low",
      "quote": "",
      "summary": ""
    }
  ],
  "topic_count": 0
}

第1章の例の記述（点数7）なら、次のように返ります。

{
  "topics": [
    { "category": "praise", "feature_area": "月次の集計",
      "confidence": "high",
      "quote": "月次の集計画面が見やすくなって助かる",
      "summary": "月次の集計画面の見やすさへの評価" },
    { "category": "bug", "feature_area": "CSVの取り込み",
      "confidence": "high",
      "quote": "CSVの取り込みで文字化けする",
      "summary": "CSVの取り込みで文字化けが起きている" },
    { "category": "pricing", "feature_area": "unknown",
      "confidence": "low",
      "quote": "もう少し安いプランがあれば部署を増やしたい",
      "summary": "利用部署を増やすための料金の相談" }
  ],
  "topic_count": 3
}

3つ目の話題が low なのは、価格への不満とも、利用を広げたい前向きな相談とも読めるからです。 どちらであっても担当が話を聞きに行く価値があり、見直しの一覧で担当が読んでから動きます。

1つ目の理由は、topics をそのままループにかけられることです。 Create Loop From Line Items に topics を渡すと、話題の数だけ後続が動きます。回答1件が3つの話題を持てば、チケットと台帳と知らせが1回ずつ動きます。

2つ目は、category と confidence で Paths の分かれ道を決められることです。

3つ目は、quote で届いた先の人が原文を確かめられることです。 チケットや要望台帳には、要約ではなく記述の原文の部分を載せます。要約だけでは、顧客が何に困っていたかの細部が落ちます。

ループの後のアクションはループの回数だけ動くので、点数が6以下の知らせはループの前に置きます。 ループの後に置くと、話題の数だけ同じ知らせが届きます。

システムへ連携する

Zendesk は、Zapier では有料プランで使えるプレミアムのアプリで、Zendesk の Team プラン以上と管理者の権限が要ります。 チケットを作るときは、回答者のメールアドレスと企業名、記述の原文、点数を入れます。Zendesk の側の自動メールの設定によっては、チケットの作成で回答者に受付のメールが届くことがあります。 NPSから作ったチケットにはタグを付け、受付のメールを送るかどうかをサポートと決めておきます。

Slack の担当へのダイレクトメッセージは、顧客台帳の担当のメールアドレスで相手を探して送ります。 Slack の連携は、メールアドレスや名前で利用者を探せます。

人が確認する

1. 届いた先で、それぞれの部署が対応する … サポートはチケットに、プロダクトは要望台帳に、担当は知らせに応えます
2. 見直しの一覧を週に1回確かめる … 確信度が low のもの、other のもの、顧客IDが見つからなかったものを振り分け直します
3. 届いた先から戻されたものを記録する … 「これは不具合ではない」とサポートが戻したチケット、「要望ではない」とプロダクトが戻した行を、分類の誤りとして残します
4. 機能の領域の unknown を見る … プロダクトが、一覧に領域を足すかを決めます

週に1回の見直しでは、次の順に見ます。

振り分けの前に人が全件を確かめる設計にはしません。 届け先はどれも社内の受け口で、誤って届いても顧客に何かが送られるわけではありません。 その分、届いた先から戻す道と、戻された記録を必ず作ります。

目標は、600件をならして1件1.5分です。 振り分けの大半は人の手を通らず、見直しの一覧と戻されたものの記録に時間を使う見込みです。

例外に対処する

5行目は、分類の外で守ります。 「他社に替えるか検討中」は pricing にも other にもなりえます。どちらに落ちても担当に届くよう、点数の規則と、見直しの一覧の確認で二重に拾います。

記録を残す

• 回答の全文（点数、自由記述、顧客ID、回答日時）
• AIの出力の全文（話題ごとの分類、領域、確信度、原文）
• 話題ごとの届け先と、作ったチケットの番号・要望台帳の行
• 届いた先から戻された記録 … どの分類が、どう誤っていたか
• 回答からチケットができるまでの時間

最後の行が、この構成の物差しです。 第3章の（a）で3〜4日かかっていたものが、回答の直後にチケットになっているかを毎月見ます。