SaaS・サブスクの解約申請フォームの理由欄を分類し、引き留めの余地があるものをカスタマーサクセスへ、不具合が理由のものをサポートへ振り分ける

処理の起点を決める

解約申請の送信を起点にします。 自社サービスの解約の処理の中に、Webhook のURLへ申請の内容を送る処理を足します。毎日の定時に未処理をまとめて読む作りにはしません。 引き留めの連絡は申請から数日が勝負で、半日の遅れがそのまま話を聞ける時間を削ります。

送るのは、解約の手続きが受け付けられた後です。 送信に失敗しても解約の手続きは止めません。Webhook の失敗で解約ができなくなる作りにすると、顧客は解約の画面でエラーを見ることになります。 解約の受付と社内の振り分けを、別々に失敗できるようにしておきます。

Zap を止めている間に届いた申請について、一つ注意があります。Zap を止めたり消したりすると Catch Hook は404を返すようになりますが、その切り替わりまでに数時間かかることがあり、その間は200が返ります。 自社サービスの側で「200が返ったから届いた」とみなすと、止めている間の申請が振り分けられずに消えます。 送った申請には自社の側で送信済みの印を付け、毎朝、台帳に記録が無い申請を突き合わせます。

入力データを集める

質を決めるのは、自由記述と分類の手引きです。 選択肢だけなら規則で振り分けられます。AIを使う理由は、選択肢で「料金」を選んだ人が自由記述に「CSVの取り込みが毎回失敗するので、この料金は払えない」と書くような、選択肢と本文が食い違う申請を読むためです。

契約と利用の情報は、申請と一緒に自社サービスから送ります。 Zapier から管理画面を見に行くより、申請を送る側が持っている値を添えるほうが確実で速く済みます。 AIはこの値を分類の参考にしますが、行き先を決める材料には使わせません。 契約の大きさで行き先を変えるのは、規則の側の仕事です。

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

顧客台帳は、会社IDで引きます。 会社名で引くと、「株式会社」の有無や支店名で引けない会社が出ます。Lookup Spreadsheet Row は探す列と値を指定し、最後の行から探す設定や、見つからないときに新しい行を作る設定を持っています。この構成では、見つからないときに行を作る設定は使いません。 台帳に無い会社は、作るのではなく受付の窓口へ回します。

同じ会社の過去の申請も見ておきます。 一度解約を取り下げた会社が再び申請してきた場合、カスタマーサクセスにとっては事情が違います。解約理由の台帳を会社IDで引き、最後の行から探す設定で直近の1件を取ります。

AIへ渡す前に整形する

1. 空の申請を除く … 申請IDか会社IDが無いものは、分類せずに受付の窓口へ回します
2. 重複を除く … 同じ申請IDが台帳にすでにあれば、二度目は処理しません。送り直しで同じ申請が二度届くことがあるためです
3. 自由記述の空欄を印にする … 自由記述が空なら、free_text_empty を true にして分類へ渡します。選択肢だけで分類させ、AIに理由を作らせないためです
4. 個人の連絡先を落とす … 自由記述に電話番号やメールアドレスが書かれていれば、自社サービスの側で送る前に伏せ字にしておきます
5. テスト申請を除く … 社内の検証用アカウントからの申請は、会社IDの一覧で除外します

3番目を省くと、空欄の申請に「料金が理由と思われる」といった理由が付きます。 選択肢しか無い申請は、選択肢どおりにしか分類できません。分からないことを分からないと返させるための印です。

AIに処理させる

させるのは、理由の種類を決め、引き留めの余地と不具合の有無に印を付け、根拠にした文を写すことだけです。

引き留めの余地の付け方は、分類の手引きに書きます。 「料金」「使いこなせない」「機能不足」は話を聞けば変わる可能性があり、「事業の終了」「会社の廃業」は変わりません。 ただし同じ「料金」でも「他社が半額だった」と「予算が削られた」では意味が違うので、最終的な余地の高さは自由記述で決めさせます。

4行目が、いちばん起きやすい失敗です。 「エラーが出る」と書かれた申請に、AIが「ブラウザのキャッシュが原因と思われる」と添えると、サポートは調べる前にその前提で返事を書きます。 本当にサービスの側の不具合だった場合、顧客は二度、同じ説明をすることになります。

指示内容を固定する

あなたはSaaSのカスタマーサポートで、解約申請の理由を分類する立場です。
解約申請に書かれた内容だけを根拠にしてください。推測で補わないでください。

【理由の種類（reason_category）】次のどれか1つを選んでください。
- price ............. 料金が高い、予算が合わない
- adoption .......... 使いこなせない、社内に定着しなかった
- missing_feature ... 必要な機能が無い
- bug ............... 不具合、障害、データの消失、動作が遅い
- competitor ........ 他社のサービスへ移る
- business_end ...... 事業の終了・縮小、廃業、統合
- staff_change ...... 担当者の退職・異動で使う人がいなくなった
- other ............. 上のどれにも当たらない

【引き留めの余地（retention_signal）】
- high .... 条件が変われば続ける意思が読み取れる（例：「安ければ続けたい」）
- medium .. 理由が改善できる種類だが、続ける意思までは書かれていない
- none .... 事業の終了など、サービスの側で変えられない理由
- unknown . 自由記述が空、または判断できるだけの記載が無い

【厳守事項】
- 選択肢と自由記述が食い違うときは、自由記述を優先してください。
  その場合は choice_conflict を true にしてください。
- 自由記述に不具合・エラー・データの消失・動作の遅さが書かれていれば、
  理由の種類が何であっても bug_reported を true にしてください。
  使い方の問題か不具合か分からないときは "unclear" にしてください。
- 不具合の原因を推測しないでください。対処方法も書かないでください。
- free_text_empty が true のときは、選択肢だけで分類し、
  retention_signal は unknown にしてください。理由を書き足さないでください。
- 行き先、値引き、プランの変更の提案は書かないでください。
- evidence には、判断に使った自由記述の一部をそのまま写してください。
  言い換えないでください。
- confidence は、分類にどれだけ迷わなかったかを high／low で書いてください。
  理由が2つ以上同じくらい書かれているときは low にしてください。

【解約申請】
選択肢：{reason_choice}
自由記述：{free_text}
free_text_empty：{free_text_empty}
【参考：契約と利用の情報】{usage_info}

「理由の種類が何であっても bug_reported を true に」を書かないと、選択肢の理由に引っ張られます。 「料金」を選んで自由記述に不具合を書いた申請が price に分類され、不具合の印が付かないままカスタマーサクセスへ回ります。 理由の種類と不具合の有無を別の項目にしているのは、この申請を取りこぼさないためです。

「対処方法も書かない」は、AIが親切で書き足すのを止めるためです。 分類だけを頼んでも、不具合の申請には「再ログインで解決する場合があります」と添えがちです。要点の欄にこれが入ると、サポートの担当者が最初に読む1文が推測になります。

出力形式を固定する

AI by Zapier の出力のフィールドを、次の項目で定義します。 フィールドに分けておくと、後ろの手順で1つずつ条件や記録に使えます。

{
  "reason_category": "price | adoption | missing_feature | bug | competitor | business_end | staff_change | other",
  "retention_signal": "high | medium | none | unknown",
  "bug_reported": "true | false | unclear",
  "choice_conflict": "true | false",
  "summary": "",
  "evidence": "",
  "confidence": "high | low"
}

1つ目の理由は、Paths の条件をこの値だけで書けることです。 文章の中から「不具合」という語を探す条件は、書き方が変わると外れます。値が決まった選択肢の中から返るので、条件が壊れません。

2つ目は、行き先を決める規則を表で持てることです。

分岐の条件を重ならないように書くのが要点です。 Paths の分岐は左から順に1つずつ実行され、条件を満たした分岐はすべて動きます。 A と B の条件が重なると、不具合の申請がサポートとカスタマーサクセスの両方に回り、顧客に別々の部署から連絡が行きます。 B と C に「bug_reported が false」を入れているのは、そのためです。

confidence が low のものは、A〜C の条件にも「confidence が high」を足して、Fallback に落とします。 迷った分類を担当者に回すより、受付で1件読むほうが速く終わります。

3つ目は、台帳に同じ形で残ることです。 理由の種類が決まった選択肢なので、月ごとの件数を比べられます。 これまで人ごとにばらばらだった集計が、そのまま使えるようになります。

システムへ連携する

台帳への記録を Paths の前に置くのは、Paths の制約のためです。 Paths の手順を足すと、それが Zap の最後の手順になります。 分岐の後ろに共通の記録の手順は置けないので、全件に必要な記録は分岐の前で済ませます。 分岐の後ろで記録しようとすると、分岐の数だけ同じ手順を作ることになります。

自社サービスと顧客台帳には書き込みません。 解約の手続きを変える経路を、この構成は持ちません。担当者が引き留めの話をして取り下げになった場合も、取り下げの操作は顧客自身か担当者が管理画面で行います。

分岐Aでは、サポートのチケットに自由記述をそのまま入れます。 要点は添えますが、サポートが読むのは顧客が書いた文です。 担当者がいる会社なら、担当者にも「サポートで調べている」とだけ知らせ、引き留めの連絡はサポートの回答が出るまで待ってもらいます。

人が確認する

人が読むのは、受付の窓口に回ったものと、毎日の終わりの流し見です。 分岐AとBの件は、それぞれの担当者が対応の中で読むので、受付の担当者は開きません。

1. 受付の窓口に回ったものを読む … 自由記述と選択肢を読み、行き先を決めて担当者に回します。台帳の分類も、その場で直します
2. 毎日の終わりに、その日の台帳を流し見る … 理由の種類と行き先の列だけを上から見て、明らかな誤りを直します
3. 担当者から戻ってきた誤りを記録する … 「不具合ではなく使い方の問題だった」「引き留めの余地は無かった」を台帳の訂正の列に残します
4. 月に一度、訂正の多い種類を見る … 同じ種類の誤りが続くなら、分類の手引きの例文を足します

3番目が、この構成を育てる記録です。 AI by Zapier は実行のたびに学習する仕組みではありません。 誤りを直しても、次の申請の分類は変わりません。直すには、分類の手引きの例文を人が書き足すしかなく、 そのための材料が訂正の列です。

目標は、450件をならして1件2分です。 受付の窓口に回るのが2割前後という想定で、それより多い月は、選択肢と自由記述の食い違いが増えているか、分類の手引きに無い理由が出てきています。

例外に対処する

6行目で「未分類」を残すのは、件数を合わせるためです。 分類に失敗した申請が台帳から消えると、月の解約件数と台帳の件数が合わなくなり、 どの申請が漏れたかを後から探すことになります。

7行目は第7章のトリガーで書いた、Zap を止めたときの問題への備えです。 止めた直後の数時間は200が返るため、送った側の記録と受けた側の記録を突き合わせる以外に、漏れを見つける方法がありません。

記録を残す

• 申請の内容（選択肢・自由記述）と、受け取った日時
• 分類の結果（7項目すべて）と、そのとき使った分類の手引きの版
• 行き先（分岐A・B・C・Fallback のどれに入ったか）と、連絡した相手
• 人が分類を直した記録 … どの項目を、何から何に変えたか
• 担当者の対応の結果（連絡が取れた、取り下げになった、解約どおり）
• Zapier の Zap の実行の履歴（エラーになった実行を含む）

2つ目の「手引きの版」は、月ごとの比較のために残します。 例文を足すと分類の傾向が変わるので、「機能不足が先月より増えた」が顧客の変化なのか手引きの変化なのかを、版で見分けます。

5つ目の対応の結果は、引き留めの余地の付け方が合っていたかを確かめる材料になります。 high が付いた件の取り下げの割合が medium と変わらないなら、余地の高さの付け方を見直す時期です。