機能を比べる前に、
線を引く場所を決めてください

最も重要な論点です。A店の会員がB店に行ったとき、B店で来店履歴が見えるべきか。見えるべきなら、顧客データベースは全社共通にする必要があります。ただし、店舗ごとに独立した商売として運営している場合や、個人情報の取り扱い方針上、店をまたいで見せたくない場合もあります。ここを決めずに導入すると、後から構造を変えるのは大がかりな作業になります。

「いつもはA店だけど、今日は職場近くのB店で」という予約を認めるか。認めるなら、予約画面で店舗を選ぶ導線が必要になり、空き枠も横断で見せることになります。認めないなら、店舗ごとに独立した予約ページで十分です。飲食や物販では横断が自然ですが、担当者との関係が強い業種では、あえて分けたほうが運用が安定することもあります。

全店同じメニュー・同じ料金なら、本部で一括登録できる形が圧倒的に楽です。一方、立地によって価格が違う、店舗限定メニューがある、という場合は、共通部分と個別部分を分けて持てる必要があります。「共通メニュー＋店舗独自メニュー」という二層構造に対応しているかは、必ず確認してください。

店長は自店だけ、エリアマネージャーは担当エリア、本部は全店。この権限の階層が製品側で表現できるかは、店舗数が増えるほど効いてきます。全員が全店を見られる設計だと、情報管理の面で問題が出ます。逆に、店長が自店の設定すら変えられないと、現場が回りません。実際の組織図に当てはめて確認してください。

当たり前のようですが、製品によっては全店共通でしか設定できないものもあります。立地によって営業時間が違う、店舗ごとに定休日が違う、臨時休業を店長が自分で登録したい——この3つができるかを確認してください。できないと、本部への連絡と設定依頼が毎回発生します。

週の前半はA店、後半はB店というスタッフがいる場合、そのスタッフの予約枠が両店で正しく管理される必要があります。これができていないと、同じ時間に両店で予約が入る、という事故が起きます。兼務が発生する運営なら、この点は必須要件になります。

全社の合計、店舗別、エリア別、スタッフ別、メニュー別。本部が意思決定に使う切り口を先に決めておくと、必要なレポート機能が明確になります。「とりあえず全部見たい」だと、どの製品を見ても足りないか、多すぎるかのどちらかになります。

出店ペースが速い会社では、ここが実務上の分かれ目になります。既存店の設定を複製して新店を作れるか、それとも毎回ゼロから設定するのか。10店舗を超えたあたりから、この差が効いてきます。将来の店舗数を想定して確認してください。

1店舗ごとに月額が積み上がる形か、一定の店舗数までは定額か。出店計画がある場合、5店舗時点・10店舗時点の月額を試算しておくべきです。初期は安くても、店舗数が増えると想定外の額になることがあります。契約単位（会社単位か店舗単位か）も併せて確認してください。

直営だけだったところにFCが加わる、暖簾分けで独立する店が出る、店舗を譲渡する。こうした変化が起きたとき、顧客データや予約データをどう分けるのかを事前に確認しておくと安心です。「切り出せない」構造だと、将来の選択肢が狭まります。