結婚式場・ホテル婚礼部門の予約管理と顧客管理を一つのシステムにまとめる設計の勘所。来館予約・打ち合わせ・見積もり・成約を、Excelと紙の分断から一本の記録へ

この記事の結論：結婚式場やホテル婚礼部門の予約管理と顧客管理を一つのシステムにまとめるときは、画面や機能より先に、記録の単位を「一組の結婚式（案件）」に決めます。来館予約・打ち合わせ・見積もり・成約は、すべてその案件にぶら下がる記録として持ち、案件の段階は一つの項目で管理します。会場と日取りの仮押さえはデータベースの制約で二重に入らないようにし、見積もりは上書きせず版で残します。Excel・紙・複数ツールからの移行は、進行中の案件から始め、過去の台帳は読み取り専用で残します。

読み手として考えているのは、婚礼の現場で予約や顧客の台帳を預かる方と、その仕組みを組む開発者です。特定の製品や式場の事例は扱わず、仕組みの考え方だけをまとめます。

予約と顧客の記録が分かれるのは、段階ごとに別の台帳へ載るから

婚礼の記録がばらばらになるのは、同じお客様が段階を進むたびに、別の道具へ書き写されていくからです。どの段階で、どの道具に移っているかを書き出すと、まとめるべき場所が見えてきます。

どの道具も、それぞれの段階では十分に役立っています。困るのは、段階をまたぐたびに転記が起き、写し間違いと「どれが正しいか分からない」状態が積み重なることです。一つのシステムにまとめる目的は、この転記をなくし、一つの記録を見れば案件の今が分かる状態にすることです。

記録の中心に置くのは、人ではなく一組の結婚式（案件）

一つのシステムの中心には、新郎・新婦の一人ひとりではなく、「一組の結婚式」を表す案件の記録を置きます。来館も見積もりも契約も、二人のどちらか一方ではなく、お二人の結婚式に対して起きる出来事だからです。

骨組みだけを表にすると、次のようになります。

-- 骨組みの例（項目は最小限）
CREATE TABLE wedding_case (
  id            BIGSERIAL PRIMARY KEY,
  stage         TEXT NOT NULL,          -- 段階（次の節の一覧）
  owner_staff   BIGINT,                 -- 担当者
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE case_person (
  case_id  BIGINT REFERENCES wedding_case(id),
  person_id BIGINT REFERENCES person(id),
  role     TEXT                         -- 新郎・新婦・ご家族 など
);
CREATE TABLE visit_reservation (
  id       BIGSERIAL PRIMARY KEY,
  case_id  BIGINT REFERENCES wedding_case(id),
  starts_at TIMESTAMPTZ NOT NULL,
  kind     TEXT NOT NULL,               -- フェア・相談・試食 など
  attended BOOLEAN                      -- 来館したか（当日以降に記録）
);

人を単位にした作りだと、片方から予約があり、もう片方から問い合わせがあったとき、同じ結婚式の記録が二つに割れます。案件を中心にしておけば、どちらから連絡が来ても一つの記録にたどり着けます。来館数や成約率の数え方をそろえる話は、来館と成約の数え方の記事で別に扱っています。

案件の段階は一つの項目で持ち、次へ進む条件を決める

案件が今どこにいるかは、一つの「段階」の項目で持ち、段階を進める条件を先に文章で決めます。チェックボックスをいくつも並べて段階を表すと、矛盾した組み合わせが生まれ、一覧で絞り込めなくなります。

段階を進めるたびに、いつ、誰が、どこからどこへ動かしたかを別の記録に残します。この履歴があれば、「来館から仮予約までに何日かかったか」を後から数えられます。見送りやキャンセルの理由は、自由記入だけにせず、いくつかの選択肢から選ぶ形にすると、集計に使えます。

会場と日取りの仮押さえは、二重に入らない仕組みにする

会場と日取りの押さえは、画面の確認ではなく、データベースの制約で二重に入らないようにします。同じ日の同じ会場を、二人の担当者が同時に押さえようとしたとき、画面の確認だけでは両方の登録が通ってしまうからです。

-- 仮押さえと本予約を合わせて、同じ枠に一つだけ入れる
CREATE TABLE venue_hold (
  id         BIGSERIAL PRIMARY KEY,
  case_id    BIGINT REFERENCES wedding_case(id),
  venue_id   BIGINT NOT NULL,
  event_date DATE NOT NULL,
  slot       TEXT NOT NULL,             -- 午前・午後・夜 など
  status     TEXT NOT NULL,             -- tentative（仮）/ confirmed（本予約）/ released（解除）
  expires_at TIMESTAMPTZ
);
CREATE UNIQUE INDEX one_active_hold
  ON venue_hold (venue_id, event_date, slot)
  WHERE status IN ('tentative', 'confirmed');

期限を過ぎた仮押さえを自動で外す処理は、外したことを担当者とお客様の記録の両方に残すところまでを一つの処理にします。外れたことに担当者が気づかないまま、お客様に「押さえてあります」と伝えてしまうのが、いちばん避けたい事故です。

見積もりは上書きせず、版で残す

見積もりは、直すたびに新しい版として保存し、前の版を消さない作りにします。打ち合わせが進むと金額は動くものなので、「いつ、何が、なぜ変わったか」を後から説明できることが、お客様との信頼に直結します。

版を残しておくと、二つの版の明細を並べて、増えた品目と減った品目を自動で示せます。打ち合わせの席でその差を見せれば、「最初の見積もりと違う」という不安に、その場で答えられます。

見積書をメールなどでやり取りした場合、その記録は電子帳簿保存法の電子取引の記録として、電子のまま保存する決まりがあります。保存の要件は国税庁の案内に沿って確かめ、見積もりの版を消さない作りと合わせて設計します。

誰が何を見られるかを、役割ごとに決める

一つのシステムにまとめると、多くの人が同じ記録にアクセスするようになるので、役割ごとに見られる範囲と操作できる範囲を決めます。紙や担当者ごとのファイルでは自然に分かれていた範囲が、まとめた途端に全員に見えてしまうことがあるからです。

通則編と呼ばれる個人情報保護委員会の指針では、個人データを扱う事業者に組織・人・物理・技術の面での安全管理の措置を求めており、技術の面の例としてアクセスの制御が挙げられています。役割ごとの範囲を決めることは、この措置を仕組みとして形にすることでもあります。誰がいつどの記録を見て、何を変えたかの記録も、最初の版から残します。

Excelと紙からの移行は、進行中の案件から始める

移行は、進行中の案件だけを先に移し、施行が済んだ過去の台帳は読み取り専用で残す順番が確実です。すべてを一度に移そうとすると、表記の揺れや重複の整理に時間がかかり、現場が新しいシステムを使い始める日が遠のきます。

1. 今使っている台帳をすべて並べる。 予約の一覧、見積もりのファイル、会場の予定表、紙のシートの項目を書き出す
2. 案件を一つにまとめる。 同じ結婚式が複数の台帳に載っていたら、どれが同じ案件かを決める
3. 進行中の案件だけを移す。 来館予約から打ち合わせ中までの案件を新しいシステムへ入れる
4. 会場の押さえを最後に照らし合わせる。 移したあと、予定表と新しいシステムの押さえが一致しているかを一件ずつ確かめる
5. 切り替えの日を決める。 その日からは新しいシステムだけに書き、古い台帳は読み取り専用にする

並行して二つの台帳に書く期間は、短く区切ります。両方に書く期間が長いと、どちらかが古くなり、結局どちらも信用されなくなります。

既製の顧客管理を使うか、作るかは、段階と押さえの持ち方で決める

既製の顧客管理サービスで足りるかどうかは、案件を中心にした記録と、会場の押さえの制約を、その製品で持てるかで判断します。一般的な顧客管理は「会社」や「個人」を中心に作られていることが多く、二人で一組の結婚式と、日取りの押さえを同じ記録で扱えるかが分かれ目になります。

一つの業種に限らない予約管理システムなら、株式会社bundlyzeでは企画から運用まで開発してきました。婚礼の記録の単位や押さえの持ち方から決めていく相談の流れは、業務システムの開発のご案内（bundlyze）に書いています。

出典

確認日はどちらも2026年10月2日で、いずれも公的な資料です。指針や保存の要件は見直されることがあるので、設計を固める段階で改めて最新版を確かめてください。

• 通則編のガイドライン：安全管理の措置とアクセスの制御（個人情報保護委員会）
• 国税庁「電子帳簿保存法関係」：電子取引で受け渡した見積書などの保存