Notion顧客管理の作り方｜商談・対応履歴・タスクをDBでつなぐ

Notionで顧客管理を作ることはできます。

会社名を並べる。

担当者名を入れる。

商談ステータスをボードで見る。

メールや面談メモをページ内に残す。

タスクDBとつないで、次回連絡日を管理する。

こうした使い方なら、Notionは小さなCRMとして使えます。

実際、Notion公式の営業テンプレートカテゴリでも、リードや顧客関係を管理し、営業プロセスを強化する用途が紹介されています。

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

ただし、Notion顧客管理で失敗するパターンも多いです。

• 1つのDBに会社、担当者、商談、タスク、請求メモが混ざる
• 会社名と担当者名が同じ行に入り、複数担当者を扱えない
• 商談が増えるたびに顧客行のステータスを上書きしてしまう
• 対応履歴がページ本文に散らばり、最後に誰が何をしたか分からない
• 次回連絡日が未入力のまま放置される
• 個人情報や契約前情報を外部共有ページに置いてしまう
• AI要約を確認せずに顧客メモへ入れてしまう
• 営業人数や案件数が増えても、専用CRMへ移す判断が遅れる

Notion顧客管理は、顧客名を並べる表ではなく、会社DB、担当者DB、商談DB、対応履歴DB、タスクDBを分けてつなぐ小さな営業システム として作る方が安定します。

この記事では、Notionで顧客管理を作る方法を、会社DB、担当者DB、商談DB、対応履歴、営業タスク、権限、CRMへ移す判断まで実務目線で整理します。

先に結論：顧客、商談、対応履歴を1つに混ぜない

Notionで顧客管理を作るときは、最初にDBを分けます。

最低限、次の5つを分けて考えます。

DB	1行の意味	役割
会社DB	1社	会社情報、業種、契約状況、担当営業を管理する
担当者DB	1人	顧客側の担当者、役職、連絡先、所属会社を管理する
商談DB	1商談	提案、見積、契約前後の進捗を管理する
対応履歴DB	1回の接点	メール、電話、面談、問い合わせ、フォローを残す
タスクDB	1作業	次回連絡、資料作成、見積送付、社内確認を追う

1つの表で始めると、最初は楽です。

しかし、顧客管理では同じ会社に複数の担当者がいます。

同じ会社で、複数の商談が並行することもあります。

1回の商談に、何度もメール、面談、資料送付、社内確認が発生します。

これらを1行に詰め込むと、必ず崩れます。

混ぜているもの	起きる問題
会社と担当者	退職、異動、複数窓口に対応できない
会社と商談	過去商談と現在商談が上書きされる
商談と対応履歴	どの接点で何が決まったか追えない
対応履歴とタスク	実施済みの記録と未来の作業が混ざる
顧客管理と請求管理	権限、履歴、正式台帳の責任が曖昧になる

Notion公式ヘルプでは、データベースはページの集まりであり、プロパティやビューを使って整理できると説明されています。

Notion公式ヘルプ：データベースの基本

顧客管理でも、この特徴を活かします。

1行を何にするかを決め、DB同士をリレーションでつなぐ。

それが、NotionをCRMとして使う時の基本です。

Notionデータベースの作り方

顧客管理に必要なDB

Notionで顧客管理を作るなら、最初から大きく作りすぎる必要はありません。

ただし、DBの分け方だけは早めに決めた方がよいです。

会社DB

会社DBは、顧客の母体です。

1行は1社です。

プロパティ	型	目的
会社名	タイトル	顧客企業を識別する
種別	セレクト	リード、既存顧客、休眠、パートナーなど
業種	セレクト	提案内容や事例分類に使う
担当営業	ユーザー	社内の責任者を決める
契約状況	ステータス	未契約、商談中、契約中、解約、休眠
関連担当者	リレーション	担当者DBとつなぐ
関連商談	リレーション	商談DBとつなぐ
最終接点日	ロールアップ、日付	対応履歴から直近接点を見る
次回連絡日	ロールアップ、日付	タスクや商談から次の動きを見る
メモ	テキスト	固定情報だけを書く

会社DBには、変わりにくい情報を置きます。

会社概要、業種、担当営業、契約状況などです。

日々変わる商談進捗や対応メモは、会社DBへ直接書きすぎない方がよいです。

担当者DB

担当者DBは、顧客側の人を管理するDBです。

1行は1人です。

プロパティ	型	目的
氏名	タイトル	顧客側担当者を識別する
所属会社	リレーション	会社DBとつなぐ
役職	テキスト	意思決定者、実務担当者などの判断に使う
メール	メール	連絡先
電話	電話番号	必要な場合のみ
役割	セレクト	決裁者、窓口、利用者、紹介者など
関連商談	リレーション	どの商談に関わるかを見る
最終接点日	ロールアップ	対応履歴から確認する

担当者DBを分ける理由は、会社と人のライフサイクルが違うからです。

会社は同じでも、担当者は異動します。

担当者が複数いることもあります。

1社1担当者の前提で作ると、営業の現実に合わなくなります。

会社DBと担当者DB

会社DBと担当者DBは、リレーションでつなぎます。

関係	設計
1社に複数担当者	会社DBと担当者DBをリレーションする
1担当者が複数商談に関わる	担当者DBと商談DBをリレーションする
退職、異動	担当者ステータスで管理し、過去履歴は消さない
窓口と決裁者	担当者DBの役割で分ける

会社DBに担当者名をテキストで書くだけでも、最初は使えます。

しかし、担当者が2人以上になるとすぐに困ります。

窓口、決裁者、利用部門、紹介者が分かれるからです。

顧客管理を営業で使うなら、会社DBと担当者DBは分けます。

ただし、個人事業主や小規模な問い合わせ管理だけなら、最初は会社DBと担当者DBを1つにしても構いません。

その場合でも、あとで分けられるように、次の項目は混ぜすぎない方がよいです。

項目	置き場所
会社名	会社情報
担当者名	担当者情報
メール	担当者情報
商談金額	商談情報
次回連絡	タスク情報
面談メモ	対応履歴

商談DB

商談DBは、営業プロセスを見るためのDBです。

1行は1商談です。

プロパティ	型	目的
商談名	タイトル	提案や案件を識別する
会社	リレーション	会社DBとつなぐ
担当者	リレーション	顧客側担当者を紐づける
社内担当	ユーザー	営業責任者
フェーズ	ステータス	リード、初回接点、提案中、見積中、契約待ち、失注、受注
見込み金額	数値	営業管理に使う
確度	セレクト、数値	A、B、Cや%で管理する
受注予定日	日付	見込み時期を見る
次回アクション	リレーション	タスクDBとつなぐ
関連履歴	リレーション	対応履歴DBとつなぐ
失注理由	セレクト、テキスト	振り返りに使う

商談DBで重要なのは、フェーズを作りすぎないことです。

最初は次の程度で十分です。

フェーズ	意味
リード	まだ具体的な提案前
初回接点	ヒアリングや紹介直後
提案中	提案内容を整理している
見積中	金額、条件、範囲を詰めている
契約待ち	契約、発注、稟議の待ち
受注	契約または発注済み
失注	見送り、競合負け、時期不一致

フェーズ名は営業チームで揃えます。

人によって「提案中」と「見積中」の意味が違うと、パイプラインは信用できません。

商談DBには、最新状態を置きます。

商談の経緯や会話の詳細は、対応履歴DBへ分けます。

対応履歴

対応履歴DBは、顧客との接点を残すDBです。

1行は1回の接点です。

プロパティ	型	目的
件名	タイトル	何の接点か分かるようにする
日時	日付	いつ対応したか
種別	セレクト	メール、電話、面談、紹介、問い合わせ、フォロー
会社	リレーション	会社DBとつなぐ
担当者	リレーション	顧客側担当者とつなぐ
関連商談	リレーション	商談DBとつなぐ
社内対応者	ユーザー	誰が対応したか
要約	テキスト	会話の要点
決定事項	テキスト	決まったこと
次アクション	リレーション	タスクDBとつなぐ
原本URL	URL	メール、議事録、録画、Slackなどへ戻る

対応履歴を会社DBのページ本文に書くだけだと、あとで拾えません。

「今月連絡していない顧客」

「提案後にフォローがない商談」

「担当者別の対応件数」

「次アクションがない面談」

こうした確認ができなくなります。

履歴はDBにします。

ただし、全文をNotionへ転記しすぎる必要はありません。

メール本文、契約条件、個人情報、添付ファイルなどは、原本側に残し、Notionには要約とリンクだけを置く方が安全です。

AIで面談メモやメール要約を作る場合も、正式な顧客履歴にする前に人が確認します。

AI要約は下書き、顧客履歴は確認済み情報 と分けると、誤読や個人情報の扱いを抑えられます。

営業タスク

顧客管理は、履歴を残すだけでは足りません。

次に何をするかを追う必要があります。

営業タスクは、タスクDBで管理します。

プロパティ	型	目的
タスク名	タイトル	作業内容
担当者	ユーザー	社内の実行者
期限	日付	次回連絡、資料作成、見積送付の期限
ステータス	ステータス	未着手、進行中、確認待ち、完了、保留
会社	リレーション	会社DBとつなぐ
商談	リレーション	商談DBとつなぐ
対応履歴	リレーション	どの接点から発生したか
完了条件	テキスト	何をもって終わりか
次回確認日	日付	保留時の確認日

営業タスクで特に重要なのは、次回連絡日です。

顧客管理が崩れる理由の多くは、情報がないことではありません。

次に誰が何をするかが決まっていないことです。

Notionには、次のビューを作ります。

ビュー	条件
今日の営業タスク	期限 が今日以前、ステータス が未完了
自分の未完了	担当者 が自分、ステータス が未完了
商談別タスク	商談 でグループ化
フォロー漏れ	次回確認日 が過去、ステータス が未完了
確認待ち	ステータス = 確認待ち

Notionタスク管理の作り方

タスクDBを分けると、営業会議で確認しやすくなります。

商談DBだけを見ていると、「提案中」と表示されていても、実際に次の作業があるか分かりません。

タスクDBまで見ると、見積作成、社内確認、顧客返信、次回面談設定が追えます。

権限と個人情報

顧客管理では、権限設計を軽く見ない方がよいです。

Notion公式の共有と権限ガイドでは、共有メニューで誰がコンテンツにアクセスできるか、どの権限レベルかを管理できると説明されています。

Notion公式ガイド：Sharing & permissions

顧客管理では、次のように分けます。

情報	権限の考え方
会社名、公開情報	営業チーム内で共有しやすい
担当者名、メール、電話	必要なメンバーに限定する
商談金額、確度	営業、経営、関係者に限定する
契約条件、請求情報	Notionではなく契約、会計、CRM側に置く
個人的なメモ	顧客DBに残すべきか慎重に判断する
外部共有ページ	顧客情報を含むDBビューを置かない

Notionの外部共有は便利です。

しかし、顧客管理DBをそのまま外部共有するのは危険です。

共有するなら、顧客向けの専用ページを作り、必要な情報だけを置きます。

社内用の会社DB、商談DB、対応履歴DBをそのまま見せない方がよいです。

また、ページ本文に個人情報や契約前の内部メモを書きすぎると、あとで権限管理が難しくなります。

顧客管理では、入力できることより、見せてよい範囲を先に決めます。

CRMへ移す判断

Notionは、顧客管理の立ち上げには向いています。

営業プロセスを試し、項目を調整し、チームの運用を早く作れます。

ただし、Notionを正式なCRMとして使い続けるべきかは別問題です。

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

状態	移行を考える理由
営業担当者が増えた	権限、入力統制、パイプライン集計が重要になる
商談数が多い	予実、確度、売上見込みの管理が必要になる
問い合わせやフォーム連携が増えた	重複排除、名寄せ、外部連携が必要になる
見積、契約、請求とつながる	正式台帳や承認履歴が必要になる
メール配信やMAと連携したい	顧客セグメントと配信履歴が必要になる
監査、権限、履歴が厳しくなる	Notionだけでは管理責任が重くなる

Notionを使う意味がなくなるわけではありません。

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

顧客マスタや正式な商談台帳はCRM。

提案の文脈、会議メモ、ナレッジ、社内レビューはNotion。

この分担の方が安定することも多いです。

Notion顧客管理は、最初から完璧なCRMを作ることが目的ではありません。

まず、会社、担当者、商談、対応履歴、タスクを分ける。

次に、ビューと週次レビューで営業の動きを見えるようにする。

最後に、規模や統制が必要になったら、正式なCRMへ移す。

この順番で考えると、Notionを無理に使い続けず、営業管理の土台として活かせます。