契約した数量・機能と実際の利用状況のずれを毎月見て、増減の提案とフォローを決める

処理の起点を決める

毎月第3営業日を起点にします。前月の利用実績がデータ基盤に確定した後のタイミングです。

月初すぐに動かさないでください。 利用実績の集計が終わっていないと、当月の数字が欠けます。データ基盤の集計がいつ終わるかを確認して、その2日後に設定してください。

もう1つの起点として、利用が契約の上限を超えたときに即時で通知する形を置きます。上限超過は、月次を待てません。 顧客が使えなくなっている可能性があります。この即時の経路だけは、別に作ってください。

週次にする必要はありません。 契約と実績のずれは、そこまで速く動きません。上限超過だけを即時にし、残りは月次で十分です。

入力データを集める

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

契約内容： 契約管理システムからエクスポートします。「契約している数量」と「オプション機能の有無」が、項目として取れる必要があります。 契約書のPDFしかない場合、この構成は成立しません。契約内容の構造化が先です。

利用実績： データ基盤から、当月と過去6か月を取ります。6か月にしている理由は、推移の向きを見るためです。 当月だけでは「95%」が高いのか、上がってきたのかが分かりません。

機能別の利用： ここが取れるかどうかで、この構成の価値が変わります。「契約しているが一度も使われていない機能」は、増額の提案でも解約の兆しでもなく、定着支援の対象です。 これが分かると、フォローの種類が1つ増えます。

問い合わせ件数： 同じ使用率でも、問い合わせが多い顧客と少ない顧客では意味が違います。上限に近づいていて問い合わせも多い顧客は、困っている可能性が高くなります。

顧客側の担当者の交代： 利用が急減する原因として、よくあるものです。担当者が代わって使い方が分からなくなった、という状況は、解約の兆しではなく定着支援の対象です。

AIへ渡す前に整形する

1. 顧客IDでの突合 … 契約管理システム、データ基盤、CRMで顧客IDの体系が違うことがあります。対応表を用意してください
2. 契約変更の反映 … 月の途中で契約を変更した顧客は、使用率の計算が複雑になります。月末時点の契約で計算し、変更があった旨を記録します
3. 対象外の除外 … 試用中の顧客、解約が決まっている顧客、契約から1か月未満の顧客を除きます。契約直後は利用が少なくて当然です
4. 単位の統一 … 容量（GB / TB）、呼び出し数（回 / 千回）の単位をそろえます
5. 推移の算出 … 過去6か月の使用率を並べ、傾きを計算します。この計算は表計算側で行います

AIに処理させる

計算処理にさせること：

生成AI（Claude API）にさせること：

「着眼点」が、この構成でもっとも役に立つ出力です。 「上限接近。増額の相談」とだけ言われても、担当者は何を話せばよいか分かりません。「ユーザー数が6か月で60%から94%へ上昇。同時期に問い合わせが3件増えている。人員が増えたのか、設定の見直しが必要なのかを確認する」まで出ると、そのまま電話できます。

提案の金額、増額の幅、解約の可能性の数値化はさせません。 「解約確率68%」といった数字を出させないでください。根拠のない数字が独り歩きします。

指示内容を固定する

あなたは既存顧客のフォローを支援する担当者です。
下の顧客について、契約内容と利用実績のずれを整理し、
フォローの種類と優先度を判定してください。

【厳守事項】
- 数値は下に与えた計算済みの値をそのまま使ってください。
  独自に計算し直さないでください。
- ずれの型は、下の区分からのみ選んでください。複数に当たる場合は、すべて挙げてください。
  どれにも当たらない場合は "正常" としてください。
  **無理にずれを見つけようとしないでください。900社のうち大半は正常です。**
- フォローの種類は、下の区分からのみ選んでください。
- 優先度の理由には、必ず具体的な数値を含めてください。
  「利用が伸びているため」ではなく「6か月で使用率が60%から94%へ上昇」と書いてください。
- 着眼点は、担当者が顧客と話すときに最初に確かめるべきことを1〜2点書いてください。
  **データから読み取れる事実に基づいて書き、顧客の事情を推測しないでください。**
  例：「人員が増えたのか確認する」は可。「事業が拡大しているため」は不可。
- 解約の確率、増額の見込み金額、契約更新の可否を数値で書かないでください。
- 提案の内容（どのプランへ、いくらで）を書かないでください。判断は担当者が行います。
- 顧客の事業の状況、業績、意図を推測しないでください。

【ずれの型の区分】
上限接近 ... 使用率が85%以上
上限超過 ... 使用率が100%を超えている
大幅な未消化 ... 使用率が30%未満で、契約から3か月以上経過
機能の未利用 ... 契約している機能のうち、当月一度も使われていないものがある
利用の急減 ... 前月比で50%以上減少
正常 ... 上記のいずれにも当たらない

【フォローの種類の区分】
増額の相談 / 利用促進 / 原因の確認 / 対応不要

【顧客の情報】
{customer_context}

【契約内容】
{contract}

【利用実績（当月・過去6か月・計算済みの使用率と推移）】
{usage_metrics}

【当月の問い合わせ】
{inquiries}

【直近の接触の履歴】
{contact_history}

【前月のフォローの内容と結果】
{previous_followup}

「無理にずれを見つけようとしない」の1行が重要です。 これを書かないと、900社すべてに何らかの指摘が付きます。指摘が900件出れば、担当者は読まなくなります。 「正常」が大半である状態が、正しい出力です。

「顧客の事情を推測しない」も必須です。 「事業が拡大しているため増員したと考えられます」という記述は、データからは分かりません。その推測を前提に電話すると、顧客に「何も分かっていないな」と思われます。 分かるのは「使用率が上がった」という事実だけです。

「解約の確率を数値で書かない」の指示も入れてください。 「解約リスク72%」といった数字は、根拠を説明できないまま社内で共有され、顧客への態度を変えてしまいます。

複数の項目が同時にずれる顧客の扱いを、先に決めてください。 ユーザー数は上限に迫っているのに、保存容量は契約の2割しか使っていない、という状態がよく起こります。このとき「増額の相談」と「利用促進」の両方に当たります。

そのまま両方のシートに載せると、営業とカスタマーサクセスが別々に同じ顧客へ連絡します。顧客から見ると、社内で話が通っていない会社に見えます。

対処は3つの考え方に分かれます。

2つ目をおすすめします。 顧客から見て窓口が1人であることのほうが、社内の分業より優先されます。その場合、assignee_role の判定は「顧客の主担当」をCRMから引いて上書きします。

【厳守事項（複数のずれがある場合)】
- gaps には該当するすべての型を入れてください。優先度の高いものだけに絞らないでください。
- combined_note に、複数のずれの関係を1〜2行で書いてください。
  例：「ユーザー数は上限接近だが、保存容量は2割しか使われていない。
      利用の中心が特定の用途に偏っている可能性がある」
- followup_type は1つだけ選んでください。
  契約金額への影響が大きいほうを選び、選ばなかった理由を書いてください。

combined_note が、担当者が顧客と話すときにもっとも役立ちます。 「ユーザーは増えているのに容量が使われていない」という事実から、話の切り口が1つ生まれます。

出力形式を固定する

{
  "customer_id": "",
  "customer_name": "",
  "period": "",
  "gaps": [
    {
      "gap_type": "上限接近 | 上限超過 | 大幅な未消化 | 機能の未利用 | 利用の急減 | 正常",
      "item": "",
      "current_rate": 0,
      "trend_note": "",
      "evidence": ""
    }
  ],
  "combined_note": "",
  "followup_type": "増額の相談 | 利用促進 | 原因の確認 | 対応不要",
  "assignee_role": "営業 | カスタマーサクセス",
  "priority": "high | medium | low",
  "priority_reason": "",
  "talking_points": [],
  "previous_followup_status": "improved | unchanged | worsened | no_previous",
  "data_gaps": []
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。

assignee_role を出力に含めている点が実務上効きます。 増額の相談は営業、利用促進はカスタマーサクセスが向いています。振り分けが自動で決まると、配信を分けられます。

previous_followup_status が、この構成を育てる項目です。前月にフォロー対象となった顧客が、今月どうなったかを追います。unchanged が続く顧客は、フォローが届いていないか、フォローの内容が合っていません。

data_gaps には、判断に必要なデータが欠けている箇所を入れます。「機能別の利用データが取れていない」といった内容です。これが多い顧客は、判定の信頼度が低いということです。

システムへ連携する

フォロー一覧をスプレッドシートに作ります。フォローの種類ごとにシートを分けます。

各シートの列は次の構成です。

「正常」の顧客もシートには残しますが、既定では非表示にします。 後から「この顧客は先月どうだったか」を見られるようにするためです。

顧客への連絡は、人が行います。 自動メールの経路を作らないでください。上限接近の通知が自動で届くと、顧客は「使わせないための通知」と受け取ります。

CRMへの書き戻しは、対応の記録だけにします。 「増額の相談を実施」「利用促進の面談を設定」といった活動記録を残します。判定結果そのものをCRMへ書き込むと、営業が顧客の前でその画面を開いたときに見えてしまいます。

人が確認する

followup_type が「対応不要」以外のものを、担当者が確認します。

900社すべてを確認すると効果が出ません。実際にフォローの対象になるのは、月に80〜150社程度のはずです。 それ以上出るなら、閾値の設定を見直してください。

確認の深さを分けます。

• gap_type が「上限超過」 … すでに使えなくなっている可能性。即日確認する
• priority が high … その週のうちに連絡する
• previous_followup_status が unchanged または worsened … 前月のフォローが効いていない。やり方を変える
• data_gaps が多い顧客 … 判定を信用しない。データの取得を確認する
• priority が medium / low … 月内に確認する

確認を速くするための設計が効きます。

• フォローの種類ごとにシートを分ける（自分の担当分だけ見ればよい）
• 上限超過を最上部に固定する
• 契約金額と更新日を並べて表示する
• 前月の対応内容を併記する（同じ話を繰り返さない）
• 着眼点を、そのまま電話で使える文にする

4つ目が効きます。 前月に「増額のご相談をしたが、予算の都合で見送り」と記録されていれば、今月また同じ話をせずに済みます。

例外に対処する

記録を残す

この記録は、フォローの効果を測る材料になります。

• 月ごとの判定結果（ずれの型、フォローの種類、優先度）
• 担当者が実施したフォローと、その結果
• 前月からの変化（previous_followup_status）
• 増額に至った案件と、そのきっかけ
• 解約に至った顧客の、直前3か月の判定履歴
• data_gaps の内容

「解約に至った顧客の判定履歴」を必ず残してください。 解約が起きたとき、その兆候がこの仕組みで見えていたかを振り返れます。 見えていたのにフォローしなかったなら運用の問題、見えていなかったなら判定の型の問題です。どちらかを特定できます。

増額に至ったきっかけも記録してください。 「上限接近の連絡から2週間で増額」という記録が積み上がると、この仕組みの効果を金額で説明できるようになります。