Notion顧客管理テンプレートの選び方｜CRMとして崩れない項目設計

Notionには、顧客管理やCRM向けのテンプレートが多くあります。

会社名を一覧にするテンプレート。

リードを管理するテンプレート。

商談パイプラインをボードで見るテンプレート。

営業タスクやフォロー日を管理するテンプレート。

Notion公式の営業テンプレートカテゴリにも、リードや顧客関係、営業プロセスを管理するテンプレートが並んでいます。

Notion公式：営業テンプレート

テンプレートから始めるのは悪くありません。

ゼロからDBを作るより早く、画面の見た目も整っています。

ただし、テンプレートを複製しただけで顧客管理が完成するわけではありません。

• 顧客と商談が同じDBに入っている
• 会社と担当者が1行に混ざっている
• 対応履歴をどこに残すか決まっていない
• 次回連絡や営業タスクを追えない
• フェーズ名が自社の営業プロセスと合っていない
• 権限や外部共有の前提が分からない
• CRMへ移すべき規模になってもNotion内で無理をする

こうした状態のまま使い始めると、テンプレートはすぐに「きれいな顧客メモ」になります。

Notion顧客管理テンプレートは、見た目や人気で選ぶのではなく、会社DB、担当者DB、商談DB、対応履歴DB、タスクDBがCRMとして分かれているかで選ぶ べきです。

この記事では、Notion顧客管理テンプレートの選び方を、必須DB、必須プロパティ、ビュー設計、権限、使い始めの調整、CRMへ移す判断まで整理します。

先に結論：テンプレートは構造で選ぶ

Notion顧客管理テンプレートを見るときは、最初に見た目を見ない方がよいです。

きれいなダッシュボード、カード表示、アイコン、サンプルデータは参考になります。

しかし、実務で重要なのは構造です。

まず確認するのは、次の5点です。

確認項目	見るべき理由
会社DBがあるか	1社単位で顧客を管理できるか
担当者DBがあるか	複数担当者、異動、役割を扱えるか
商談DBがあるか	同じ会社に複数商談があっても追えるか
対応履歴DBがあるか	メール、面談、電話、問い合わせの履歴を残せるか
タスクDBがあるか	次回連絡、資料作成、見積送付を追えるか

1つのDBだけで完結しているテンプレートは、個人の簡易管理には使えます。

しかし、チーム営業や継続的な顧客管理には足りないことが多いです。

Notion公式のテンプレートガイドでは、テンプレートはワークスペースに追加できる既成ページであり、追加後に自由に変更、編集、更新できると説明されています。

Notion公式ガイド：Notionテンプレート完全ガイド

つまり、テンプレートは完成品ではありません。

自社の営業プロセスに合わせて直す前提で選ぶものです。

Notion顧客管理の作り方

テンプレート選定基準

顧客管理テンプレートを選ぶときは、次の順番で見ます。

順番	確認すること	判断
1	何を1行にしているか	顧客、商談、担当者が混ざっていないか
2	DBが分かれているか	会社、担当者、商談、履歴、タスクを分けられるか
3	必須プロパティがあるか	担当者、期限、フェーズ、次回連絡日があるか
4	ビューが実務向きか	今日やること、確認待ち、フォロー漏れを見られるか
5	権限を分けられるか	顧客情報や商談情報を必要範囲に限定できるか
6	将来移行できるか	CRMや会計ソフトへ移す余地があるか

特に、1行の意味は重要です。

テンプレートの1行	向いている用途
1行 = 1社	顧客台帳、会社別の管理
1行 = 1担当者	名刺管理、接点管理
1行 = 1商談	パイプライン、売上見込み
1行 = 1接点	対応履歴、面談ログ
1行 = 1タスク	次回連絡、営業作業

「顧客管理テンプレート」と書かれていても、実際には商談管理テンプレートのことがあります。

逆に、CRMテンプレートと書かれていても、会社名とメモだけの簡易台帳のこともあります。

名前ではなく、1行の意味とDBの分け方を見ます。

必須DB

テンプレートを選ぶ時は、最低限次のDBがあるかを確認します。

DB	必須度	なければ起きる問題
会社DB	高	顧客企業の台帳が作れない
担当者DB	中	複数窓口、異動、決裁者を扱いにくい
商談DB	高	商談の進捗や見込みが会社情報に混ざる
対応履歴DB	中	面談やメールの経緯が本文に埋もれる
タスクDB	高	次回連絡や資料作成が追えない

小さく始めるなら、会社DB、商談DB、タスクDBの3つでも構いません。

ただし、顧客対応が増えるなら担当者DBと対応履歴DBも必要になります。

テンプレート例として、NotionマーケットプレイスにはCRMとパイプラインを扱うテンプレートもあります。

Notion Marketplace：Simple CRM + Pipeline

ただし、個別テンプレートはあくまで例です。

採用する前に、自社の営業プロセスに必要なDBがあるかを見ます。

必要なDBがなければ、テンプレートを使わないのではなく、複製後に追加します。

足りないDB	追加する理由
担当者DB	1社に複数人いる顧客を扱うため
対応履歴DB	面談、メール、電話の接点を追うため
タスクDB	次回アクションを漏らさないため
商品、サービスDB	複数商材の提案を扱うため
請求前確認DB	契約や請求前の確認を分けるため

必須プロパティ

DBがあっても、プロパティが足りないと運用できません。

まず、会社DBには次の項目が必要です。

プロパティ	型	確認ポイント
会社名	タイトル	1社を識別できるか
種別	セレクト	リード、既存顧客、休眠、パートナーなどを分けられるか
担当営業	ユーザー	社内責任者が分かるか
契約状況	ステータス	未契約、商談中、契約中、解約などを管理できるか
関連商談	リレーション	商談DBとつながるか
関連担当者	リレーション	担当者DBとつながるか
最終接点日	ロールアップ、日付	放置顧客を見つけられるか

商談DBには、次の項目が必要です。

プロパティ	型	確認ポイント
商談名	タイトル	提案や案件を識別できるか
会社	リレーション	顧客と紐づくか
社内担当	ユーザー	誰が追うか分かるか
フェーズ	ステータス	営業プロセスに合っているか
見込み金額	数値	売上見込みを見られるか
受注予定日	日付	いつ決まる見込みか分かるか
次回アクション	リレーション	タスクDBとつながるか
失注理由	セレクト、テキスト	振り返りに使えるか

タスクDBには、次の項目が必要です。

プロパティ	型	確認ポイント
タスク名	タイトル	何をするか分かるか
担当者	ユーザー	実行者が分かるか
期限	日付	遅れを拾えるか
ステータス	ステータス	未着手、進行中、確認待ち、完了を分けられるか
関連会社	リレーション	顧客別に見られるか
関連商談	リレーション	商談別に見られるか
完了条件	テキスト	何をもって完了か分かるか

テンプレートにプロパティが多すぎる場合も注意します。

使わない列が多いと、入力されません。

最初は、担当者、期限、フェーズ、次回アクション、最終接点日を確実に入れる方が重要です。

ビュー設計

顧客管理テンプレートは、DBの中身だけでなくビューを見ます。

営業チームで使うなら、最低限次のビューが必要です。

ビュー	目的
商談パイプライン	フェーズ別に商談を見る
今日の営業タスク	今日までに対応すべき作業を見る
自分の担当顧客	担当者別に会社や商談を見る
フォロー漏れ	最終接点日や次回連絡日から放置を見つける
確認待ち	見積、提案、契約前確認を拾う
失注一覧	失注理由を振り返る

見た目が整ったダッシュボードでも、フォロー漏れを見つけられないなら実務では弱いです。

特に必要なのは、日次と週次のビューです。

タイミング	見るビュー
毎朝	今日の営業タスク、期限超過
営業会議	商談パイプライン、確認待ち、失注一覧
週次	フォロー漏れ、担当者未設定、次回連絡日なし
月次	見込み金額、受注、失注理由、CRM移行の必要性

テンプレートにビューがなければ、複製後に追加します。

Notionテンプレートは、複製後にDBプロパティやビューを変更できるものとして考えます。

権限チェック

顧客管理テンプレートは、権限も確認します。

テンプレートの中には、サンプル用にすべての情報が同じページに置かれているものがあります。

そのまま実運用にすると、見せるべきでない情報まで広がります。

情報	権限の考え方
会社名、公開情報	営業チーム内で共有しやすい
担当者名、メール、電話	必要なメンバーに限定する
商談金額、確度	営業、経営、関係者に限定する
契約条件、請求前情報	Notion外や限定DBで扱う
面談メモ、内部メモ	外部共有ページには出さない

外部共有ページに、顧客管理DBのリンクドビューを置く場合は特に注意します。

顧客名、担当者、商談金額、社内メモが見えていないか確認します。

顧客向けページを作るなら、社内CRM用DBとは分けます。

テンプレートを選ぶ段階で、権限を分けやすい構造かを見ておくべきです。

Notion権限設定の基本

使い始めの調整

テンプレートを複製したら、そのまま使い始めず、先に調整します。

最低限、次の作業をします。

調整	内容
サンプルデータ削除	例示用の顧客、商談、タスクを消す
フェーズ名の変更	自社の営業プロセスに合わせる
プロパティ整理	使わない項目を削除し、必須項目を追加する
リレーション確認	会社、担当者、商談、タスクがつながっているか見る
ビュー追加	今日のタスク、フォロー漏れ、確認待ちを作る
権限設定	顧客情報を見られる範囲を決める
入力ルール作成	どの項目を誰がいつ入れるか決める

特にフェーズ名は、自社の営業プロセスに合わせます。

よくあるフェーズ	調整例
Lead	リード
Contacted	初回接点
Proposal	提案中
Negotiation	見積、条件調整
Closed won	受注
Closed lost	失注

英語のままでも使えますが、チームで意味が揃わないなら日本語にします。

また、テンプレートにAI要約欄を追加する場合は、正式メモと分けます。

AIで作る	人が確認する
面談要約の下書き	顧客履歴に残す内容
優先度候補	実際の優先度
次回アクション候補	担当者と期限
失注理由の分類候補	最終的な失注理由

AI出力をそのまま顧客履歴や商談フェーズに反映しない方がよいです。

顧客管理では、誤読や過剰な要約が営業判断に影響します。

CRM移行のサイン

Notion顧客管理テンプレートは、立ち上げには便利です。

営業プロセスを試し、必要項目を固め、チームの運用を作るには向いています。

ただし、次の状態になったら、専用CRMやkintoneなどへ移す判断をします。

サイン	理由
商談数が多くなった	パイプライン集計、売上予測、履歴管理が重くなる
営業担当者が増えた	権限、入力ルール、レビュー運用が複雑になる
フォーム、MA、メール配信と連携したい	顧客セグメントや配信履歴が必要になる
見積、契約、請求とつながる	正式台帳や承認履歴が必要になる
名寄せや重複排除が増えた	顧客マスタとしての品質管理が必要になる
監査や権限要件が強い	Notionだけでの管理責任が重くなる

Notionをやめるという意味ではありません。

CRMへ移した後も、Notionは営業ナレッジ、提案テンプレート、議事録、商談レビュー、社内共有に使えます。

テンプレートは、最初の営業管理を形にするための入口です。

その入口で、会社、担当者、商談、対応履歴、タスクを分けておけば、あとでCRMへ移す時も整理しやすくなります。

Notion顧客管理テンプレートを選ぶ時は、見た目ではなく、業務データの分け方を見る。

この判断だけで、テンプレートがただのメモ帳で終わるか、小さなCRMとして育つかが変わります。