HubSpot サブスクリプション管理とMRR追跡・更新設計

HubSpotでは、契約・請求の記録と顧客対応を結び付け、サブスクリプションの状況を追えます。更新と収益の判断に使う情報を、対象契約までたどれるようにすることが設計の出発点です。

「更新日を表計算で追い、対象者を毎回作り直している」
「請求情報と顧客とのやり取りが別々で、確認のたびに画面を行き来する」
「解約の申し出を受けてから、利用状況や過去の問い合わせを調べている」——こうした状態では、対象契約の特定や担当者への引き継ぎに手間がかかります。

HubSpotのサブスクリプション管理では、定期契約の情報を顧客や取引の記録と関連付け、請求状況や更新対応をCRM上で追えるようにします。設計するときは、契約条件の正本、請求結果の確認先、更新を判断する担当を先に決めます。そのうえで、MRRなどの指標に使うデータと、担当者の行動につなげるデータを整理します。

次の表は、商品情報と契約条件を対応させる際の確認先です。登録した商品と実際の契約で名称や請求条件が異なる場合は、まず契約固有の条件を確認します。共通の商品情報を直すべきか、個別の契約記録で扱うべきかを決めてから、通知や収益集計に進みます。

この記事でわかること

表計算による更新管理を見直したい方や、契約記録からMRRを説明できるようにしたい方に向けて、情報の置き場所、指標の定義、更新通知を試す順序を説明します。契約の記録が食い違う場合にどこへ戻るか、どの確認が済めば次の段階へ進めるかも示します。

• 管理の全体像 — 顧客・取引・サブスクリプション・請求を結ぶ際に、情報の正本と更新担当を決めます。
• MRRとARRの設計 — 集計対象、金額、日付の扱いをそろえ、契約記録と照合します。
• 更新通知の設定 — 契約条件から準備の開始時点を決め、社内タスクの対象と担当を確かめます。
• 解約リスクへの対応 — 取得できる記録を見極め、通知を受けた担当者が取る行動を定めます。
• 段階的な導入方法 — 更新管理で見つかった不一致を直してから、分析や顧客向け連絡へ広げます。

HubSpotで扱う契約・請求・顧客情報の全体像

サブスクリプション管理を始める前に、どの情報をHubSpotで持ち、どの処理を決済や請求の仕組みに任せるかを決めます。

次の画面は、HubSpotの請求・決済管理を紹介する画面です。自社で利用する機能を確認する際は、画面上の情報と契約・請求の記録がどのように対応するかを確かめてください。

顧客から請求までの情報の流れ

基本の流れは、次のとおりです。

1. コンタクトや会社の登録
2. 商談・契約条件
3. サブスクリプションと請求

契約後の問い合わせや更新協議も顧客の記録に関連付ければ、営業とカスタマーサクセスが対応の背景を確認しやすくなります。

1. まず、更新時に参照する契約を特定します ── 同じ顧客に契約が複数ある場合は、顧客名だけで判断せず、どの契約の更新日・請求状態・対応履歴かを区別します
2. 次に、契約条件の変更が確定したときの更新担当を決めます ── 誰がどの記録を更新するかを決めます

企業様によって最適な形は異なります。契約単位を担当者が特定でき、変更が次の更新対象の抽出に反映される状態を目指してください。

例えば、同じ会社に継続中の契約と更新協議中の契約がある場合、会社単位の一覧だけでは通知先を決められません。

• 契約ごと ── 更新日、現在有効な条件、協議の担当を確認します
• 協議中の契約 ── 合意が確認できるまで「更新完了」の対象に含めず、次に確認する日と担当者を残します

確認する順序は、次のとおりです。

1. 会社を特定する
2. 対象契約を特定する
3. その契約の有効な条件を確認する

• 契約を特定できなければ ── 関連付けに戻ります
• 契約は特定できても変更後の条件が反映されていなければ ── 合意内容を確認できる担当者に戻ります
• 対象と条件を説明できたら ── 更新日と請求結果をそれぞれの記録で確かめ、担当者が次の行動を選べるか試します

表計算で分散した情報を一元化する

表計算で契約一覧を管理し、請求側の顧客名やCRMの会社名を別々に更新していると、表記ゆれや更新漏れを見つけにくくなります。解約申請を受けた際にも、対象契約と過去の問い合わせを結び付けて確認する必要があります。

移行前に、表計算の各列について次を確認します。

• 誰が入力するか
• 何を根拠に更新するか
• HubSpotのどの記録に対応するか

顧客を識別する項目、契約状態、開始日、更新日、請求状態が食い違う場合は、契約書や請求の記録など、確認に使う資料と判断担当を決めてから修正します。

項目ごとに正本が異なる場合は、その違いを記録します。例えば、次のように確認します。

• 更新日 ── 合意済みの契約条件から確認します
• 支払いの結果 ── 請求側の記録で確認します
• 両者が食い違った場合 ── 契約条件と請求結果をそれぞれの担当に確認します

移行する項目は、登録できる範囲と、確認が済むまで保留する範囲に分けます。判断の基準は空欄の数ではなく、その項目を使う業務です。

• 更新日を確認できない契約 ── 日付通知へ進めません
• 金額の意味を確認できない契約 ── MRRの照合対象として区別します

保留した契約には、確認する資料、担当者、確認後に更新する記録を残します。

同じ契約を更新通知と収益集計の両方で使えるとは限りません。

• 更新日を確認できても金額の内訳が不明なら ── 社内の更新準備を進めつつ、MRRへの反映は確認を待ちます
• 金額が確認できても更新日が不明なら ── レポートの対象を判断したうえで、日付通知には含めません

どの業務に使える記録かを契約ごとに示せたら、対象を段階的に広げます。

課金機能とCRM運用の境界

HubSpotでサブスクリプションを管理する際は、請求条件、利用中の決済方法、請求書の処理担当を確認し、請求・支払いの記録先を決めます。既存の決済サービスを使う場合は、次を先に確認します。

• どのデータを同期するのか
• 請求処理の結果をどの契約へ戻すのか

商品カタログに登録する内容は、実際の契約条件と照合します。プラン名や請求周期が契約ごとに異なる場合は、どの情報を商品として共通管理し、どの条件を個別の契約記録で確認するかを決めます。

請求の結果と契約状態が異なる契約では、まず双方の記録がいつ、何を根拠に更新されたかを確かめます。

• 請求結果が不明なら ── 請求担当へ確認します
• 更新条件の合意が不明なら ── 顧客対応の担当へ確認します
• 支払いの問題が解消しても契約条件の協議が続いているなら ── 請求の確認完了と契約更新の完了を分けて記録します

MRR・ARRを追跡するデータを設計する

MRRやARRのレポートは、金額の欄を作るだけでは正確に読めません。先にそろえるものは、次のとおりです。

• 対象とする契約
• 金額の意味
• 契約状態
• 集計する時点

定義を共有してからレポートを作り、表示された値を契約記録から説明できるか確認します。

集計対象と指標の定義を決める

MRRは月次の経常収益、ARRは年次の経常収益を表す指標として使われます。

• 月額契約と年額契約が混在する場合 ── 集計時に月次換算するか、年次契約の受注額を別に見るかを決めておきます
• 初期費用や一時的な追加請求 ── 継続収益に含めると、定期収益の推移が読みづらくなります

次の表を使い、指標ごとの扱いを文書化します。特に、契約開始と受注、解約申請と契約終了のどちらを集計の基準にするかは、契約記録と照らして決めてください。

定義を決めるときは、更新条件を協議中の契約や、解約を申し出ていても契約期間が残っている契約をどう扱うか確認します。

• 申請日と終了日で集計結果が変わるなら ── 採用した基準をレポートの説明に残します
• 協議中でも現在の条件が有効な契約と、変更が合意済みで適用日を待つ契約 ── 分けます
• 担当者が同じ契約を見て異なる判断をした場合 ── 集計を広げる前に定義を見直します

例えば、更新条件の合意日と新しい金額の適用日が異なる契約では、合意しただけで表示額を変えると、その時点で有効な条件を読み違えるおそれがあります。

1. 契約記録で両日を確認し、レポートが「合意済みの将来額」と「現在有効な継続額」のどちらを示すか決めます
2. 目的が混在する場合は表示を分け、担当者がそれぞれの金額を契約条件までたどれることを確認します

集計ルールを比べるときは、同じ契約を使って「受注した時点」「契約が始まる時点」「変更が適用される時点」で表示がどう変わるかを確認します。

• 差が出た契約について、採用した基準、根拠となる記録、変更前後の金額と適用日を説明できたら ── 同じ条件の契約にも適用します
• 現在値の上書きによって過去の条件をたどれなくなるなら ── 集計範囲を広げる前に履歴の記録方法を決めます

必要なプロパティを絞る

取引やサブスクリプションに持たせる項目は、レポートや担当者の判断に使うものから選びます。出発点にする項目は、次のとおりです。

• 契約開始日
• 次回更新日
• 契約期間
• プラン種別
• MRR

利用中のアカウントで管理できる項目を確認してから追加項目を決めます。

表中の項目名や設定場所を確認するときは、どの記録に値を持たせるかも決めます。

• 同じ意味の金額を複数の記録に入力する場合 ── どちらを正本とし、変更時に誰が照合するかを先に定めます
• 正本以外の値が異なったとき ── 更新を待つのか、担当者へ確認を渡すのかも決めておくと、差を見つけた人が判断を止めずに済みます

各項目を「空欄でも更新対応を進められるもの」と「入力がなければ進められないもの」に分けます。例えば、次回更新日が空欄の契約は、日付を起点にした通知の対象にできません。

• 契約条件を確認できれば ── 担当者が日付を確定します
• 確認できなければ ── 根拠を探す担当と確認先を記録します

日付が確定するまでは、日付通知とは別に確認が必要な契約として扱います。

金額の履歴を分析したい場合は、現在値だけを書き換える運用では過去の変化を追えないことがあります。

• 金額の変更 ── 変更前後の金額と適用日をどこで確認するかを決め、必要な場合に記録方法を設けます
• 項目を増やす前 ── その項目から判断する行動と、値が誤っていた場合の修正担当を説明できるか確かめてください

次の表は、契約の開始日を記録する項目の例です。項目名だけで利用先を決めず、契約のどの記録に値を置くか、既存の項目を使うか追加するかを確認してください。

更新日やMRRの項目も、同じ考え方で記録先と更新担当を決めます。

レポートで収益の変化を読む

レポートでは、次を分けて確認します。

• MRRの推移
• プラン別の構成
• 追加された継続収益
• 失われた継続収益

単一の合計値だけでは、顧客数の変化と契約内容の変化を切り分けにくいためです。

照合する順序は、対象契約、対象期間、金額の意味です。

• 契約が含まれていなければ ── 状態と関連付けを確認します
• 契約は含まれているのに計上時点が異なれば ── 日付の定義を確認します
• 時点は合っていても金額が異なれば ── 換算方法や一時費用の扱いを確認します

原因を説明でき、同じ条件の契約でも同じ結果になることを確かめてから、継続して見るレポートにします。

利用するレポートや自動化の構成は、アカウントの契約内容と利用できる機能を確認して決めます。請求レコードを作れることと、通知・分析を自動化できることを分けて確認してください（出典：HubSpotでサブスクリプションを作成する）。

顧客に複数の契約がある場合は、会社全体の金額だけを見ず、どの契約の金額と更新日が集計に含まれているか確かめます。

• 契約単位の説明ができない場合 ── 顧客と契約の関連付けを見直してから、プラン別や期間別の比較に進みます
• チャーンレートの推移を見る場合 ── 解約申請と契約終了のどちらを集計の基準にするか決め、対象期間に含めた契約を契約記録で確認します

レポートを確認する際は「レポート > ダッシュボード」を開き、表示した指標の対象期間と契約記録を照合します。

1. 差が見つかったら、その契約が集計対象か、どの日付で計上されたか、どの金額が使われたかを順に調べます
2. 原因を記録して定義または契約情報を直します
3. 同じ契約で再度照合できたら比較対象を広げます

次の画像は、HubSpotデータベース設計図（オンボーディング・契約・MRR月次収益）です。顧客と契約の関係を確認し、MRRをどの契約記録から説明するか考える際に参照してください。

更新通知をワークフローで仕組み化する

更新連絡を担当者の記憶や個人用の予定表だけに任せると、引き継ぎや担当変更のたびに確認が必要になります。更新日を契約情報に持ち、日付を基準にタスクや通知を作れば、次の行動をチームで共有できます。

自動化する前に、次を決めます。

• 準備の開始時点
• 対象外にする状態
• 通知後の判断担当

通知の段階と担当を決める

更新通知日は、契約上の連絡期限から、条件変更の確認、社内承認、請求準備に必要な期間を逆算して決めます。

• 契約ごと ── 期限と変更条件を確認し、同じ条件で扱える契約を整理します
• 準備が期限に間に合わない契約 ── 通常の通知対象にまとめず、担当者が契約上の期限と未完了の作業を確認して個別の対応を決めます

通知の時点を決める際は、連絡期限が確認できるか、条件変更に社内承認が必要か、請求準備を誰が始めるかの順に見ます。

• 条件が共通なら ── 同じ準備手順を使えます
• 期限や承認手順が異なるなら ── 契約ごとに日程を決め、違いを担当者が確認できるようにします

• 準備を始める時点 ── 担当者が契約条件と過去の合意を確認します
• 更新判断の時点で条件変更や解約の意思表示があれば ── 通常の案内から外し、協議の担当と次の確認日を記録します
• 更新日 ── 条件の合意、契約状態、請求状態、対応結果を照合します。未確認の項目が残る場合は完了とせず、確認先を決めます

これらの判断を担当者が行えることを確かめてから、顧客向け連絡の自動化を検討します。

日付を基準にワークフローを組む

更新通知の対象は、更新日が入力され、契約状態を確認できるレコードに絞ります。

日付を基準とする設定を検討する際は、利用中のアカウントで設定できる登録条件と実行時点を確認します（出典：スケジュールに基づくワークフロー登録トリガーを設定する）。

設定の流れは次のとおりです。

1. 更新日が正しく入っている契約を確認します。空欄なら契約条件の確認先を決め、過去の日付なら未対応の更新か入力誤りかを調べます。日付の根拠が確定した契約から対象にします。
2. 契約上の連絡期限と必要な準備から開始時点を決め、日付を基準にした登録条件を設定します。条件が異なる契約を同じ通知で扱うかは、担当者の確認作業と期限が共通かどうかで判断します。
3. 契約状態に加え、解約申請や条件交渉など、通常の更新案内から外す状態を確認します。除外した契約にも対応が必要なら、協議や確認の担当タスクにつなげます。
4. 社内タスクや通知に、対象契約、更新日、確認すべき条件、対応結果の記録先を含めます。担当者が契約を特定できない通知は、内容を直してから運用します。
5. 状態や更新日が異なる契約で動きを確かめます。通常更新の契約に通知が届き、協議中の契約は通常案内から外れ、日付未確定の契約には確認担当が付くかを見ます。対象と担当者に渡る情報が意図どおりなら、運用範囲を広げます。

試す契約には、次を含めます。

• 通常更新
• 条件協議中
• 更新日未確定
• 更新日が変更された契約
• 担当者が交代した契約

通知が届いたかに加え、変更前の条件による案内を止められるか、対象外の契約にも確認担当が付くかを確認します。判断に必要な情報がタスクからたどれなければ、通知内容か契約の関連付けを直します。

運用開始後に意図しない通知が出た場合は、その契約の状態、更新日の根拠、登録条件を照合します。

• どの条件が通知を生んだかを説明できてから ── 修正し、同じ状態の契約で再び確かめます
• 更新日や担当者の変更後にも古い条件でタスクが残る場合 ── そのタスクの扱いと変更後の通知を確認し、担当者が参照すべき記録をそろえます

日付を基準にしたワークフローは、「自動化」>「ワークフロー」から設定します。

顧客への連絡と請求処理を分ける

更新日の通知は、請求や契約の自動更新そのものと同じではありません。自動課金を利用する場合も、顧客への案内、更新条件の合意、決済結果の確認は別の業務として設計します。

顧客向け連絡を検討する前に、解約申請、条件変更の協議、支払い状況に応じて送信を止める条件を確認します。

• 送信を止めた契約 ── 放置せず、誰が何を確認すれば案内を再開できるか記録します
• 請求側で支払いが失敗した場合 ── 結果を確認する担当と連絡履歴の記録先を決めます
• 支払いが解消しても条件変更の協議が続いている契約 ── 通常の更新案内へ戻しません

解約リスクの兆候を対応につなげる

解約リスクへの対応は、スコアを自動計算することだけでは進みません。利用状況、問い合わせ、顧客からの評価、決済状況など、実際に取得できる情報をもとに確認を促し、担当者が次の対応を決められることが重要です。

通知を作る前に、次をそろえます。

• 記録の出所
• 意味
• 対応先

利用できる兆候を選ぶ

利用状況の変化、サポート問い合わせ、顧客評価、決済失敗、担当者の変更について、HubSpotで確認できる記録と、別の仕組みで確認する記録を分けます。

• 表にある記録が自社で取得できるかを先に確かめ ── 取得できない兆候は判定に含めません
• 決済に関する行 ── 請求状態を確認する場合と、Stripe Webhookによる通知を利用している場合を分けて示しています
• 通知を受けた場合 ── 対象契約を特定して請求側の現在の結果と照合します
• 表の掲載順や通知の取得方法 ── 対応の優先順位を示しません

以下は、担当者が確認する記録と行動の例です。

この表は確認作業の入口です。次の順に確認します。

1. まず対象契約を特定し、記録が作られた時点と現在の状況を照合します
2. 次に、契約上の期限、顧客への影響、すでに進んでいる対応を確認します

通知の種類だけで優先度を固定せず、未解決の内容と対応期限を担当者が判断します。

• 決済失敗の通知があっても請求側で解消済みなら ── 記録と対応履歴を照合します
• 未解決なら ── 請求担当と顧客対応の担当が次の行動を決めます

Stripe Webhookによる通知を利用している場合も、通知だけで現在の支払い状況を判断しません。

• 通知を利用している場合 ── 対象契約と請求側の現在の結果を確かめ、契約上の期限や顧客への影響を踏まえて対応を決めます
• 対象契約を特定できない通知 ── 確認先と担当者を付けます
• 通知を利用していない契約 ── 請求状態など実際に確認できる記録から同じ順序で判断します
• どちらの場合も、請求側の結果と顧客への連絡履歴が食い違えば ── 先に更新時点を確認します

問い合わせが増えたという事実だけで解約リスクと決めつけないことも大切です。問題解決のために積極的に連絡している顧客もいます。

• チケットの内容と未解決事項を確認し、顧客評価とも食い違うなら ── 担当者が背景を調べます
• 記録が古い、または出所を確認できない場合 ── 通知条件に加える前に情報の更新方法を決めます
• 担当者が次の行動を選べない情報 ── 使い道を見直します

次の表は、解約リスクの確認に使う指標と検知方法、社内での対応を検討するためのレベルの例です。レベルは顧客の状態を示す確定値ではありません。

評価の低下と未解決の問い合わせが同時に見られる場合も、両方が同じ課題を指すかを担当者が確かめてから対応を決めます。

表の「中」「高」は社内で確認を始めるための設定例で、解約の確率や対応順を示しません。どちらの表示でも、次の順に進めます。

1. まず回答や問い合わせがどの契約に関するものかを確認し、顧客が伝えた内容、未解決の問題、確認できていない点を分けます
2. 次に、契約上の期限と顧客への影響を見て、顧客へ連絡するか、社内で解決状況を確認するかを担当者が決めます

低いレベルの記録でも期限内の対応が必要なら、その期限に合わせて担当を決めます。

• 解消済みの事象にレベルが付いたまま残る、または表示されたレベルと必要な対応が合わない場合 ── レベルの付け方と通知後の手順を見直します
• 判定を運用に使う前 ── 担当者が同じ記録を見て同じ確認先を選べること、対象契約と未解決の内容を説明できることを確かめます

スコアを行動基準に変える

リスクスコアを使う場合は、誰が更新し、どの情報を根拠にし、どの状態になったら誰が対応するかを明らかにします。まずは、チーム内で判断できる次のような状態から始められます。

• 要確認
• 対応中
• 解消

「要確認」にする際は、確認した事実と未確認の点を記録します。

• 担当者の選択 ── 顧客への連絡、社内相談、状況観察のどれが必要かを選び、次に確認する条件を残します
• 「対応中」から「解消」へ移す条件 ── 連絡したことだけでなく、何を確認して課題が解消したと判断するかで定めます
• 同じ種類の通知が続いても対応につながらない場合 ── 通知条件か担当の割り当てを見直します

HubSpotに残すのは、対象契約に結び付く記録、対応状態、担当者、判断結果です。AIを使う場合は、問い合わせ履歴の要点と未確認事項の整理を補助させます。

例えば、複数のチケットに同じ問題が書かれているように見えても、担当者は元のチケットを読み、未解決の問題なのか、別々に解決済みの相談なのかを確かめます。

• 未解決なら ── 対応担当と次の確認日を決めます
• 解決済みなら ── スコアや通知条件に反映すべきか見直します

役割を決める際は、次のようにします。

• HubSpotの記録 ── 判断の根拠
• AIの整理結果 ── 確認作業の補助
• 担当者の確認 ── 対応決定の条件

• AIが「解約リスクが高い」と整理しても、根拠となる問い合わせが別の契約に関するものなら ── その整理結果を対象契約の判定に使いません
• 元の記録を特定でき、内容と現在の状態を担当者が確認できた場合 ── 対応状態へ反映します

AIに整理を任せる前に、対象の契約と参照する履歴を担当者が指定します。

• 整理結果 ── 顧客が伝えたこと、社内で確認したこと、まだ確認できないことを分けて示し、参照した記録に戻れるようにします
• 契約を取り違えた要約や、解決済みの問い合わせを未解決として扱った要約があれば ── 担当者が元の記録と照合して訂正します

確認できた事実に基づいて次の対応を決め、その後に対応状態を更新します。

更新対応でも同じ順序を使います。

1. HubSpotの契約記録で更新日、担当、合意した条件を確認し、AIが整理した問い合わせの要点を元の記録と照合します
2. 条件変更の協議が必要なら通常の更新案内から外し、協議担当と次の確認時点を残します
3. 記録と整理結果が一致し、送信条件を担当者が確認できた契約から次の対応へ進めます

失注や解約から次の改善へつなげる

解約が発生した場合は、理由を記録して終わりにせず、契約・利用状況・問い合わせ履歴と合わせて振り返ります。

分類は、次のようなものを自社の実情に合わせて用意し、営業やカスタマーサクセスから製品・マーケティングへ共有できる形にします。

• 価格
• 機能
• 導入時期
• 社内事情など

理由を分類する前に、顧客が伝えた内容と社内の推測を分けて記録します。

• 分類に迷う事例が続く場合 ── 選択肢の意味を担当者間で確認します
• 振り返りから改善する業務が決まったら ── 担当と見直す条件を残します
• 次の契約でも同じ課題が見られるかを確認できれば ── 入力項目を増やす目的も明確になります

業務に合わせたパイプラインと段階導入

すべての契約を同じステージで管理する必要はありません。トライアルから有料化するサービスと、年間契約の更新提案が中心のサービスでは、担当者が判断する節目が異なります。

自社の契約プロセスに合わせ、ステージを移す条件と必要な記録を決めます。

契約の進行段階を定義する

例えば、次のような流れがあります。

• SaaSのトライアルから ── 有料契約、更新、解約に至る流れ
• 年間契約の更新提案から ── 条件交渉、更新または解約に至る流れ

ステージ名だけでなく、何が確認できたら次へ移すかを担当者間でそろえます。

例えば、更新提案を送った段階と、条件の合意を確認した段階を同じ「更新完了」にすると、一覧から未確定の契約を区別できません。

• 提案中 ── 担当と返答待ちの内容を残します
• 合意後 ── 根拠となる記録を確認してステージを移します

各ステージについて、移行を判断する資料、更新担当、未確定時の扱いを決めてください。

• パイプラインを収益予測にも使う場合 ── ステージの定義と、予測に含める契約をそろえる必要があります
• 契約獲得と既存契約の更新を同じ流れで管理するか ── 担当者の作業とレポートで両者を区別できるかを確かめて判断します

少数の項目から始めて広げる

• 初期段階 ── 契約状態、更新日、担当者、MRRなど、更新判断やレポートに直接使う項目に絞ります
• 担当者が入力する意味を説明しづらい項目 ── 追加を見送り、運用後に不足が具体化した時点で検討します

次の段階へ進む前に、確認する結果を決めます。

1. 更新対象の抽出結果で契約、更新日、担当者を説明できたら ── 社内通知を試します
2. 通知で通常更新と個別協議を区別でき、対応結果を記録できたら ── MRRレポートを契約記録と照合します
3. 差が残る場合 ── 指標の定義か契約記録に戻って確認します
4. 外部データ ── それによって変わる判断と、更新が止まったときの確認担当が決まってから加えます

段階を進める判断には、正しく処理できた契約だけでなく、保留した契約も使います。保留の理由が次のどれかを分け、各担当が確認先を示せるか確かめます。

• 契約を特定できない
• 日付の根拠がない
• 金額の意味が異なる

保留の扱いを説明できないまま対象を広げると、通知や集計の差を後から追いにくくなります。

手作業ではなく運用ルールで引き継ぐ

更新漏れを個人の注意力で補うのではなく、次を仕組みにします。

• 更新日が登録されていない契約を見つける方法
• 更新タスクの担当を決める方法
• 対応結果を記録する場所

担当交代時には、未完了タスクだけでなく、どの契約条件を確認済みかも引き継ぎます。

運用開始後は、更新日が空欄の契約、期限を過ぎても完了していないタスク、請求状態と契約状態が異なる契約をそれぞれ確認します。

• 空欄なら ── 入力の根拠と担当を調べます
• 未完了なら ── 作業が止まった理由を調べます
• 状態の不一致なら ── 請求結果と顧客との合意を調べます

原因に応じて入力ルールや通知条件を直し、同じ条件で再び対象を抽出できるか確かめます。レポートを広げるのは、こうした差を担当者が説明し、修正できる状態になってからです。

よくある質問

HubSpotでサブスクリプションの請求処理もできますか？

まず、利用する請求・決済の方法と、アカウントで使える機能を確認します。そのうえで、契約条件を記録する担当、請求を実行する担当、結果を確認する担当を決めてください。請求結果が契約状態と異なる場合は、支払い結果が未確認なのか、契約条件の記録が未更新なのかを調べます。確認先と修正担当まで決めると、更新対応でどちらの情報を調べるべきか明確になります。

MRRはHubSpotで自動集計できますか？

サブスクリプションデータを使った継続収益の分析やレポートを構成できます。集計対象、年額契約の月次換算、一時費用の扱いが決まっていないと数字の意味がそろいません。まず計算ルールを文書化し、新規契約、条件変更、解約申請など、扱いが分かれる契約記録とレポートの結果を照合します。差が出たら、対象契約、日付、金額の順に原因を確認してから利用範囲を広げます。

更新通知を顧客へ自動送信できますか？

日付を基準にしたワークフローで、条件に合うレコードへのアクションを設定する方法があります。顧客へ送る前に、契約状態、解約申請、条件交渉の有無を確認できるようにします。まず社内通知で対象と担当が正しいか試します。送信を止めるべき契約を区別でき、止めた契約にも確認担当と次の行動を残せるようになったら、顧客向け連絡を検討します。

解約リスクのスコアはどのように決めますか？

利用状況、問い合わせ、顧客評価、決済状態のうち、取得できて意味を確認できる情報から選びます。スコアを作る場合は、根拠となる項目、更新担当、通知後の行動を合わせて定義します。決済失敗などの通知は、対象契約と現在の請求結果を照合してから対応を判断します。点数や通知の種類だけで対応順を決めず、未解決の事実、契約上の期限、顧客への影響を確認します。情報の更新や解釈がそろわない段階では「要確認」などの状態で管理し、担当者が事実と未確認の点を記録します。対応後に何を確認すれば「解消」とするか決めてから、判定を広げます。

どこから導入を始めるとよいですか？

現在の契約一覧で、対象契約、更新日、担当者を確認するところから始めます。契約を特定できない場合は関連付けを、日付が不明な場合は契約条件を先に確かめます。次に、更新対象を抽出して社内タスクを試し、契約状態と請求状態の差を確認します。対象と対応結果を説明できるようになったらMRRレポートを契約記録と照合し、その後に顧客向け連絡や解約兆候の分析を検討します。

まとめ

HubSpotでサブスクリプション売上を管理するときは、顧客情報、契約、継続請求、更新対応を関連付け、担当者が対象契約と判断の根拠を確認できる状態を目指します。

• MRRやARR ── 集計対象と契約状態、金額、日付の扱いを決めてからレポートにします
• 更新通知 ── 社内対応で対象と担当を確かめ、顧客連絡や請求処理の条件を整理してから広げます

まずはHubSpot上で更新日と担当者を確認し、担当者が未設定のレコードと更新状況を一覧にしてください。次を分けると、修正すべき情報と導入範囲を判断できます。

• 契約を特定できないもの
• 日付の根拠を確認できないもの
• 請求状態が食い違うもの

1. 現在の契約一覧から、顧客の識別情報、契約状態、更新日、担当者を確認します。食い違う情報は、根拠となる記録と修正担当を決めます。
2. HubSpotで管理する項目と、請求や決済の仕組みで管理する項目を分けます。請求結果と契約状態が異なる場合の確認先も決めます。
3. 更新日を基準とした社内タスクを試し、対象、担当、対応結果を確認します。通常更新と個別確認が必要な契約を区別できたら、レポートや顧客通知へ広げます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

契約情報を収益レポートに反映する方法、決済結果の確認、商品情報の整理を深めたい場合は、次の記事を参照してください。

MRRの集計対象と金額・日付のそろえ方、支払い結果と対象契約の照合、商品カタログと個別の契約条件の分け方を、それぞれ確認できます。

• HubSpotの収益管理レポート｜ARR・MRR・チャーンレート・LTVダッシュボードの構築
• HubSpot × Stripe決済連携ガイド｜サブスク課金からWebhook設定まで完全解説
• HubSpot商品カタログ（プロダクトライブラリ）の設定方法｜商品マスタ・価格表・バンドル設計

カテゴリ: Revenue Hub | HubSpot