公式スキル · カスタマーサクセス

アカウントの解約リスクのメモ

v1.0.1・2026年11月4日更新

1つのアカウントについて、根拠つきのリスク度、原因の仮説、担当者と期日つきの引き止めプラン、顧客に伝える文面をまとめる。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• 利用が落ちた、推進役が辞めた、更新が近く何かおかしいと感じる
• 引き止めの電話やリスクアカウントのレビューの前

AI に渡すもの

• 利用データ（できれば比べられる2期間分）
• 最近のチケット
• 電話のメモとメール
• プラン、金額、更新日

できあがるもの

根拠の表、仮説、日付つきの引き止めプラン、顧客への文面をまとめた1ページのリスクメモ。

手順

1. シグナルを並べる 入力にあるシグナルを出どころつきで1つのリストにまとめる: 「アクティブユーザー 42 → 18（利用データ、7月と4月の比較）」。よくあるもの: アクティブユーザーが30%以上減った、主要機能が30日使われていない、未解決のチケットが3件以上、14営業日を超えて未解決のチケットがある、推進役が辞めた、予算や競合の話が出た、打ち合わせが流れた、席数を減らしたいと言われた。
2. このスキルの既定の基準でリスク度を決める チームにヘルススコアがあれば、それに合わせて書き換える。高: 強いシグナル（推進役の退職、競合や解約への言及、利用が50%以上減少）が2つ以上、または更新まで60日以内で強いシグナルが1つでもある。中: 強いシグナルが1つ、または弱いシグナルが3つ以上。低: 弱いシグナルだけ。どのシグナルでその度合いにしたかを書く。
3. 原因の仮説を書く 1文で、こちらから見えることではなく、顧客の側で何が変わったか。「導入を進めた業務責任者が6月に辞め、今はツールの持ち主がいない」。その根拠と、どうなれば仮説が外れるかを添える。原因が2つ考えられるなら両方書き、どちらを先に確かめるかを書く。
4. 引き止めプランを立てる 2〜5手順。それぞれに担当者を1人（人の名前。「CS」は不可）、日付、完了の状態をつける。最初の手順は5営業日以内に行う。手順は原因に合わせる。推進役がいなくなったなら必要なのは新しいスポンサーで、機能のデモではない。
5. 顧客に伝える文面を書く 次のメッセージか電話の冒頭で使う2〜4文: 気づいたことを顧客の言葉で言い、具体的な手助けを1つ申し出て、質問を1つする。「利用が減っていますね」を責めるように言わない。何を手伝いたいかを言う。
6. 金額と期日を書く 契約金額と更新日は入力から写す。なければ「[要確認: 金額]」と書く。推測しない。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: churn-risk-note
description: 利用データ、サポートチケット、商談・打ち合わせのメモから、顧客アカウント1社の解約リスクのメモを書く。根拠つきのリスク度、原因の仮説、手順ごとに担当者と期日をつけた引き止めプラン、顧客に伝える文面を出す。解約しそうなアカウントがあるとき、更新が近いとき、利用が落ちたとき、推進役（チャンピオン）が辞めたとき、「アカウントヘルス」「チャーンリスク」「解約リスク」のまとめを頼まれたときに使う。
---

# 解約リスクのメモ

解約リスクのメモの役目は、1つのアカウントについて、適切な人に今週動いてもらうこと。リスク度を示し、その根拠を見せ、いちばんありそうな原因を挙げ、引き止めの手順をそれぞれ名前のある担当者と日付に割り当てる。感覚より根拠。リスクの主張にはすべて、数字、チケット、発言の引用のどれかをつける。

## 使う場面

- 利用が落ちた、推進役が辞めた、更新まで90日以内で何かおかしいと感じる。
- 引き止めの電話やマネージャーへのエスカレーションの前。
- 毎週のリスクアカウントのレビュー。
- 多数のアカウントにまたがる解約分析には使わない。顧客の声の側は feedback-themes を使う。

## 用意するもの

- 利用データ: ログイン、アクティブユーザー、主要機能の利用。できれば直近3か月とその前の3か月。
- 最近のチケットとその状況。
- 電話や打ち合わせのメモ、顧客とのメール。
- アカウントの基本情報: プラン、席数、契約金額、更新日、主な窓口と推進役。
- どれかが欠けていても進め、根拠の欄に「[不足: …]」と書く。チケットから利用状況を、利用状況からチケットを推測しない。

## 手順

1. **シグナルを並べる。** 入力にあるシグナルを出どころつきで1つのリストにまとめる: 「アクティブユーザー 42 → 18（利用データ、7月と4月の比較）」。よくあるもの: アクティブユーザーが30%以上減った、主要機能が30日使われていない、未解決のチケットが3件以上、14営業日を超えて未解決のチケットがある、推進役が辞めた、予算や競合の話が出た、打ち合わせが流れた、席数を減らしたいと言われた。
2. **このスキルの既定の基準でリスク度を決める。** チームにヘルススコアがあれば、それに合わせて書き換える。高: 強いシグナル（推進役の退職、競合や解約への言及、利用が50%以上減少）が2つ以上、または更新まで60日以内で強いシグナルが1つでもある。中: 強いシグナルが1つ、または弱いシグナルが3つ以上。低: 弱いシグナルだけ。どのシグナルでその度合いにしたかを書く。
3. **原因の仮説を書く。** 1文で、こちらから見えることではなく、顧客の側で何が変わったか。「導入を進めた業務責任者が6月に辞め、今はツールの持ち主がいない」。その根拠と、どうなれば仮説が外れるかを添える。原因が2つ考えられるなら両方書き、どちらを先に確かめるかを書く。
4. **引き止めプランを立てる。** 2〜5手順。それぞれに担当者を1人（人の名前。「CS」は不可）、日付、完了の状態をつける。最初の手順は5営業日以内に行う。手順は原因に合わせる。推進役がいなくなったなら必要なのは新しいスポンサーで、機能のデモではない。
5. **顧客に伝える文面を書く。** 次のメッセージか電話の冒頭で使う2〜4文: 気づいたことを顧客の言葉で言い、具体的な手助けを1つ申し出て、質問を1つする。「利用が減っていますね」を責めるように言わない。何を手伝いたいかを言う。
6. **金額と期日を書く。** 契約金額と更新日は入力から写す。なければ「[要確認: 金額]」と書く。推測しない。

## 出力の形式

```markdown
# 解約リスク: [アカウント名] — [日付]

**リスク:** [高 / 中 / 低] — [1行で、その度合いにしたシグナル]
**更新日:** [日付] · **金額:** [金額か「[要確認: 金額]」] · **担当:** [アカウント担当者]

## 根拠
| シグナル | 出どころ | 詳細 |
|---|---|---|
| [シグナル] | [利用データ / チケット / 電話 / メール] | [数字、日付、または引用] |

## 原因の仮説
[1文。] 根拠: [...]。外れる条件: [...]。

## 引き止めプラン
| 手順 | 担当者 | 期日 | 完了の状態 |
|---|---|---|---|
| [動詞で始まる手順] | [名前] | [日付] | [目で確かめられる結果] |

## 顧客に伝えること
> [2〜4文]

## 不足している情報
- [判断を変えうる、もらっていないデータ]
```

## 例

**入力:**

> 今日: 2026年9月9日（水）。アカウント: ひかり歯科クリニック、25席、11月30日更新、年額180万円。利用: 週次アクティブユーザー 21 → 7（8月と5月の比較）。予約機能: 8月12日から利用なし。チケット: カレンダー連携について未解決が2件、古いほうは19営業日。9月2日の電話メモ: 「事務長の山口が辞めて、今は森が代わりに見ています」。森さんから、10席に減らせないかと聞かれた。

**出力:**

```markdown
# 解約リスク: ひかり歯科クリニック — 9月9日（水）

**リスク:** 高 — 推進役が退職、利用が67%減少、席数の削減を打診、更新まで82日
**更新日:** 11月30日（月） · **金額:** 年額180万円 · **担当:** [アカウント担当者]

## 根拠
| シグナル | 出どころ | 詳細 |
|---|---|---|
| 推進役の退職 | 電話、9月2日 | 「事務長の山口が辞めて、今は森が代わりに見ています」 |
| アクティブユーザーが67%減少 | 利用データ | 週次 21 → 7、5月と8月の比較 |
| 主要機能が使われていない | 利用データ | 予約機能: 8月12日から利用なし |
| 放置されたチケット | チケット | カレンダー連携で未解決2件、古いほうは19営業日 |
| 席数の削減を打診 | 電話、9月2日 | 森さんが10席について質問 |

## 原因の仮説
予約機能を回していたのは山口さんで、退職後はカレンダー連携の不具合が森さんの手を止め、利用を引っぱる人がいない。根拠: 予約機能は8月12日から使われておらず、退職は9月2日の電話で伝えられた [確認: 山口さんの退職日]。未解決のチケットは2件とも連携の件。外れる条件: 山口さんの退職より前に利用が落ちていた。

## 引き止めプラン
| 手順 | 担当者 | 期日 | 完了の状態 |
|---|---|---|---|
| カレンダー連携を直すか回避策を出し、チケット2件を閉じる | [サポートリーダー] | 9月11日（金） | 森さんが連携の動作を確認 |
| 森さんと30分の設定の打ち合わせをし、予約機能を再開する | [アカウント担当者] | 9月16日（水） | その週に予約機能が使われる |
| 今後ツールの持ち主になる人を森さんに聞く | [アカウント担当者] | 9月16日（水） | 持ち主の名前が決まる |
| 3週間後、利用状況を見ながら席数を見直す | [アカウント担当者] | 10月7日（水） | データにもとづいて席数が合意される |

## 顧客に伝えること
> 森様、山口様の退職後に引き継いでくださり、ありがとうございます。カレンダー連携の不具合は弊社の問題です。今週中に直し、直りしだいご連絡します。来週30分ほどお時間をいただき、予約機能をもう一度使える状態にしませんか。そのうえで、実際の使い方に合わせて席数を決められればと思います。

## 不足している情報
- 5月より前の利用データ。山口さんの退職後に利用が落ち始めたことを確かめるため。
- 山口さんの退職日。8月12日と比べるため。
```

## 送る前のチェック

- [ ] リスク度に、基準に沿ってその度合いにしたシグナルが書いてある。
- [ ] 根拠の各行に出どころと、数字・日付・引用のどれかがある。
- [ ] 仮説に、どうなれば外れるかが書いてある。
- [ ] 引き止めの手順すべてに名前のある担当者が1人と日付があり、最初の手順は5営業日以内。
- [ ] 入力にない契約金額、日付、利用の数字が入っていない。
- [ ] 顧客への文面が、利用について責めるのではなく、手助けを申し出ている。

## よくある失敗

- 「なんとなく静か」だからリスク高にする。シグナルを示すか、度合いを下げる。
- 値引きだけの引き止めプラン。価格が原因であることはまれ。先に原因を直す。
- 担当者を「CS でフォロー」にする。人の名前を書く。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.1 · 2026年11月4日 · Example: the input states today (Wednesday 9 September 2026) and the first save step is due Friday 11 September, not a Sunday; the hypothesis no longer dates Joel's exit, which the input doesn't give, and marks it to check.
• v1.0.0 · 2026年11月4日 · First release.