Notionで顧客管理・CRMを作る方法｜DB設計から専用CRMとの比較、フォローを取りこぼさない運用まで
この記事の要点（TL;DR）
- NotionはCRM（顧客管理）として使えます。会社・担当者・商談・対応履歴をデータベースに分け、リレーションで紐付ければ、小規模チームの「顧客台帳」としては十分に機能します。
- Notionの強みは、0円から始められること・自由なカスタマイズ・情報の一元化です。一方で専用CRMのような自動化・分析・サポートは弱く、放っておくと「次のフォローの取りこぼし（フォロー漏れ）」が起きやすい弱点があります。
- フォロー漏れの防止は、DB設計とは別レイヤーで設計するのが要点です。Notion標準のリマインダーは「本人がNotionを開いているとき」しか届かず、取引先など社外の相手には届きません。
- Kapselとは、Notionの期日・担当・ステータスを監視し、Notionを使わない社外の相手にもメールで自動リマインドを送り、受信者のワンクリックでNotionのステータスに書き戻す通知ツールです。受注済み・入金済みには送りません。
Notionを顧客管理（CRM）に使いたいが、専用ツールを入れるほどでもない——そんな小規模チームやフリーランスは少なくありません。この記事は、NotionをCRMとして使えるかどうかの前提整理から、データベース設計、商談パイプラインの管理、専用CRMとの比較、そして顧客管理で最も起きやすい「フォロー漏れ」の防ぎ方までを、第三者視点で客観的にまとめます。
結論を先に述べます。Notionは顧客情報を一元化する「台帳」としては小規模なら十分に使えます。ただし、CRMの本質である「次に誰へいつ動くか」を確実に実行させる仕組みは、DB設計だけでは完結しません。台帳の設計と、フォローを取りこぼさない通知の設計を分けて考えるのが、破綻しない運用の要点です。
結論 — Notionは『顧客台帳』には向くが、フォロー漏れの防止は別レイヤーで設計する
Notionは顧客情報を一元管理する台帳としては小規模チームに十分向きますが、「次のフォローを確実に実行させる」機能は弱いため、そこは別の仕組みで補う設計が現実的です。 顧客の連絡先・商談履歴・ステータスをNotionに集約するのは容易ですが、その情報を見て誰かが動くまでは何も起きません。台帳（可視化）とフォロー（通知・実行）を切り分けて設計すると、顧客管理が破綻しにくくなります。
| レイヤー | 役割 | 得意なツール |
|---|---|---|
| 台帳レイヤー（可視化） | 顧客・商談・履歴を一元管理し、いつでも参照・引き継ぎできる状態にする | Notion（データベース）／専用CRM |
| フォローレイヤー（実行） | 「次回フォロー日が来た」「未対応の商談がある」ことを担当者や取引先に確実に届け、行動につなげる | Notion標準通知／Zapier・Make・GAS／通知ツール |
💡 ポイント：Notionで顧客DBを整えるだけでは「見れば分かる」状態止まりです。誰かがそのDBを能動的に開かないとフォローは始まりません。台帳とフォローを切り分けると、「見に行くのを忘れて失注・失客する」事故が減ります。
NotionはCRM（顧客管理）として使えるか
結論として、NotionはCRMとして使えます。 Notionのデータベース機能を使えば、顧客の連絡先・商談の進捗・対応履歴を構造化して管理でき、市販のCRMに近い顧客台帳を自作できます。ただし「専用CRMと同等」ではなく、規模と要件によって向き・不向きがはっきり分かれます。
Notionのデータベースは、テーブル・ボード・カレンダー・ギャラリーなど複数のビューで同じデータを見せられ、プロパティ（ステータス・日付・担当者・金額・リレーションなど）で情報を構造化できます。この仕組みは、顧客管理に必要な「一覧・進捗・履歴」を表現するのに十分な柔軟性を持ちます。一方で、営業自動化やメール配信、高度なレポーティングといった専用CRMの中核機能は、Notion単体には備わっていません。
向いているケース（小規模・柔軟な運用・低コスト重視）
Notionでの顧客管理は、顧客数がそれほど多くなく、運用ルールを自分たちで柔軟に決めたい小規模チームやフリーランスに向いています。 専用CRMの決まった型に業務を合わせるのではなく、自社の商談フローに合わせてプロパティやビューを自由に組み替えたい場合、Notionのカスタマイズ性が活きます。すでにNotionをタスク・議事録・ドキュメントに使っているなら、顧客情報も同じワークスペースに集約でき、情報の分散を防げます。
- 顧客・商談の件数が数十〜数百規模で、1人〜少人数で回している
- 商談フローや管理項目を頻繁に見直したい／自社独自の項目が多い
- 月額のCRM費用をかけず、まず0円で顧客管理を始めたい
- Notionをすでに社内の情報基盤として使っている
向かないケース（大規模な自動化・高度な分析が前提の営業組織）
大人数の営業組織で、メール配信の自動化・売上予測・詳細な分析レポートが前提になる運用には、Notionは向きません。 顧客数や商談数が多く、リード獲得からナーチャリング、受注、アフターフォローまでを自動で回したい場合は、その用途に特化した専用CRM/SFAのほうが効率的です。Notionはあくまで汎用のデータベース＋ドキュメントツールであり、営業活動の自動化や高度な集計を主目的には設計されていません。
- 数千件以上の顧客・商談を複数人で同時に扱う
- メール自動配信・スコアリング・売上予測など営業自動化が前提
- 権限を役職・部門ごとに細かく制御する必要がある
- 監査・コンプライアンス上、専用ツールの管理機能が求められる
⚠️ 注意：「使えるか／使えないか」は二択ではなく、規模と要件の問題です。小さく始めてNotionで回し、限界が見えたら専用CRMへ移す、という段階的な進め方が現実的です。移行の目安は後述します。
Notionで顧客管理をするメリット・デメリット
Notionで顧客管理をする最大の利点は「0円から始められる自由なカスタマイズ性と情報の一元化」であり、最大の弱点は「専用CRMではないための自動化の弱さとフォロー漏れの起きやすさ」です。 導入前に、両方を天秤にかけて判断するのが安全です。
| 観点 | メリット | デメリット |
|---|---|---|
| コスト | 無料プランでも顧客管理を始められる | 高度な運用でも機能追加より外部ツール併用が必要になる場合がある |
| 柔軟性 | プロパティ・ビューを自由に設計でき、業務に合わせられる | 設計の自由度が高い分、作り込みに時間と設計スキルが要る |
| 一元化 | タスク・議事録・顧客情報を同じ場所に集約できる | 情報が増えると整理・命名ルールが崩れやすい |
| 自動化 | ボタン・オートメーションで簡単な自動化は可能 | メール配信・外部通知など本格的な自動化は不得手 |
| 分析 | ロールアップで合計・件数などの集計は可能 | 売上予測・ファネル分析など高度な分析はできない |
| サポート | コミュニティ情報やテンプレートが豊富 | 顧客管理に特化した専任サポートはない |
メリット（0円から始められる・自由なカスタマイズ・情報の一元化）
Notionの顧客管理は無料プランでも始められ、OSやデバイスを問わずブラウザ・アプリから使え、顧客情報を社内の他の情報と同じ場所に一元化できます。 個人利用の範囲であれば費用をかけずに顧客台帳を作れるため、専用CRMの契約前に「自社に必要な項目は何か」を試しながら固められます。さらに、商談DB・タスク・議事録・ナレッジを同じワークスペースに置けるので、「顧客情報はCRM、議事録は別ツール」といった分散を防ぎ、参照の手間を減らせます。
デメリット（専用CRMではない・自動化が弱い・フォロー漏れが起きやすい）
Notionは汎用ツールであるため専用CRMのような営業自動化・分析が弱く、特に「次回フォローの取りこぼし（フォロー漏れ）」が起きやすい点に注意が必要です。 顧客DBに「次回フォロー日」を入れておいても、その日が来たことを能動的に知らせてくれる仕組みが弱いため、担当者がDBを見に行かない限りフォローは始まりません。習得コストがかかる、顧客管理に特化した公式サポートがない、といった点も、専用CRMと比べたときの弱みです。フォロー漏れの具体的な防ぎ方は、後述の「フォロー漏れと防ぎ方」で整理します。
Notionで顧客管理データベースを設計する手順
Notionで顧客管理を設計する基本は、1つの巨大な表に詰め込まず、会社・担当者・商談・対応履歴を別々のデータベースに分け、リレーションで紐付けることです。 最初にすべてを1テーブルにすると、同じ会社の情報が重複したり、商談ごとの履歴が追えなくなったりします。役割ごとにDBを分けると、拡張しても崩れにくい設計になります。
作成手順の全体像は次のとおりです。
- 管理したい対象を洗い出す（顧客企業・担当者・商談・問い合わせ・対応履歴など）
- 対象ごとにデータベースを作る（会社DB・担当者DB・商談DB・対応履歴DB）
- 各DBに必要なプロパティ（ステータス・日付・担当者・金額など）を設計する
- リレーションでDB同士を紐付ける（商談DB→会社DB／担当者DB など）
- ロールアップで関連情報を集約する（会社ごとの商談金額合計など）
- ビュー（テーブル・ボード・カレンダー）で用途別の見え方を用意する
会社DB・担当者DB・商談DB・対応履歴DBを分けて考える
顧客管理DBは「会社（顧客企業）」「担当者（人）」「商談（案件）」「対応履歴（やりとり）」の4つに分けると、情報が重複せず、履歴も追いやすくなります。 1つの会社に複数の担当者がいて、1人の担当者と複数の商談が並行し、各商談に複数の対応履歴がぶら下がる、という現実の構造をそのままデータベースに落とし込む考え方です。
| データベース | 主な役割 | 代表的なプロパティ |
|---|---|---|
| 会社DB | 顧客企業の基本情報を管理 | 会社名・業種・住所・Webサイト・関連担当者（リレーション） |
| 担当者DB | 顧客側の個人（キーパーソン）を管理 | 氏名・所属会社（リレーション）・役職・メール・電話 |
| 商談DB | 案件・商談の進捗を管理 | 商談名・ステータス・確度・金額・次回フォロー日・担当者・関連会社（リレーション） |
| 対応履歴DB | 打ち合わせ・連絡などのやりとりを記録 | 日付・種別・内容・関連商談（リレーション）・担当者 |
💡 ポイント：小規模なら「会社DB」と「担当者DB」を1つにまとめ、「商談DB」と「対応履歴DB」の2〜3個構成から始めても構いません。最初から4つ作る必要はなく、運用しながら分割するのが現実的です。
基本プロパティ設計（ステータス・次回フォロー日・担当者・金額など）
商談DBには最低限、ステータス・次回フォロー日・担当者・金額の4プロパティを持たせると、進捗と「次に何をすべきか」が一覧で分かります。 ステータスは商談の段階、次回フォロー日は次に動く日、担当者は責任者、金額は見込み金額を表します。これらを揃えることで、後段のパイプライン管理や自動リマインドの条件設定が可能になります。
| プロパティ名 | 型 | 用途 |
|---|---|---|
| ステータス | セレクト | 問い合わせ／提案／交渉／受注／失注 の段階管理 |
| 次回フォロー日 | 日付 | 次に連絡・行動する予定日。リマインドの起点 |
| 担当者 | ユーザー（People） | 社内の担当者。フィルタ「自分」で自分の案件だけ表示 |
| 見込み金額 | 数値 | 受注見込み額。パイプラインの金額合計に使う |
| 確度 | セレクト／数値 | 受注確率（例：A/B/C や 30%/60%/90%） |
| 最終接触日 | 日付 | 直近で連絡した日。放置日数の把握に使う |
⚠️ 注意：日付プロパティは「次回フォロー日（未来の予定）」と「最終接触日（過去の実績）」を分けて持つのがおすすめです。1つにまとめると「もう連絡したのか、これから連絡するのか」が判別できなくなります。
リレーション／ロールアップで顧客と案件を紐付ける
リレーションで商談DBと会社DB・担当者DBを紐付け、ロールアップで会社ごとの商談金額や件数を集約すると、顧客単位での状況が一目で分かります。 リレーションは複数DB間を関連付けるプロパティ、ロールアップは関連先の値を集計・表示するプロパティです。たとえば会社DBに「関連商談（リレーション）」を置き、ロールアップで「商談金額の合計」「進行中の商談件数」を表示すれば、会社ごとの重要度が見えます。
- リレーション：商談DBに「関連会社」「関連担当者」を持たせ、会社・人と案件を結ぶ
- ロールアップ：会社DBで関連商談の「金額の合計」「受注件数」を集計表示する
- フォーミュラ：最終接触日から今日までの経過日数を計算し、放置案件を可視化する
Notionで顧客情報を扱うときの権限管理と個人情報の注意点
Notionの権限はワークスペース単位・ページ単位が基本で、専用CRMのような「プロパティ（項目）ごとの細かい権限制御」はできないため、顧客の個人情報を扱うDBほど共有範囲の設計を意識しておく必要があります。 顧客管理DBには氏名・メールアドレス・電話番号・取引条件など、社外に漏れると影響の大きい情報が集まります。誰が見られて、誰が編集できるかを最初に決めておくと、事故を防げます。
Notionの権限モデルでできること・できないこと
Notionの権限は、ワークスペースメンバーの役割（管理者／メンバー／ゲスト）と、ページ単位の共有設定（フルアクセス／編集可能／コメント可能／閲覧のみ）の組み合わせで決まります。データベースの特定のプロパティ（列）だけを一部のメンバーに隠す、といった項目単位の権限制御は標準機能にはありません。
| できること | できないこと |
|---|---|
| ページ／DB単位で共有範囲を絞る（特定メンバーのみ・ゲストのみ） | プロパティ（列）単位で表示・非表示を切り替える |
| ゲストを招待して特定ページだけ共有する | ゲストに商談DB全体を見せず一部の行だけ見せる |
| ワークスペース管理者がメンバーの権限を一括管理する | 部門・役職ごとに閲覧できるレコードを自動的に出し分ける |
⚠️ 注意：行（レコード）単位・項目単位でアクセスを細かく制御したい場合、Notion標準ではフィルタ付きビューを個別に共有するなど運用でカバーする必要があります。役職・部門ごとに厳密な権限分離が必須の場合は、専用CRMの権限管理機能のほうが向いています。
個人情報を扱う上での実務上の注意点
顧客の氏名・連絡先・取引条件をNotionに集約する場合、次のような点を運用ルールとして決めておくと安全です。
- 共有リンクの公開範囲を確認する：ページ共有時に「Web上の誰でも閲覧可」を誤って選ばないよう、共有前に範囲を確認する
- ゲスト招待は必要なページ・DBに限定する：取引先やパートナーをゲスト招待する際は、顧客DB全体ではなく必要な範囲に絞る
- 退職・契約終了時にアクセス権を整理する：メンバーの入れ替わり時に、顧客DBへのアクセス権が残ったままにならないようにする
- 不要になった個人情報は削除・アーカイブする：失注や取引終了から一定期間が過ぎた個人情報は、社内の保持方針に沿って整理する
これらは運用ルールで対応できる範囲ですが、業種によっては個人情報保護法などの法令上の管理体制が求められる場合があります。取り扱う個人情報の性質・量によっては、専用CRMやSFAが備える権限管理・監査ログ機能が必要になることもあるため、前述の「専用CRMへ移るべき人」を判断する材料の一つとして考慮してください。
商談ステータス・パイプラインをボードビューで管理する
商談DBをボードビューにし、ステータスで列を分けると、問い合わせ→提案→受注／失注のパイプラインをカンバン形式で可視化できます。 カードをドラッグして列を移動させるだけでステータスが更新されるため、どの案件がどの段階で止まっているかが直感的に分かります。テーブルビューが「一覧・編集」向きなのに対し、ボードビューは「進捗の流れ」を見るのに向いています。
ステータス設計の例（問い合わせ→提案→受注／失注）
パイプラインのステータスは、自社の商談フローに沿って「問い合わせ→提案→交渉→受注／失注」のように、段階が一方向に進む形で設計します。 段階を細かくしすぎると運用が重くなり、粗すぎると停滞が見えません。まずは5段階前後から始めて、運用しながら調整するのが実用的です。
| ステータス | 意味 | 次のアクションの例 |
|---|---|---|
| 問い合わせ | 新規リード・初回接触 | ヒアリング日程の調整 |
| 提案 | 見積・提案を提示済み | 検討状況の確認フォロー |
| 交渉 | 条件・価格を調整中 | 条件のすり合わせ・クロージング |
| 受注 | 成約（クローズ） | 請求・納品・オンボーディングへ |
| 失注 | 見送り・他社決定 | 失注理由の記録・再アプローチ時期の設定 |
商談後の追客（フォローアップ）の設計そのものを詳しく知りたい場合は、Notionで見積・商談後の追客を自動リマインドする方法で、可視化と通知を分けた設計を解説しています。
テンプレートを使って早く始める
ゼロから作るのが大変な場合は、Notion公式ギャラリーやコミュニティのCRMテンプレートを複製し、自社の項目に合わせて調整するのが早道です。 テンプレートには会社・商談・履歴のDBとリレーションがあらかじめ組まれているものが多く、構造を学びながら着手できます。ただしテンプレートは他社の運用前提で作られているため、不要なプロパティを削り、自社のステータスに置き換える調整は必要です。
| 始め方 | 向いている人 | 注意点 |
|---|---|---|
| 公式ギャラリーのテンプレを複製 | 構造の型を早く手に入れたい | 項目が自社に合わないことが多く、要調整 |
| コミュニティ／有料テンプレを利用 | 完成度の高いものを使いたい | 提供元・更新状況・サポート範囲を確認する |
| ゼロから自作 | 自社フローが独特／学習も兼ねたい | 設計と作り込みに時間がかかる |
受注後の請求・入金ステータスまで一元管理する
商談が受注に進んだあと、請求書DBを追加して商談DBとリレーションで紐付ければ、見込み客の管理から請求・入金の追跡までをNotion上で一元管理できます。 顧客管理と請求管理を別々のツールに分けると、「受注したのに請求書を出し忘れる」「入金確認が漏れる」といった段差が生まれやすくなります。同じワークスペース内でDBをつなげておくと、受注から入金までの流れを1か所で追えます。
請求書DBの基本設計
商談DBが「受注」ステータスになったタイミングで、請求書DBに1件レコードを作成し、商談とリレーションで紐付けます。
| プロパティ名 | 型 | 用途 |
|---|---|---|
| 請求書番号 | テキスト／ユニークID | 請求書を一意に識別する |
| 関連商談 | リレーション | どの商談・顧客に対する請求かを紐付ける |
| 金額 | 数値 | 請求金額 |
| 発行日 | 日付 | 請求書を発行した日 |
| 支払期限 | 日付 | 入金期限。督促の起点になる |
| 入金ステータス | セレクト | 未請求／請求済み／入金待ち／入金済み |
会社DB側に「関連請求書」のロールアップを置き、「累計請求額」「未回収金額」を集計すれば、取引先ごとの売上・未回収状況も同じ画面で把握できます。
支払期限超過だけを自動で督促する
請求書DBの支払期限と入金ステータスをKapselで監視すれば、支払期限を過ぎてなお入金ステータスが「入金待ち」のままの請求だけに、自動で督促メールを送れます。 商談の追客と同じ仕組みを、受注後の入金確認にもそのまま使える形です。入金ステータスが「入金済み」に変わった請求には送信されないため、すでに支払い済みの取引先に督促が飛ぶ事故を防げます。
請求書の督促文面の作り方や段階的な催促のタイミングは、請求書の入金リマインドを自動化する方法や入金催促メールの書き方・例文テンプレートで詳しく解説しています。フリーランス・小規模事業者の入金管理全体の進め方はフリーランスの入金管理・報酬回収の進め方も参考になります。
💡 ポイント：商談DBと請求書DBを分けてリレーションで結ぶと、「まだ受注前の商談」と「受注後の入金待ち」を混同せずに管理できます。1つのDBに両方を詰め込むと、ステータスの意味が曖昧になりやすいので注意してください。
Notionの顧客管理で起きがちな『フォロー漏れ』と防ぎ方
Notionで顧客管理をしていて最も起きやすい失敗は、DBに「次回フォロー日」を入れていても、その日が来たことに気づかず連絡を忘れる『フォロー漏れ』です。 これはDB設計の問題ではなく、通知・実行のレイヤーが弱いことが原因です。台帳がどれだけ整っていても、誰かが動かなければ商談は前に進みません。ここでは、なぜ標準機能では防ぎにくいのかと、その補い方を整理します。
Notion標準のリマインダーが顧客管理で機能しにくい理由
Notion標準のリマインダー（@remindや日付通知、データベースオートメーション）は、基本的に「Notionアカウントを持ち、そのワークスペースを開いている本人」にしか届かず、取引先など社外の相手には届きません。 担当者がNotionを日常的に開いていれば気づけますが、通知はアプリ内やまとめメールで届く挙動になりやすく、忙しい日の期日は見落とされがちです。さらに、顧客管理のもう一方の相手である取引先・見込み客は通常Notionを使っていないため、そもそも通知の宛先にできません。Notion標準通知の仕組みと限界は、Notionの通知が来ない・届かないときの原因と対処や、Notionのリマインダー機能の使い方と限界で詳しく整理しています。
| 通知の届け先 | Notion標準リマインダー | 顧客管理で必要なこと |
|---|---|---|
| 社内の担当者本人 | 届く（ただしNotionを開いている前提） | 期日を見落とさず確実に気づきたい |
| 別の社内メンバー | メンションで届く | 担当者交代・エスカレーションに使いたい |
| 取引先・見込み客（社外） | 届かない | 検討状況の確認・案内を本人に直接届けたい |
次回フォロー日・商談ステータスをメールで自動リマインドする
「次回フォロー日が来た商談」を自動で拾ってメールで知らせる仕組みを別レイヤーで用意すると、担当者がDBを見に行かなくてもフォローが始まります。 Kapselは、Notionの期日（次回フォロー日など）・担当者・ステータスを監視し、条件に合う商談について自動でメールリマインドを送ります。担当者本人への「そろそろフォローの期日です」という通知はもちろん、期限を過ぎた案件の督促（期限超過リマインド）や、対象の絞り込み（特定ステータスの商談だけ）、定期便（週次でまとめて通知）にも対応します。送信した記録は残るため、いつ・誰に・何を送ったかを後から確認できます。
- 監視対象：Notionの期日・担当・ステータスを見て、条件に合う商談だけを対象にする
- 期限超過の督促：次回フォロー日を過ぎた案件に、期限後の督促を自動送信する
- 対象の絞り込み：「提案」「交渉」などフォローが必要なステータスだけに送る
- 定期便：週次などの決まったタイミングでまとめてリマインドする
- 差し込み変数：会社名・商談名・金額などをメール文面に差し込んで送る
- 送信記録：送信履歴が残り、フォローの実施状況を追える
受注済み・入金済みの案件には送らない仕組み
フォロー自動化で最も避けたい事故は、すでに受注・入金が済んだ相手に催促や確認メールが飛ぶことですが、Kapselはステータスを監視し、受注済み・入金済みには送らない設計になっています。 日付だけを条件に自動送信すると、決着済みの案件にも通知が飛ぶ事故が起きます。ステータスを送信条件に含めることで、「まだ動きが必要な案件」だけにフォローを送り、決着済みの相手への誤送信を仕組みとして防げます。
⚠️ 注意：自動リマインドを組むときは、必ず送信条件に「ステータス」を含めてください。「次回フォロー日が今日」だけを条件にすると、受注・失注・入金済みの相手にも通知が飛ぶ危険があります。
顧客・取引先の返信でNotionのステータスが更新される（双方向）
Kapselが送るメールのリンクを受信者がワンクリックすると、その応答がNotionのステータスに書き戻される双方向の仕組みになっています。 通常のメール通知は「送りっぱなし」で、相手の反応をNotionに反映するには手作業の転記が必要です。Kapselでは受信者のワンクリックがNotionのステータス更新につながるため、取引先がNotionを使っていなくても、やりとりの結果が顧客DBに残ります。これにより、台帳と実際の進捗のズレを防げます。
💡 ポイント：双方向の書き戻しがあると、「メールは送ったがNotion側が古いまま」という台帳と現実の乖離を防げます。顧客管理では、この乖離こそが二重連絡や対応漏れの原因になります。
Notionと専用CRM、どちらを選ぶべきか
Notionと専用CRMの選択は「規模・自動化の必要度・予算」で決まり、小規模で柔軟さと低コストを重視するならNotion、大規模で自動化・分析が前提なら専用CRMが向きます。 どちらが優れているかではなく、いまの自社の段階に合うかで選ぶのが現実的です。
比較の軸（価格・自動化・拡張性・チーム規模）
| 観点 | Notion | 専用CRM（kintone・Salesforce・HubSpotなど） |
|---|---|---|
| 初期コスト | 無料プランから始められる | 無料枠のあるものもあるが、本格利用は有料が中心 |
| カスタマイズ | プロパティ・ビューを自由に設計できる | 項目・画面をカスタマイズできるが製品の枠内 |
| 自動化 | 簡単なオートメーションは可能、本格配信は不得手 | メール配信・スコアリングなど営業自動化に強い |
| 分析・レポート | ロールアップで集計可、高度な分析は不得手 | ファネル分析・売上予測など分析機能が充実 |
| 外部・社外への通知 | 標準では社外に届かない（別途仕組みが必要） | 顧客への一斉メール・ステップメール等を標準搭載 |
| チーム規模 | 少人数〜中規模向き | 中〜大規模の営業組織向き |
| 情報の一元化 | タスク・議事録・顧客を同じ場所に集約 | 顧客管理に特化（他情報は別ツールになりがち） |
💡 ポイント：Notionは「顧客管理も含めて情報を一元化したい」段階、専用CRMは「営業活動そのものを自動化・分析したい」段階に向きます。段階が変わったら移行を検討する、という捉え方が実用的です。
Notionのままでいい人／専用CRMへ移るべき人
顧客数が少なく手動フォローで回るうちはNotionで十分ですが、案件数が増えて手作業のフォローが追いつかなくなったら、専用CRMへの移行を検討する段階です。 移行のタイミングは件数だけでなく、「自動化しないと回らない」「複数人での同時運用や権限管理が必要になった」といった運用の限界で判断します。
| Notionのままでいい人 | 専用CRMへ移るべき人 |
|---|---|
| 顧客・商談が数十〜数百件で手動フォローで回る | 案件数が増え、手動フォローが追いつかない |
| 1人〜少人数で運用している | 多人数で同時に更新し、権限を細かく分けたい |
| 低コスト・柔軟性を最優先したい | 営業自動化・分析・予測が業務の前提になった |
| 顧客情報を他の社内情報と一元化したい | 顧客管理に特化した専任サポートが必要 |
なお、Notionを続ける場合でも、フォローの自動化だけを外部の通知レイヤーで補えば、「台帳はNotion・通知は自動」という中間的な運用が可能です。請求・入金の督促まで含めて追いかけたい場合は、入金催促メールの書き方・例文テンプレートや、支払い遅延・未払いへの対応と督促の進め方もあわせて参考になります。
まとめ
- NotionはCRM（顧客管理）として使える。会社・担当者・商談・対応履歴をDBに分け、リレーションで紐付ければ、小規模チームの顧客台帳として十分機能する。
- Notionの強みは0円から始められること・自由なカスタマイズ・情報の一元化。弱みは専用CRMのような自動化・分析・サポートの不足と、フォロー漏れの起きやすさ。
- 権限はワークスペース単位・ページ単位が基本で、プロパティ単位の細かい制御はできない。顧客の個人情報を扱う以上、共有範囲・ゲスト招待・アクセス整理を運用ルールとして決めておく必要がある。
- 受注後は請求書DBを商談DBとリレーションで紐付ければ、請求・入金ステータスまでNotion上で一元管理できる。
- 顧客管理は「台帳（可視化）」と「フォロー（通知・実行）」を別レイヤーで設計するのが破綻しないコツ。Notion標準の通知は本人がNotionを開いているときしか届かず、社外の取引先には届かない。
- Kapselは、Notionの期日・担当・ステータスを監視し、次回フォロー日や商談ステータスをメールで自動リマインドし、受信者のワンクリックでNotionへ書き戻す。受注済み・入金済みには送らない。無料プランは0円から試せる。
- 規模が大きくなり自動化・分析が前提になったら、専用CRMへの移行を検討する。それまではNotion＋通知レイヤーの組み合わせが現実的な選択肢になる。
顧客管理を「見れば分かる台帳」から「フォローが取りこぼされない仕組み」に変えると、商談・顧客の抜け漏れは減らせます。まずは使い方ガイドで設定の流れを確認できます。
よくある質問（FAQ）
NotionはCRM（顧客管理）として使えますか？ 使えます。Notionのデータベースで会社・担当者・商談・対応履歴を管理し、リレーションで紐付ければ、小規模チームの顧客台帳としては十分に機能します。ただし専用CRMのような営業自動化や高度な分析は弱いため、規模と要件によって向き・不向きが分かれます。
Notionで顧客管理をするデメリットは何ですか？ 主に、専用CRMではないための自動化の弱さ、売上予測などの分析ができないこと、習得コスト、そして顧客管理特化のサポートがないことです。特に「次回フォロー日が来たことに気づかず連絡を忘れる」フォロー漏れが起きやすく、通知は別の仕組みで補う必要があります。
Notionの顧客管理データベースはどう設計すればいいですか？ 1つの表に詰め込まず、会社DB・担当者DB・商談DB・対応履歴DBに分け、リレーションで紐付けるのが基本です。商談DBにはステータス・次回フォロー日・担当者・金額を持たせ、ロールアップで会社ごとの金額合計や件数を集計すると、顧客単位の状況が一覧で分かります。小規模なら2〜3個のDBから始めても構いません。
Notionで顧客の個人情報を扱う際に気をつけることは何ですか？ Notionの権限はワークスペース単位・ページ単位が基本で、専用CRMのようなプロパティ（項目）単位の細かい権限制御はできません。共有リンクの公開範囲やゲスト招待の範囲を必要な部分に絞り、退職・契約終了時にはアクセス権を整理するといった運用ルールを決めておくことが重要です。厳密な権限分離が必須の業種では、専用CRMの権限管理機能もあわせて検討してください。
受注後の請求・入金管理もNotionで一元管理できますか？ できます。商談DBが「受注」になったタイミングで請求書DBにレコードを作り、商談とリレーションで紐付ければ、請求金額・支払期限・入金ステータスまで同じワークスペースで管理できます。支払期限を過ぎても入金ステータスが「入金待ち」のままの請求だけを自動督促する仕組みも、Kapselのようなツールで補えます。
Notionと専用CRM（kintone・HubSpotなど）の違いは？ Notionは汎用のデータベース＋ドキュメントツールで、低コストと自由なカスタマイズ、情報の一元化が強みです。専用CRMはメール配信・スコアリング・売上予測など営業自動化・分析に特化しています。小規模で柔軟さ重視ならNotion、大規模で自動化・分析が前提なら専用CRMが向きます。
Notionで商談のステータス・パイプラインはどう管理する？ 商談DBをボードビューにし、ステータス（問い合わせ→提案→交渉→受注／失注）で列を分けると、カンバン形式で進捗を可視化できます。カードをドラッグして列を移動するだけでステータスが更新され、どの案件がどの段階で止まっているかが直感的に分かります。まずは5段階前後から始めるのが実用的です。
Notionの顧客管理は無料で始められますか？ はい、Notionの無料プランでも顧客管理データベースを作成でき、個人利用の範囲であれば費用をかけずに始められます。まず無料で「自社に必要な項目は何か」を試しながら固め、必要になった段階で有料プランや外部ツールの併用を検討する進め方が現実的です。
Notionのリマインダーは取引先など社外の相手にも届きますか？
届きません。Notion標準の@remindや日付通知、オートメーションは、基本的にNotionアカウントを持つワークスペース内のメンバーが対象で、Notionを使わない取引先や見込み客は宛先にできません。社外へ届けるには、Notionの情報をトリガーにメールを送るKapselのような外部の仕組みが必要です。
フリーランス・小規模事業の顧客管理にNotionは向いていますか？ 向いています。顧客・商談が数十〜数百件で少人数で回している場合、Notionの低コストと柔軟性が活き、タスクや請求管理と同じ場所に顧客情報を一元化できます。フォロー漏れや入金の追いかけが課題になったら、通知の自動化を外部レイヤーで補うとよいでしょう。フリーランスの入金管理はフリーランスの入金管理・報酬回収の進め方も参考になります。
専用CRMに乗り換えるべきタイミングはいつですか？ 案件数が増えて手作業のフォローが追いつかなくなったとき、多人数での同時運用や細かい権限管理が必要になったとき、営業自動化・分析・売上予測が業務の前提になったときが目安です。逆に、少人数で手動フォローが回っているうちは、Notion＋通知レイヤーの組み合わせで十分なことが多いです。
補足・注記
- 本記事の公開日は2026-08-08です。
- Notionの機能（データベース、テーブル・ボード・カレンダー等のビュー、セレクト／日付／ユーザー／リレーション／ロールアップ／フォーミュラなどのプロパティ、ワークスペース／ページ単位の権限モデル、
@remind・日付リマインダー・データベースオートメーションによる通知の宛先範囲、テンプレートの複製）に関する記述は、Notionの公式ヘルプおよび公式ドキュメントで公開されている仕様を一次情報として参照しています。仕様はNotion側の更新により変わる場合があるため、実際の設定時に最新の公式情報を確認してください。 - kintone・Salesforce・HubSpot など専用CRM/SFAの機能・料金・対応範囲は各サービスの提供状況により変わります。比較・移行の検討にあたっては、各公式情報を必ずご確認ください。
- 個人情報の取り扱いに関する記述は一般的な実務上の注意点の紹介であり、法令上の適否を保証するものではありません。業種・取り扱う情報の性質によっては、個人情報保護法など関連法令に基づく社内の管理体制の確認が別途必要です。
- Kapselの機能（監視対象＝Notionの期日・担当・ステータス、社外へのメール自動リマインド、ワンクリックでのステータス書き戻し、受注済み・入金済みの除外、期限超過の督促・対象の絞り込み・定期便・送信記録・差し込み変数、Proプランの複数ワークスペース・差出人ブランディング）および料金（税込：Free ¥0／Standard ¥1,980／Pro ¥4,980）は、いずれも執筆時点のものです。最新の内容は料金ページおよび使い方ガイドを参照してください。
