Notion顧客管理は、予約受付を一つのアプリで完結させる方法ではありません。顧客情報と予約履歴をまとめ、次の対応を見失わないための台帳です。受付と決済は目的に合うサービスへ分けます。
Notion顧客管理で分ける三つの役割
個人事業では顧客名簿だけを作っても運用が続きません。予約日時、対応状況、次回連絡までつながる構造が必要です。
最初に役割を三つへ分けます。各機能の責任範囲が見えると、連携漏れを防げます。
- 予約枠を受け付ける
Notion Calendarの予約リンクで空き時間を共有できます。日程変更やキャンセルも予約者側から進められます。 - 顧客情報を蓄積する
Notionのデータベースへ連絡先や対応状況を記録します。予約履歴は別データベースにすると再利用しやすくなります。 - 支払いを確認する
前払いが必要なら決済サービスを別に用意します。支払済みと面談済みを同じ状態へまとめない方が安全です。
一つへ詰め込むより、台帳を中心に役割をつなぎます。予約や決済の専門機能も残せます。
現行仕様と料金で見える開始ライン
Notion Calendarは無料で使えると案内されています。予約リンクには単発と繰り返しの二種類があります。競合予定を避ける設定も利用できます。
Notion本体の公開料金はFreeが0ドルです。Plusは一席あたり月10ドルと表示されています。Businessは月20ドルです。
無料と有料の境目は次の通りです。為替や請求条件は契約画面で再確認します。
- Freeで試す
個人利用のページとデータベースを作れます。基本フォームやCalendarも小さな検証に使えます。 - Plusへ上げる
データベース自動化を編集して定型処理を減らせます。公開フォームのブランド表示も外せます。 - 外部連携を足す
Webhookアクションは有料プランで利用できます。認証なしの送信仕様なので受信側の防御が必要です。
最初から有料化する必要はありません。手作業が増えた部分だけを自動化へ置き換えます。
判断表で決める予約と台帳の境界
面談予約と店舗予約では必要な機能が違います。人数、メニュー、前払いの有無から構成を選びます。
迷う場合は次の四つへ当てはめます。公式機能にない部分を推測で補わないことが大切です。
- 一対一の相談予約
Calendarの予約リンクから始めやすい形です。顧客ページへ面談記録を関連付けます。 - 事前ヒアリング付き予約
Notionフォームで回答を受けて台帳へ保存します。予約日時との照合方法は運営側で決めます。 - 前払いを伴う予約
決済リンクや予約サービスを組み合わせます。入金前の枠確保をどう扱うかも定めます。 - 複数スタッフや設備の予約
専用予約システムも比較対象にします。重複防止や担当振分を人手だけに頼らない方が安全です。
Notionの顧客台帳を中心にしても、受付方法は一種類に固定しません。業務ごとに必要な入口を選べます。
向く条件と向かない条件
自由に項目を作れる点は小規模運用と相性がよいです。その自由さは設計と保守の責任にもなります。
導入前に次の条件を確認します。現在の予約件数だけでなく半年後の担当人数も考えます。
- 向いている条件
一人か少人数で顧客対応を共有する事業です。面談メモと次回行動を同じ場所で追えます。 - 試してから決める条件
月の予約件数が少なく流れが固まっていない事業です。Freeで台帳を作り、必要項目を見極められます。 - 専用機能を優先する条件
席数や設備在庫まで自動で割り当てる事業です。予約制御は専用サービスへ任せる方が管理しやすくなります。 - 別基盤も検討する条件
厳格な権限分離や大量処理が必要な事業です。要件に合うCRMや業務システムも比較します。
Notionを使わない判断も正解です。自由度より事故を減らす機能が重要な業務もあります。
予約構成を作る具体的な手順
最初は顧客、予約、対応履歴の三つを作ります。入力元が違っても同じ顧客へ戻れる設計にします。
- 顧客データベースを作る
氏名、連絡先、同意、担当を必要最小限で持ちます。顧客ごとのページへ面談メモを残します。 - 予約データベースを分ける
予約日時、状態、受付経路を記録します。一人の顧客へ複数予約を関連付けます。 - リレーションを設定する
顧客と予約を相互に参照できるようにします。ロールアップで予約回数や最終日を集計できます。 - 予約リンクを作る
Calendarで単発か繰り返しのリンクを選びます。受付期間や場所も実際の提供条件へ合わせます。 - 受付後の転記を決める
最初は担当者が予約を台帳へ確認入力します。件数が増えたら連携可能性を検証します。 - 次回行動を見える化する
対応待ちや連絡予定日でビューを分けます。放置案件を週ごとに確認します。
自動化より先に手順を一周させます。例外が見えてから連携範囲を決める方が直しやすくなります。
顧客台帳に持たせる項目
項目を増やしすぎると更新が止まります。予約後の行動に使う情報だけから始めます。
- 基本の識別情報
氏名と連絡先を保存します。同姓同名でも区別できる内部IDを用意します。 - 予約と対応の状態
仮受付、確定、完了、取消を分けます。支払状態は別項目で追跡します。 - 次回の行動
連絡予定日と担当者を持たせます。期限を過ぎた顧客だけを一覧で確認します。 - 同意と確認日
連絡や情報保管に必要な確認を記録します。事業に応じた法的判断は専門家へ相談します。
カード番号や不要な機微情報は保存しません。取得目的と保管期間も事前に決めます。
個人情報と運用上の注意
顧客情報を集める以上、共有範囲の確認が欠かせません。フォームの公開範囲とデータベース権限は別に点検します。
日常運用では次の事故を想定します。便利な共有リンクほど設定を定期確認します。
- 公開範囲の誤り
顧客台帳をWeb公開しないようにします。フォームの回答先データベースも権限を見直します。 - 予約と顧客の取り違え
メールアドレスだけで自動統合しない運用も検討します。候補が複数なら人が確認します。 - 退会者のアクセス
メンバーとゲストを定期的に棚卸しします。不要な共有権限は確認後に外します。 - 自動化の連鎖
Notionの自動化は別の自動化を起動できません。期待する処理順をテストで確かめます。
法務や個人情報保護の結論は事業ごとに異なります。必要に応じて専門家へ確認してください。
実装確認のチェックリスト
公開前は顧客役と運営者役の両方で試します。結果には確認日と担当者を残します。
- 新規予約
空き枠を選んで予定が登録されるか確かめます。通知内容と会議場所も読み直します。 - 変更と取消
予約者側から日程を変更します。台帳の状態を誰が直すかも確認します。 - フォーム回答
外部の利用者として回答を送ります。不要な内部項目が見えていないか点検します。 - 重複顧客
同じ人が別経路から申し込むケースを試します。統合前に履歴が失われないようにします。 - 権限と共有
閲覧だけの担当者で台帳を開きます。編集できる範囲が想定通りか確かめます。 - スマートフォン
予約リンクとフォームを小さい画面で進めます。入力欄や案内が横へはみ出さないか見ます。
一度の成功だけで完成とは判断しません。変更、取消、重複を含めて運用を確認します。
公式情報で確認した現行仕様
以下は2026年8月5日に確認した一次情報です。導入時には各公式ページを再確認してください。
- Notionの料金と機能
公式料金ページでFree、Plus、Businessの表示を確認しました。フォームや自動化のプラン差も掲載されています。 - Webフォーム
公式フォーム資料でWeb上の利用者へ共有できる条件を確認しました。回答先データベースの権限も説明されています。 - 予約リンク
公式Calendar資料で単発と繰り返しのリンクを確認しました。変更とキャンセルの扱いも案内されています。 - 顧客と予約の関連付け
公式データベース資料でリレーションとロールアップを確認しました。顧客別の集計へ応用できます。 - データベース自動化
公式自動化資料で有料プランの条件を確認しました。自動化同士が連鎖しない制限も明記されています。 - Webhookアクション
公式Webhook資料で外部送信の仕様を確認しました。送信に認証を付けられない点も説明されています。
AIは調査と構成の補助に使用しました。公開前後の内容とリンクは人が確認する運用方針です。
Notion顧客管理の導入相談を考える目安
予約件数が少ない段階なら自分で台帳を試せます。決済、通知、複数担当が加わると設計範囲は広がります。
Literamentでは、支援内容と料金を公開しています。Notion顧客管理と予約サービスの組み合わせに迷う場合は、お問い合わせから現状をご相談ください。