Notionシステム研究所 > Notion名刺管理の作り方|顧客DBと営業フォローにつなげる
2026年6月6日
•約12分で読めます
Notionで名刺管理を作る方法を、担当者DB、会社DB、接点履歴、次回フォロー、権限、専用アプリを使う判断まで整理します。
Notionで名刺管理をしたいです。名刺の写真を貼って、名前と会社名を入れておけば十分ですか。
保管だけならそれでもよい。ただし営業で使うなら、名刺画像よりも「誰と、どの会社で、いつ会って、次に何をするか」が重要じゃ。Notionでは名刺を担当者DBと接点履歴に分けて管理するのがよい。
Notionで名刺管理を作ることはできます。
名前を一覧にする。
会社名や役職を入れる。
イベント名や初回接点を残す。
会社DBとつなぐ。
次回連絡のタスクを作る。
こうした「営業フォローにつなげる名刺管理」なら、Notionは使いやすいです。
Notion公式の営業テンプレートカテゴリでも、リードや顧客関係を管理し、営業プロセスを強化する用途が紹介されています。
ただし、Notion名刺管理で失敗するパターンもあります。
Notion名刺管理は、名刺画像の保管場所ではなく、担当者DB、会社DB、接点履歴DB、フォロータスクをつなぐ営業接点の入口 として作る方が実務で使えます。
この記事では、Notionで名刺管理を作る方法を、名刺管理で残す情報、担当者DB、会社DBとの関係、接点履歴、次回フォロー、権限と個人情報、専用アプリを使う判断まで整理します。
Notionで名刺管理をするなら、名刺を1枚の画像として保管するより、担当者DBの1行として扱います。
| 管理対象 | Notionでの置き場所 | 理由 |
|---|---|---|
| 氏名、役職、連絡先 | 担当者DB | 1人単位で検索、更新できる |
| 会社名、業種、関係性 | 会社DB | 同じ会社の複数人をまとめられる |
| 出会った日、場所、経緯 | 接点履歴DB | 展示会、紹介、面談などの文脈を残せる |
| 次回連絡、資料送付 | タスクDB | フォロー漏れを防げる |
| 商談化した案件 | 商談DB | 営業進捗や見込み管理へつなげられる |
| 名刺画像 | 添付、外部ストレージ | 原本確認用に残す程度でよい |
名刺管理で重要なのは、名刺そのものではありません。
その人と今後どう関係を続けるかです。
Notion公式ヘルプでは、データベースはページの集合であり、プロパティやビューで情報を整理できると説明されています。
名刺管理でも、この考え方を使います。
1行を「名刺」ではなく「担当者」にする。
会社、接点、次回フォローをリレーションでつなぐ。
この形にしておくと、あとで顧客管理や商談管理へつなげやすくなります。
名刺管理で残す情報は、すべて同じ重要度ではありません。
まず、営業フォローに必要な情報と、原本確認用の情報を分けます。
| 情報 | 必須度 | 用途 |
|---|---|---|
| 氏名 | 高 | 担当者を識別する |
| 会社名 | 高 | 会社DBとつなぐ |
| 役職、部署 | 中 | 決裁者、実務担当者、紹介者を判断する |
| メール | 高 | フォロー連絡に使う |
| 電話番号 | 中 | 必要な営業スタイルなら使う |
| 初回接点日 | 高 | いつ会ったかを残す |
| 接点経路 | 高 | 展示会、紹介、問い合わせ、商談などを分ける |
| 関心テーマ | 中 | 次回提案やナーチャリングに使う |
| 次回フォロー日 | 高 | 放置を防ぐ |
| 名刺画像 | 低から中 | 原本確認用 |
Notionに入れるべきなのは、後から検索したり、次の行動につながったりする情報です。
名刺画像だけを大量に貼っても、営業では使いにくいです。
たとえば、次のような問いに答えられる必要があります。
| 問い | 必要なDB、プロパティ |
|---|---|
| 展示会で会った人に誰がフォローするか | 接点履歴、担当者、フォロー担当 |
| 同じ会社の誰と会ったことがあるか | 会社DB、担当者DB |
| 決裁者か実務担当者か | 担当者DBの役割 |
| 前回どんな話をしたか | 接点履歴DB |
| 次にいつ連絡するか | タスクDB、次回フォロー日 |
名刺管理を営業に使うなら、名刺情報を「人」「会社」「接点」「次の行動」に分解します。
担当者DBは、名刺管理の中心です。
1行は1人です。
| プロパティ | 型 | 目的 |
|---|---|---|
| 氏名 | タイトル | 担当者を識別する |
| 所属会社 | リレーション | 会社DBとつなぐ |
| 部署 | テキスト | 所属部門を残す |
| 役職 | テキスト | 役割や意思決定権を判断する |
| メール | メール | 連絡先 |
| 電話 | 電話番号 | 必要な場合のみ |
| 役割 | セレクト | 決裁者、窓口、実務担当、紹介者など |
| 名刺交換日 | 日付 | 初回接点日として使う |
| 接点経路 | セレクト | 展示会、紹介、問い合わせ、既存顧客など |
| 関心テーマ | マルチセレクト | 提案やフォロー分類に使う |
| 関連接点 | リレーション | 接点履歴DBとつなぐ |
| 次回フォロー | リレーション | タスクDBとつなぐ |
| ステータス | ステータス | 未整理、フォロー予定、商談化、保留、不要など |
ここで大事なのは、担当者DBに何でも書き込まないことです。
担当者DBには、その人に紐づく基本情報を置きます。
面談メモ、メールの要約、商談の進捗は、別DBへ分けます。
| 担当者DBに置く | 別DBに分ける |
|---|---|
| 氏名、会社、役職 | 面談メモ |
| メール、電話 | メール対応履歴 |
| 役割、関心テーマ | 商談進捗 |
| 初回接点、接点経路 | 次回タスク |
| 個人情報の扱いメモ | 契約、請求情報 |
担当者DBをきれいに保つと、名刺管理は検索しやすくなります。
逆に、担当者ページ本文に毎回メモを追記していくと、最後に何をしたかが分からなくなります。
名刺管理では、担当者DBだけでなく会社DBも必要です。
理由は、1社に複数の担当者がいるからです。
| 会社DB | 担当者DB |
|---|---|
| 1行 = 1社 | 1行 = 1人 |
| 業種、地域、契約状況を持つ | 氏名、役職、メールを持つ |
| 関連担当者をロールアップで見る | 所属会社をリレーションで持つ |
| 関連商談や売上見込みを持つ | 関連接点や次回フォローを持つ |
会社DBには、会社単位で変わりにくい情報を置きます。
担当者DBには、人単位で変わる情報を置きます。
| 会社DBの項目 | 目的 |
|---|---|
| 会社名 | 顧客企業を識別する |
| 種別 | リード、既存顧客、パートナーなどを分ける |
| 業種 | 提案内容や事例分類に使う |
| 担当営業 | 社内責任者を決める |
| 関連担当者 | その会社の接点を一覧する |
| 関連商談 | 商談管理へつなぐ |
| 最終接点日 | 放置を見つける |
名刺を受け取った時点では、会社情報が少ないこともあります。
その場合でも、会社DBに仮登録しておきます。
あとから商談化した時に、会社情報と担当者情報を分けて持っておく方が整理しやすいからです。
名刺管理で抜けがちなのが、接点履歴です。
名刺を受け取った事実だけでは、営業フォローの判断ができません。
どこで会ったのか。
誰が紹介したのか。
何に関心がありそうだったのか。
何を送る約束をしたのか。
これを接点履歴DBに残します。
| プロパティ | 型 | 目的 |
|---|---|---|
| 接点名 | タイトル | 「2026-06 展示会 山田さん」など |
| 日付 | 日付 | いつ接点があったか |
| 接点種別 | セレクト | 名刺交換、展示会、紹介、初回面談、電話など |
| 担当者 | リレーション | 担当者DBとつなぐ |
| 会社 | リレーション | 会社DBとつなぐ |
| 社内担当 | ユーザー | 誰が対応したか |
| 内容メモ | テキスト | 話した要点 |
| 関心テーマ | マルチセレクト | 後日の提案分類に使う |
| 次回アクション | リレーション | タスクDBとつなぐ |
接点履歴DBを作ると、名刺交換が営業活動の履歴になります。
担当者DBのページ本文に「展示会で会った」「資料送る」などを書くだけだと、検索や集計が難しくなります。
接点履歴をDBにすると、次のようなビューを作れます。
| ビュー | 目的 |
|---|---|
| 今週の新規接点 | 最近会った人を確認する |
| 展示会別接点 | イベントごとのフォロー状況を見る |
| 紹介経由 | 紹介者や経路を確認する |
| フォロー未作成 | 次回アクションがない接点を拾う |
| 商談化済み | 接点から商談になったものを見る |
名刺管理を営業で使うなら、接点履歴は必須です。
名刺管理の成果は、登録件数ではなくフォロー件数です。
Notionでは、名刺登録後にタスクDBへつなげます。
| タスク | 例 |
|---|---|
| お礼メール | 名刺交換後、翌営業日までに送る |
| 資料送付 | 関心テーマに合わせて送る |
| 紹介者への報告 | 紹介経由の場合に行う |
| 初回面談打診 | 商談化しそうな相手へ送る |
| 一定期間後の再連絡 | すぐ商談化しない相手を追う |
タスクDBには、次のプロパティを用意します。
| プロパティ | 型 | 目的 |
|---|---|---|
| タスク名 | タイトル | 何をするか |
| 担当者 | ユーザー | 誰が実行するか |
| 期限 | 日付 | いつまでにやるか |
| ステータス | ステータス | 未着手、進行中、完了、保留 |
| 関連担当者 | リレーション | 名刺の相手とつなぐ |
| 関連会社 | リレーション | 会社DBとつなぐ |
| 関連接点 | リレーション | どの接点から生まれたか |
| 完了メモ | テキスト | 送付内容や反応を残す |
ビューは、行動に直結する形にします。
| ビュー | 条件 |
|---|---|
| 今日のフォロー | 期限が今日以前、未完了 |
| 自分の名刺フォロー | 担当者が自分、未完了 |
| 展示会後フォロー | 関連接点が展示会、未完了 |
| 期限切れ | 期限が過去、未完了 |
| 商談化候補 | 関心テーマがあり、ステータスがフォロー予定 |
名刺情報を登録しても、次回フォローがなければ営業にはつながりません。
名刺管理DBとタスクDBは、必ずセットで考えます。
名刺情報には個人情報が含まれます。
Notionで名刺管理をするなら、権限設計を後回しにしない方がよいです。
Notion公式ヘルプでは、ページ共有時に相手ごとに権限レベルを割り当てられ、閲覧、コメント、編集、フルアクセスなどを分けられると説明されています。
名刺管理では、次のように分けます。
| 情報 | 推奨権限 |
|---|---|
| 担当者DB | 営業、管理者のみ編集 |
| 会社DB | 関係部署は閲覧、営業が編集 |
| 接点履歴DB | 担当者と営業チームが編集 |
| タスクDB | 担当者が編集、管理者が確認 |
| 名刺画像 | 必要な人だけ閲覧 |
| 外部共有ページ | 原則として名刺情報を置かない |
特に注意するのは、外部共有です。
営業資料や提案ページを外部共有する場合でも、名刺情報や担当者DBを同じページ配下に置かない方がよいです。
親ページの権限やリンク共有の設定によって、意図せず広く見える可能性があるからです。
名刺情報は、見込み顧客の個人情報です。
「社内の誰でも見られる」状態にする前に、本当に必要かを確認します。
Notionだけで名刺管理を完結しない方がよい場合もあります。
| 状況 | 判断 |
|---|---|
| 名刺を大量にスキャンする | 名刺管理アプリやOCRサービスを使う |
| OCR精度が重要 | 専用アプリで読み取り、必要情報だけNotionへ渡す |
| 全社で名刺交換履歴を管理する | Sansan、Eight Teamなどの専用領域を検討する |
| 個人情報管理や監査が厳しい | 専用CRM、名刺管理システムを使う |
| 営業プロセスまで管理する | CRMへの移行を検討する |
| 小規模な営業フォロー中心 | Notionで十分な場合がある |
Notionが向いているのは、名刺情報を営業フォローや顧客DBにつなげたい場合です。
一方で、スキャン、OCR、重複名寄せ、全社共有、監査が主目的なら、専用アプリの方が向いています。
Notionで無理に全部をやる必要はありません。
Notionでは、担当者、会社、接点、次回フォローを管理する。
名刺画像の読み取りや厳密な個人情報管理は、必要に応じて専用アプリへ任せる。
この分担にすると、名刺管理はただの保管場所ではなく、営業活動の入口になります。
名刺管理で本当に見るべきなのは、何枚登録したかではありません。
誰に、いつ、どんな文脈で会い、次に何をするかです。
Notionでは、その流れをDBとタスクでつなぐことを優先しましょう。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。