スクール事業のCRMデータ設計｜見込み・受講生・保護者をどう持つか

スクール事業のCRMデータ設計の結論は、保護者・受講生・在籍（どのコースに通っているか）の3つを別々のレコードとして持つ、という一点に集約されます。 保護者と受講生はどちらもコンタクトで持って関連付けラベルで家族関係を表し、在籍は多くの場合、取引レコードとして独立させるのが扱いやすい形です。 そのうえで、入会後の状態はステージではなくプロパティー（在籍状態・開始日・終了日・退会理由）で持つと、継続率が測れる構造になります。

「メールを送る相手」と「教室に来る人」が違う——スクール事業でCRMを設計すると、最初にここで手が止まります。

子ども向けの教室、学習塾、スポーツスクール、音楽教室。これらの事業では、体験を申し込むのも、月謝を払うのも、退会を決めるのも保護者です。しかし実際に通い、満足するかどうかを左右するのは子どもです。顧客は1人ではなく2人いる、というのがスクール事業のデータ設計の出発点になります。

さらに複雑なのは、1人の保護者に子どもが複数いる場合と、1人の子どもが複数のコースに通う場合です。これを「コンタクト1件＝顧客1件」という一般的なCRMの前提で表現しようとすると、必ずどこかで破綻します。

スクール事業のCRMデータ設計とは、保護者・受講生・在籍（どのコースに通っているか）という3つの単位を分けて持ち、継続を数字で見られる形にする作業です。名簿を作る作業ではなく、継続率が測れる構造を作る作業だと考えてください。

この記事では、HubSpotを例に、スクール事業のデータ設計を整理します。教室やスクールを運営していて管理をExcelから移したい方、複数教室を展開していて全体の数字が見えずに困っている方に向けた内容です。次の4点がわかります。

• 保護者と受講生をどう持つか ── 2人を1レコードにまとめてはいけない理由を示します
• 在籍をどのレコードで表すか ── 取引で持つ場合とカスタムオブジェクトで持つ場合の分岐点です
• コース変更・休会・退会の記録 ── 状態をステージで持つか、プロパティーで持つかの判断軸です
• 継続を数字で見る設計 ── 何を最初から持たせておくべきかを説明します

読み終える頃には、自社のスクール運営をどの単位でレコード化するかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

スクール事業のCRMが難しい理由

まず、なぜ一般的な顧客管理の設計が当てはまらないのかを整理します。理由は事業構造と登場人物の2つに分かれます。スクール事業は1件売って終わりではなく、毎月の月謝が数年にわたって積み上がる収益構造を持ちます。しかも、お金を払う人と実際にサービスを受ける人が別人です。この2点があるために、商談を追いかける形の一般的なCRM設計をそのまま持ち込むと、途中で必ず表現できない関係が出てきます。ここを先に押さえておくと、この後のレコード設計で「なぜ単位を3つに分けるのか」が腹落ちし、判断に迷いにくくなります。

継続がすべてを決める事業構造

文部科学省の「令和5年度子供の学習費調査」によれば、保護者が支出した1年間・子ども1人当たりの学校外活動費（塾・習い事などの費用）は、公立小学校で256,489円、公立中学校で356,018円、公立高等学校（全日制）で245,431円でした。学習費総額は公立小学校で366,599円、公立中学校で542,450円となっています（令和5年度子供の学習費調査結果のポイント、令和6年12月25日公表・令和8年1月16日訂正版）。

この金額は年額であり、複数年にわたって継続します。つまりスクール事業の売上は、新規獲得よりも継続の長さに強く依存します。1件の入会が生む価値は、初月の月謝ではなく、通った期間の合計です。

だからこそ、CRMで最初に測れるようにすべきなのは新規獲得数ではなく、在籍期間と退会理由になります。

「申し込む人」と「通う人」の分離

スクール事業の登場人物を整理すると、次のようになります。

成人向けスクールでは保護者と受講生が同一人物になりますが、子ども向けの事業では必ず分かれます。そして退会の判断は保護者が下すため、保護者との関係が切れると継続しません。

1対1にならない関係

さらに、次の関係が同時に成立します。

• 1人の保護者に、複数の子どもがいる
• 1人の子どもが、複数のコースに通う
• 1つのコースに、複数の子どもが在籍する

この多対多の関係を、コンタクト1件では表現できません。ここが設計の核心になります。

保護者と受講生を分けて持つ

ここからが設計の本体です。最初に決めるのは、保護者と受講生をどのオブジェクトに置き、その関係をどう表現するかの2点です。ここを固めておくと、後から在籍や請求の設計を足しても崩れません。

これは特定の企業の実装ではなく、スクール事業でよく出てくる構造を一般化した設計例です。

どちらもコンタクトで持つ

結論から書くと、保護者と受講生は、どちらもコンタクトオブジェクトのレコードとして別々に持ちます。カスタムオブジェクトを新設する必要はありません。

理由は3つあります。

• どちらも「人」であり、氏名・連絡先という同じ構造を持つ
• 子どもが成長して成人向けコースへ移る場合、同じレコードのまま扱える
• コンタクト同士の関連付けが標準で使えるため、家族関係を表現できる

HubSpotでは、異なるオブジェクトのレコードだけでなく、同じオブジェクトのレコード同士（コンタクトとコンタクトなど）も関連付けられます（レコードを関連付ける）。

家族関係は関連付けラベルで表す

保護者と受講生の関係には、関連付けラベルで名前を付けます。関連付けラベルの利用にはProfessional以上のサブスクリプションが必要です。

このように持つと、「この保護者の世帯に何人在籍しているか」と「この子が過去にどのコースに通ったか」を、同じデータから両方取り出せます。

どちらにメールを送るかを決める

保護者と受講生を分けたら、次に決めるべきはマーケティングの対象をどちらにするかです。

• 教室からの連絡・請求・イベント案内 → 保護者
• 学習内容のフォロー・本人向けの声かけ → 受講生（年齢による）

ここを曖昧にすると、子どものメールアドレスに請求案内が届くといった事故が起きます。コンタクトごとに「連絡区分」を持たせ、配信リストは必ずこの区分で絞る設計にしてください。子どものメールアドレスを持たない運用にする、という選択も現実的です。

在籍をどのレコードで持つか

3つ目の単位が「在籍」です。保護者と受講生を分けただけでは、「どのコースに、いつから通っているか」を表現できません。ここを独立したレコードにできるかどうかが、継続率を測れる設計とそうでない設計の分かれ目になります。

在籍とは何か

在籍とは、「誰が、どのコースに、いつからいつまで通っているか」という1件です。受講生1人が3つのコースに通っているなら、在籍レコードは3件になります。

この単位を持たないと、次のことができません。

• コース別の在籍者数を数える
• 1人当たりの受講コース数を出す
• コースを変えた場合に、前のコースの期間を残す

受講生のコンタクトに「受講コース」というプロパティーを1つ持たせる設計は、必ず行き詰まります。複数コースが持てず、履歴も残らないためです。

取引で持つかカスタムオブジェクトで持つか

多くのスクールでは、在籍を取引で持つ設計が扱いやすいです。月謝額を金額として持て、体験から入会までのプロセスをパイプラインで管理でき、レポートも標準機能で作れます。

カスタムオブジェクトの作成には、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hub のいずれかの Enterprise が必要です（カスタムオブジェクトを作成する）。判断の考え方はHubSpotでカスタムオブジェクトを作るべきかの判断基準にまとめています。

判断に迷ったときの起点

判断の起点は、「その単位で金額を集計したいか」です。在籍ごとの月謝と継続期間を見たいなら取引、名簿として持てれば足りるならカスタムオブジェクトでも構いません。同じ判断軸を法人研修事業に当てはめた例は研修の管理システムを設計するで扱っています。

入会前の「見込み」をどこに置くか

ここまでは在籍中の話でしたが、その手前にまだ入会していない見込みの家庭がいます。資料請求だけした人、体験に申し込んだが来ていない人、体験に来たが決めていない人。この層をどこに置くかで、設計の使いやすさが変わります。

結論は、在籍レコードを入会前から作る設計です。体験の申し込みが入った時点で在籍レコードを1件作り、パイプラインのステージで「申込受付」から始めます。入会が決まればそのレコードがそのまま在籍になり、決まらなければ失注としてクローズします。

この形にする理由は3つあります。

• 体験から入会までの歩留まりが、同じレコードの遷移として自然に取れる
• 入会後に「どのコースの体験から入ったか」が履歴として残る
• 見送りになった家庭にも、見送り理由と体験日が残り、後から再アプローチできる

逆に、入会したときに新しくレコードを作り直す設計にすると、体験から入会までの日数も、体験を担当した講師も、繋がらなくなります。作り直さず、状態を進める。ここが設計の分かれ目になります。

なお、資料請求だけで体験に至っていない層は、在籍レコードを作らずコンタクトのライフサイクルステージだけで管理する形が扱いやすくなります。すべてを在籍レコードにすると、実体のないレコードが溜まります。プロセスの詳しい設計は体験申込から入会・継続までのパイプライン設計で扱っています。

コース変更・休会・退会をどう記録するか

スクール事業で最も設計が問われるのが、この部分です。入会後の変化は、レコードを新しく作るのではなく、既存のレコードの状態を更新する形で起きます。ただし、すべての変化を上書きしてよいわけではありません。コースを変えた、しばらく休む、辞めた——この3つは現場では地続きの出来事ですが、データとしての扱いはそれぞれ違います。どの変化を上書きしてよく、どの変化で新しいレコードを作り、どの変化を履歴として残すのか。この線引きを、運用が始まる前に決めておく必要があります。決めずに走り出すと、1年後に継続率を出そうとした段階で、過去が復元できないことに気づきます。

状態はステージではなくプロパティーで持つ

入会した後の在籍は、パイプラインのステージを進める対象ではありません。数か月から数年、同じ状態が続きます。

ここで「通塾中」「休会中」といったステージを刻もうとすると、誰も動かさないステージができます。入会でパイプラインはクローズし、在籍中かどうかは別のプロパティー（在籍状態）で持つ設計が扱いやすくなります。

退会理由と休会理由は、必ず選択肢型にしてください。自由記述にすると集計できず、改善に使えません。

コース変更は「終了」と「開始」で表す

コースを変えたときに、既存の在籍レコードのコース名を書き換えてはいけません。書き換えると、前のコースにどれだけ通っていたかが失われます。

正しくは、前の在籍を終了日を入れてクローズし、新しい在籍レコードを1件作ります。こうすると、その子の受講履歴が時系列で残ります。

休会と退会を区別する

休会は復帰の可能性がありますが、退会にはありません。この2つを同じ扱いにすると、復帰の見込みがある層へのアプローチができなくなります。

休会には「休会開始日」と「復帰予定日」を持たせ、復帰予定日が近づいたらタスクを自動生成する設計にすると、復帰率が上がります。ワークフローの組み方はHubSpotワークフローの設定ガイドを参考にしてください。

継続を数字で見る

設計が正しいかどうかは、必要な数字が取れるかで判定できます。スクール事業の場合、判定に使うのは新規獲得の数字ではなく、継続に関わる数字です。次の6つが取れる状態になっていれば、ここまでの設計は機能しています。

HubSpotの計算プロパティーには、関連レコードの値を集計するロールアップ機能があり、件数・合計・最早の日付・最新の日付などを取得できます。計算プロパティーはProfessional以上で利用できます（計算プロパティーを作成する）。

これを使うと、保護者のコンタクトに「世帯の在籍数」「初回入会日」を自動で持たせられます。この2つがあるだけで、兄弟入会の提案リストが作れます。

このうち退会理由と開始日は、後から設計を変えると過去分が取れません。最初から持たせておく価値が最も高い項目です。

よくある質問

スクール事業のCRMデータ設計について、ご相談の場でよくいただく質問をまとめました。保護者と受講生を分ける必要が本当にあるのか、在籍を取引で持つと件数が膨らまないか、月謝の入金管理までCRMでやるべきか、複数教室をどう持つか、Excelから何を先に移すか、の5点です。いずれも設計に入る前に方針を決めておく論点で、ここが固まっていると後戻りが減ります。

Q1. 保護者と受講生を1つのコンタクトにまとめてはいけませんか。

成人向けスクールで受講者本人が申し込む場合は、1つで構いません。子ども向けの場合は分けてください。まとめると、兄弟が2人通っているときに1レコードでは表現できず、子どもごとの在籍履歴も残せません。「1人の保護者に複数の子ども」が発生し得るなら、分けるのが前提です。

Q2. 在籍を取引で持つと、取引の件数が多くなりすぎませんか。

在籍者数が数百人から数千人の規模であれば、取引の件数として問題になりません。数万件を超える規模になると、レポートの応答が重くなる場面が出てきます。その場合は、退会済みの在籍をアーカイブ用のパイプラインへ移すか、在籍をカスタムオブジェクトへ移す検討に入ります。最初から件数を心配して複雑な設計にする必要はありません。

Q3. 月謝の入金管理までCRMでやるべきですか。

入金の確定値は会計側に置き、CRM側は「請求ステータス」程度を持つ設計をおすすめします。境界の目安は、「会計の正確性が問われるものは会計側、判断と経緯はCRM側」です。ただし、未納が続いていることは退会の強い兆候なので、未納の事実だけはCRMから見えるようにしておく価値があります。

Q4. 複数教室を運営しています。教室はどう持てばよいですか。

教室は会社オブジェクトのレコードとして持ち、在籍レコードに関連付ける方法が扱いやすくなります。教室ごとの在籍数・退会率を集計でき、担当講師の割り当ても表現できます。教室数が2〜3で当面増えないなら、在籍のプロパティー（選択肢型）で持つ簡易な設計でも構いません。将来的に教室ごとの損益を見たくなるかどうかが判断の分かれ目です。

Q5. すでにExcelで名簿を管理しています。何から移せばよいですか。

現在在籍している人だけを移してください。過去の退会者まで含めて移そうとすると、データの整合を取る作業で止まります。在籍者を移し、開始日と在籍状態と退会理由の3項目を持たせて運用を始める。過去分は、必要になったときに追加でインポートすれば足ります。名簿の完全性より、今日から新しい退会が正しく記録される状態を先に作るほうが価値が出ます。

関連記事

• 体験申込から入会・継続までのパイプライン設計 ── 体験からの歩留まりを分けて数える設計です
• 教育業界のHubSpot活用法 ── 教育業界でのHubSpot活用の全体像をまとめています
• 教育・スクール業DX実践ガイド ── 教育・スクール業のDX全般を扱っています
• 研修の管理システムを設計する ── 同じ判断軸を法人研修事業に当てはめた例です
• HubSpotでカスタムオブジェクトを作るべきかの判断基準 ── 在籍を取引で持つかカスタムオブジェクトで持つかの判断に使えます

まとめ

スクール事業のCRMデータ設計は、名簿を作る作業ではなく、継続が測れる構造を作る作業です。要点を整理します。

• 保護者と受講生は別のコンタクトで持ち、関連付けラベルで家族関係を表す。1対多が成立するためです
• 在籍を独立したレコードとして持つ。受講生のプロパティーにコース名を1つ持たせる設計は必ず行き詰まります
• 在籍は取引で持つのが扱いやすい。金額を持て、入会プロセスをパイプラインで管理できます
• 入会後の状態はステージではなくプロパティーで持つ。数年続く状態をステージで刻むと、誰も動かさないステージができます
• コース変更は書き換えず、終了と開始で表す。書き換えると受講履歴が失われます
• 退会理由と休会理由は選択肢型にする。自由記述では集計できず、改善に使えません
• 配信対象は連絡区分で必ず絞る。子どものアドレスに請求案内が届く事故を防ぎます

最初の一歩としておすすめしたいのは、「直近1年に退会した人を10件選び、退会理由を分類してみる」ことです。分類できないなら、それが今の管理で失われている情報です。10件分類するだけで、選択肢に何を並べるべきかが見えてきます。

そのうえで、在籍レコードに「開始日」「在籍状態」「退会理由」の3項目を持たせる。ここから始めるのが現実的です。

自社のスクール運営に合わせたCRM設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の管理方法をうかがったうえで、設計の方向性をご提案します。