NotionだけでSFA/CRMを作ろうとしたら、考えることが多すぎてNotionの解説どころじゃなくなった話

どーもばるすです。

アドベントカレンダー2025、9日目の記事です。
（予約公開を入れておいたはずなんですが、設定ミスってました）

Cloudnative IRS Advent Calendar 2025 – Adventar

はじめに

SFA/CRMってNotionで作れますか？

商談でご質問いただくことが稀にあるんですが、正直あまりオススメしていません。

個人情報や営業情報を扱うにはNotionは自由度が高すぎて怖いし、作っていく過程がふつーにしんどいんですよ。

Notionを触る前にSFA/CRMを考えるときに抑えておきたい要素が山のように出てきて、途中からNotionの話じゃなくなるんです。完全に。

なので、この記事ではNotionのノウハウ解説ではなくSFA/CRMと向き合う際に整理しておくべきことをメインにご紹介します。
▼注意点
SFA/CRM設計において、本稿で触れる要素以外にも考えるべき点や定義する事項があります。
全てのケースを網羅してお伝えするのは難しい点、予めご留意いただけると助かります。

では、Let’s do this。（最近葛葉さんにハマっている）

例として架空の2社を定義しておきます。

• A社（BtoB SaaS）
  • 中小企業向けのクラウド勤怠管理システムを提供
  • 従業員50名くらい
  • 顧客は「法人」
• B社（BtoC ジム）
  • 駅前のパーソナルトレーニングジム
  • トレーナー数 5 名
  • 顧客は「個人」

この2社を頭に置きながら読み進めてもらえると、「あ、自分の会社だとこうなるな」が見えやすいかなと思います。

まず最初に：自社の事業プロセスをざっくり理解する

いきなりNotionのデータベースを作り始める前に、まずここから。
ここをフワッとしたまま進めると、途中で必ず「何を軸に管理してるんだっけ？」と迷子になります。

最低限確認しておきたいのはこのあたりですかね。掘れば掘るほど増えるけど一旦これくらいに。

0-1. 確認したいこと

• 顧客は誰か
  • BtoBなのかBtoCなのか、両方なのか
  • 契約単位は「会社」なのか「人」なのか
• 見込み顧客が「顧客」に変わるタイミング
  • A社なら：契約書締結 or 発注書受領
  • B社なら：体験レッスン後にコース契約した瞬間 など
• 契約満了〜再契約までの流れ
  • 自動更新なのか、毎回見積もりを出すのか
  • 誰がどのタイミングで声をかけるのか
• 顧客コミュニケーションは分業されているか
  • 営業／CS／サポート／トレーナー など
  • どこからどこまでを、誰が持つ前提で設計するのか
• 顧客側にどんな意思決定があるか
  • 「導入するかどうか」だけなのか
  • 「どのプランにするか」「どの支店で契約するか」など、途中で枝分かれがあるのか

A社（BtoB SaaS）の場合

• 顧客：従業員50〜500名の法人
• 見込み顧客：
  • Web フォームで資料請求 / デモ依頼してきた担当者
• 顧客化の瞬間：
  • 電子契約サービスで契約締結した時点
• 再契約フロー：
  • 満了60日前に営業が更新の打診
  • 契約更新 or 解約 or プラン変更

B社（BtoC ジム）の場合

• 顧客：個人会員
• 見込み顧客：
  • 体験レッスンを予約した人
  • LINE追加して問い合わせしてきた人
• 顧客化の瞬間：
  • 初月のコース料金を支払った瞬間
• 再契約フロー：
  • 毎月自動更新だけど、頻度低下や休会希望などの分岐が多い

ここをざっくりでも言語化しておくと、後で「何をテーブルにするか」「何を項目にするか」がブレにくくなります。

1．このCRMが”何を見るためにあるか”を先に決める

いきなりテーブル設計に行きたくなるところですが、
「この仕組みを作った結果、統計/レポート/サマリーで何が見えていれば成功か？」 を先に決めておいた方がいいです。

そうしないと、営業現場は頑張ってデータ入力してるのに経営が欲しい数字が出てこないしライフサイクルも追えない、という悲しい状態になります。
マジで親の顔よりも見てきた構図です。

A社（BtoB）の「何を見るか？」の例

• チャネル別の MQL→SQL率
  • MQL（Marketing Qualified Lead）= マーケティング活動によって得られた、質の高い優良な見込み客
  • SQL（Sales Qualified Lead）= 受注の確度が高い（と判断できる）見込み顧客
• 営業ごとの商談数・受注率
• 契約更新の予定リスト（次の60日で更新が来る案件）
• 解約理由の傾向（価格／機能／サポートなど）

これを見たいなら、

• 「流入チャネル」
• 「商談ステージ」
• 「契約開始日・終了日」
• 「解約理由」

みたいな項目が必要になる、という逆算ができます。

B社（ジム）の「何を見るか？」の例

• 体験予約 → 来店率
• 体験来店 → 本契約率
• 会員の継続月数の分布
• 休会→復帰パターンの数

これをちゃんと見たいなら、

• 「予約経路」
• 「体験実施日／キャンセル理由」
• 「契約開始月」
• 「休会開始／復帰日」

あたりが最初から必要になってきます。
ここら辺Notionではまだ発展途上な機能だったりするので、ダッシュボードのようにBusiness Inteligence（BI）機能を求める場合はLookerTableやPowerBIの検討をオススメします。

2．顧客・見込み顧客の定義をちゃんと決める

ここが曖昧なままだと、現場が「顧客」と呼んでいる対象と、CRM上で「顧客フラグが立っているレコード」がズレるという状態が起こります。
営業現場の認識齟齬製造機です。

A社（BtoB）

• 「見込み顧客」
  • フォームから情報を送ってきた時点の担当者
• 「SQL（商談化した見込み顧客）」
  • 営業が「これは話せる」と判断して、商談が1件以上登録された状態
• 「顧客」
  • 契約締結済みの法人（1社に複数担当者が紐づく）
• 「解約済顧客」
  • 契約終了日を過ぎた会社（ただし履歴やアップセル候補として残す）

B社（ジム）

• 「見込み顧客」
  • 体験レッスンを予約した人
  • もしくはLINE登録して問い合わせしてきた人
• 「顧客」
  • 初回コース契約・決済が済んだ人
• 「休会中」
  • フォーマルに「休会申請」した人
• 「退会」
  • 一定期間利用がなく、本人も退会を希望している or
  • 一定ルールで自動判定（○ヶ月連続利用なし など）

この辺りをちゃんと定義しておくと、
CRM上では「ステータス」や「契約有無」としてシンプルに表現できます。

3．営業プロセスをざっくり4フェーズくらいに分ける

ここはそんなに難しく考えなくてよくて、「おおまかな流れ」をざっくり4区切りくらいにするイメージです。
「誰かがこのフェーズにいる」というのをちゃんと表現するのがCRMの仕事です。
あとは「どのタイミングで」「どのイベントが起きたら」フェーズを進めるか？を決めていく感じ。

A社（BtoB）

1. 集客（リード獲得）
2. 商談（ヒアリング・デモ・提案）
3. 契約〜導入（オンボーディング）
4. 更新・アップセル（継続・拡大）

B社（ジム）

1. 集客（認知・問い合わせ・体験予約）
2. 体験（カウンセリング・お試しトレーニング）
3. 初月契約（コース選択・決済）
4. 継続・休会・復帰（会員維持のフェーズ）

この段階ではまだだいたいこれくらいでよくて、細かいステージ分け（例：商談ステージを6個に分けるとか）は後で詰めればOKです。
実際にCRMを作るときに別の考慮事項が生じて、後で直すことも多々あります。

4．フェーズ × 業務イベント × 入力タイミングを決める

ここから少し実務寄りになります。
CRMに何を記録するかは、「どんなイベントが発生するか」とセットで考えた方がやりやすいです。

A社（BtoB）の主なイベント

• 資料請求があった
• デモの日程が決まった
• デモを実施した
• 見積もりを送った
• 契約が締結された
• 初期設定が完了した
• 更新の打診をした
• 解約の申し出があった

これに対して、

• 「誰が」
• 「いつ」
• 「どのテーブルに」
• 「どんな項目を」

入れるかを決めておきます。

B社（ジム）の主なイベント

• 体験レッスンの予約
• 体験当日の来店 / キャンセル
• コース契約
• コース変更（週1→週2とか）
• 休会・退会・復帰
• トレーナー変更

B社の方が人の感情とかその場の判断要素が強いので、どこまでをCRMに記録するかの線引きもけっこう重要です。
機械的に得られる情報よりも、担当したトレーナーが肌で感じたコメントの方がよっぽど価値が高いとか、示唆が多く得られるとかザラにありますからね。

5．テーブル（データモデル）を決める

ここでやっとCRMのテーブル（NotionではDB）の話が出てきます。

A社（BtoB）に必要そうなテーブル

• 顧客（会社）
• 担当者（人）
• 商談
• 契約
• プラン（料金表）
• イベント履歴（上で出した「何が起きたか」のログ）
• 更新・解約アクション

B社（ジム）に必要そうなテーブル

• 顧客（会員）
• 体験予約
• コース契約
• 出席記録（何日にどのコマに来たか）
• 休会・退会履歴
• 決済履歴
• トレーナー

Notionの場合、テーブル（DB）を増やしすぎると管理がしんどくなるので、

• 「絶対にテーブル（DB）を分けるべきもの」
• 「1テーブル（DB）の中の種類として持てば十分なもの」

をわけて考えた方がいいです。
これらを元にテーブルを作っていくと、例えばこういうERが仕上がります。

A社（BtoB SaaS）のテーブル関係図

B社（ジム）のテーブル関係図

実際にはここまで厳密なERを引く必要はないかもですが、頭の中ではだいたいこんな構造をイメージしておくと設計がブレにくくなり、実際に作る際に役立ちます。

6．各フェーズの項目を「最低限」に絞る

項目を盛りすぎて、誰も真面目に入力しなくなる

SFA/CRMでよくある失敗パターンです。
なので、各フェーズで”これだけ入っていれば最低限運用できる”項目を決めておきましょう。

A社（商談テーブル）の例

• 会社名（顧客テーブルへのリレーション）
• 担当者（担当者テーブルへのリレーション）
• 商談ステージ（見積提示中／検討中／合意済み など）
• 見積金額
• 予測確度（低・中・高くらいのラフさでもいい）
• 次回アクション日

B社（体験予約テーブル）の例

• 顧客（会員テーブルへのリレーション）
• 予約日時
• チャンネル（Web / 電話 / Instagram / 紹介 など）
• 実施結果（来店／キャンセル／無断キャンセル）
• 簡単なメモ（目的：ダイエット／筋力アップなど）

「足りない項目は後から足せるけど、多すぎる項目は誰も埋めない」
この前提で、まずは削ぎ落とす方向で考えるのがおすすめですね。
SFA/CRM運用していると項目増やすのは簡単なんですが、減らすのは超めんどいので。

余談①：必須入力と”あとからどうにでもなる”派生データ

項目を決めるときに意識しておきたいのが、ざっくり次の2種類に分ける考え方です。

• どうしても入力してほしい「必須入力」
• 入力された必須データを加工すればいくらでも増やせる「派生データ」

個人的には、必須入力はだいたい次の4系統だけ死守すればいいと思っています。

1. 誰に関する話か（顧客・会社・担当者）
2. いつ起きた話か（日付・期間）
3. 何の種類の話か（チャネル・ステータス・イベント種別）
4. いくらの話か（金額・数量）

これさえ毎回ちゃんと記録されていれば、

• コンバージョン率
• 継続率
• LTV
• チャネル別のパフォーマンス

みたいな数字はあとからいくらでも作れます。
逆に、ここの定義をサボると、どれだけメモが充実していても「感想以上のことが言えないCRM」になります。

余談②：KPI/BIと必要な項目の早見表

A社（BtoB SaaS）

Point
– 必須項目をちゃんと押さえておけば、派生データやKPIはあとからいくらでも増やせる
– 「チャネル」「日付」「金額」「ステータス」のどれかが抜けると一気に見える世界が狭くなる

B社（ジム）

Point
– B社のようなBtoCサービスだと「人の感情」とか「ライフイベント」に左右される部分も考慮され、完璧なデータを目指すと運用が破綻しやすい
– 「チャネル」「日付」「コース」「ステータス」とかが揃っていればLTVや継続率のような指標は十分出せる

7．フェーズ移行の条件をちゃんと決める

「なんとなく次のステージに進める」のはNGです。
「これが起きたら次のフェーズへ」「こうなったらドロップ扱い」 を明確にしておく必要があります。

A社（例）

• 「商談化」
  • 担当者と30分以上のオンライン or 対面の打ち合わせが終わったら
• 「受注」
  • 契約締結日の登録が済んだら
• 「失注」
  • 3ヶ月間アクションなし or 相手から明確に失注と連絡をもらったら

B社（例）

• 「体験完了」
  • 実際にジムに来てもらい、トレーニング or カウンセリングをしたら
• 「顧客化」
  • いずれかのコースに入会し、初回支払いが完了したら
• 「見込み顧客ドロップ」
  • 体験のキャンセル（無断含む）が2回以上続いたらなど

このルールを決めておくと、CRM上でも「状態（ステータス）」の更新が一貫した基準で行えるようになります。
ステータスの設定あるあるなんですが、どうしてもMECEにできなかったり、現在のステータスの完了=次のステータスの開始条件 という関係性に落とし込む部分で躓きがちです。
そのステータスは本当に必要か？8割以上の顧客がそのステータスを必ず通過するか？など自問すると良いと思います。

8．顧客のライフサイクルを一周書き出す

ここまで来たら一度、「1人の顧客が、最初に出会ってから完全に離れるまでをざっくりストーリーとして書いてみる」のがけっこう効きます。

A社（1社のイメージ）

1. 広告 or セミナーからサイト流入
2. Web フォームから資料請求
3. 営業が連絡 → デモ設定 → デモ実施
4. 見積もり提示 → 社内検討 → 稟議 → 契約締結
5. 初期設定・オンボーディング
6. 半年〜 1 年運用
7. 更新時期にまた営業が入り、更新 or アップセル or 解約

B社（1人のイメージ）

1. Instagram でジムの投稿を見る
2. プロフィールリンクから体験予約
3. 当日来店 → カウンセリング → 体験トレーニング
4. その場 or 後日コース契約
5. 週1 or 週2のペースでしばらく通う
6. 仕事が忙しくなって休会
7. 数ヶ月後に復帰
8. 最終的に一定期間使わなくなり、そのまま退会

このストーリーの各ポイントで、CRM上では「どのテーブルの、どのレコードの更新として表現されるのか」を考えていきます。
イメージに具体性が欠けていたり、「設計」「構築」などの粗い言葉で片付けようとしている部分があれば、そこが考慮不足な部分なことが多いです。

9．ID設計・名寄せ・アーカイブのルールを考えておく

ここは地味なんですが、サボると中長期で必ず破綻するところです。運用の泣き所ですね。
ここでの苦労が未来の自分を救うと信じて臨みましょう。

共通して考えておきたいこと

• 顧客を一意に識別するIDは何にするか
  • メール？電話番号？Notion上の連番？
• 同じ会社／同じ人が重複して登録された時にどうするか
  • 手動で名寄せする運用か
  • 入力ルールをかなり厳しめにするか
  • 入力が揺れるケースはどのようなものがあるか
• 休眠・退会・解約した顧客をどう扱うか
  • レコードを消すのか
  • ステータスだけ変えてアーカイブするのか
  • アーカイブしたレコードは復活するのか、再作成するのか

A社（ToB）の難しさ

• 「グループ会社」「子会社」「複数拠点」みたいな構造をどう扱うか
• メールアドレス、役職、所属会社などが変わった場合、別人扱いにするのか、同一人物として統合するのか
• 別人/同一人物 の判定基準を設けておくべきか

B社（ToC）の難しさ

• 電話番号やメールが変わりやすい
• 別名義で再入会してくるケースをどう扱うか（家族名義など）
• 同姓同名への対処

10．例外フローをあえて列挙しておく

綺麗なフロー図だけを作っていると、
現場でよく起こる”グレーなケース”を片っ端から取りこぼします。
想定できる範囲で例外ケースを列挙し備える必要があります。

A社の例外

• 商談は進んでないけど、「来期検討なので1年後に連絡して」と言われたケース
• 一度解約したけど、別部署で再導入になったケース
• 契約は1社だが、複数のブランド・サービスで使い方が違うケース

B社の例外

• 体験は来てくれたけど、その場では契約せず、数ヶ月後にいきなり入会してくる人
• 休会→復帰→またすぐ休会、を何度も繰り返す人
• 友達紹介で来たけど、紹介元が誰かは本人も忘れているケース

こういうケースをあらかじめ意識しておくと、

• 項目を1〜2個足しておく
• ステータスを1個増やす
• 「メモ欄をちゃんと書く」という運用ルールを課す

などの工夫がしやすくなります。

11．ビュー・ダッシュボードをどう見せるか考える

誰がどの画面からCRMを触るのかを最初からイメージしておきたいです。
Notionの良さは「ビューを自由に作れること」なのでNotionでCRM運用するのであればある程度利用者にビューの作成を委ねるのもありです。

A社（BtoB）のビュー例

• 営業個人用ビュー
  • 自分が担当の商談一覧
  • 「次のアクション日」が近い順に並ぶ
• マネージャー用ビュー
  • チャネル別のリード数
  • 商談のステージごとの本数
  • 今月・来月の更新予定案件

B社（ジム）のビュー例

• 今日は誰が来るのか一覧
  • 今日予約している会員
  • 体験の人／既存会員で分けて表示
• 会員の状態一覧
  • 「3ヶ月以上来ていない人」
  • 「今月退会予定の人」

この「ビューの設計」がけっこう利用者のモチベーションに直結するので、テーブル設計とほぼ同じくらい重要だと個人的には思っています。

12．Notionに落として、運用して、壊して、直す

ここまで来てやっとNotionでどう作るかって話です。
目的がはっきりしていれば作ること自体はそれほど難しくないですが、Notionのみならず使うシステムに応じて作りやすさ/できることに差が生まれます。

ということでサンプルです。
Notionで作るならどうやるの？が気になる方はこちらをご確認ください。
モノを見てもらう方が早いので、作り方については割愛します。
※自動入力やロールアップなど最低限のものにしています。

• Notionサンプル：A社（BtoB SaaS）
• Notionサンプル：B社（BtoC パーソナルジム）

サンプルを少し触ってみれば一目瞭然でもあるのですが、実際に1〜2週間くらい運用してみると色々綻びや足りていない観点がどんどん出て来ます。

• この項目は誰も埋めない
• ビューを作ったけど実用に足りない
• 想定以上に手数が多い
• 商談作るときに顧客紐付けが面倒くさい
• 入力時に迷う
• データ数が多いと目が滑る
• ビューの条件を絞りすぎて一覧性が落ちた

などなど。

作ってみたら思っていた以上に考えることが多い！ってのは設計〜運用テストフェーズでのあるあるです。
ここで初めて発覚する隠れた業務プロセスなんかも出て来たりしますね。
システムに業務を寄せるべきであるという考えもありますが、これについては結局のところ塩梅の問題じゃないかな？と思っています。
システムが業務に合わせにいくか？システムに業務を合わせるか？は現状のプロセスの目的とかけているコストを鑑みて検討するのが一番丸いです。そりゃそうだ、って話ですけど。

▼リリース/先行テストの打ち出し方について

• 最初から「これはβ版です」と宣言しておく
• 現場からフィードバックをもらって改善のサイクルを回す

くらいのノリで運用設計しておいた方が実際にはうまくいきやすいんですが、このノリを許容してくれる現場でなければ信頼貯金を失うだけというリスクもあるので注意しましょう。
現場は常に本気で仕事してます。軽いノリで邪魔されたくないって人もいますからね。「これくらいはせめて考えて設計してよ…」といった暗黙的な「当たり前」のラインがあります。
ラインの探りどころについては 丁寧さが必要 vs スピードが落ちる のせめぎ合いなんですが、どれくらいの塩梅なのかは各社各様ケースバイケースの極みなので、自社に置き換えたらどうだろうか？を適宜想像してアレンジしていただけると助かります。

おまけ：関連自動化の例

CRM単体ではなく、Zapier / Make / Slack連携を前提にしたネタとして。

A社（BtoB SaaS）でやりやすい自動化

• リード登録 → Slack の #leadsチャンネルに自動投稿
  • 自動化可能条件：
  • リードテーブルに「流入チャネル」「担当営業」を持っていること
• 商談の「次回アクション日」が今日のもの → 朝9:00に担当営業のDMへリマインド投稿
  • 自動化可能条件：
  • 商談テーブルに「次回アクション日」「担当営業」を持っていること
  • 「担当営業」のSlackIDがなんらかの手段で取得できること
• 契約の「更新予定日」が60日以内 → 「更新対応リスト」に自動でビューを作る or タグ付け
  • 自動化可能条件：
  • 契約テーブルの「開始日」「終了日」が入力されていること
• 解約登録 → 解約理由を集計して週1でSlackにサマリ投稿
  • 自動化可能条件：
  • 契約テーブルに「解約理由」を持っていること

入力してもらった最低限のデータを元に、更新を忘れないようにする仕組みを目指して作るのがCRM起点自動化の第一歩かなと思います。

B社（ジム）でやりやすい自動化

• 「翌日体験予定の人」リストを毎日朝Slackに投げる
  • 自動化可能条件：
  • 体験予約テーブルに「日時」「顧客名」を持っていること
• 「3週間以上来ていない会員」を抽出してフォローメッセージ候補リストを出す
  • 自動化可能条件：
  • 出席テーブルに「出席日」を持っていること
  • 会員テーブルに「会員ステータス」を持っていること
• 「来月で契約終了予定の会員」一覧を作り、カウンセリングの声かけリストにする
  • 自動化可能条件：
  • 契約開始日・期間 or 契約終了日
• 休会→復帰の履歴から、「復帰しやすいタイミング」（季節・イベント前など）をざっくり見る
  • 自動化可能条件：休会・復帰の日時

まとめ

冒頭書いた通りなんですが、Notionは最後の最後に出てくるだけで、ほとんどが「事業と業務プロセスと顧客の話」なんですよね。でもそれが一番大事という。

ここまでご紹介した観点に沿って言語化ができれば、Notionで頑張るかSalesforceかHubSpotか、別の候補を探すかの目安を立てる際に役立つと思います。
「ツールをどう使うか」より前に「自社の営業・顧客の体験を、どんな構造として捉えてデザインするか」を一回ちゃんと分解してみると、SFA/CRMの構築コンサルへ依頼する際の要件定義が進めやすくなるはずです。
SFA/CRM設計においては本稿でお話した以外にも考えるべき要素や定義する事項がありますし、全てのケースを網羅してお伝えするのは難しい点、ご留意いただけると助かります。

以上、SFA/CRMの設計はやっぱ大変ですよねーって話でした。

ではでは。