この予約システムは二つの業種で共有されています。service と clinic です。動くコードは同じ——サービス、予約、担当者の割り当て、パッケージ——で、clinic を選ぶと画面の語彙が予約・患者・施術コースに置き換わります。歯科医院とネイルサロンは、同じ予約の問題を違う言葉で抱えているからです。業種の選択が変えるのは語彙だけで、構造は変えません。クリニック専用の製品を分ければ、2リリースのうちにサービス側とずれていきます。
サービスとは、店が決める所要時間と価格のこと
カタログはサービスの一覧で、それぞれに所要時間と価格が付きます。所要時間は飾りではありません。90分の施術と15分のカットが同じ一日の違う量を占めるからこそ、予定表が意味を持ちます。客は店の公開ページを見て、サービスを選んで予約します。そのページのセクションはサービスモジュール自身が提供していて、他のどのモジュールとも同じ共有 UI キットで作られているので、後付けではなく最初からそこにあるように見えます。
予約と、店が自分で押す確定
予約のリクエストは名前、電話番号、日付、時刻、備考を運びます。保留の状態で届き、店が確定します。未確定の件数はコンソールのダッシュボードのライブバッジの一つで、進行中の注文やスタッフを呼んでいるテーブル、未処理の休暇申請と並んで数秒ごとに更新されます。複数のモジュールを動かしている商売でも、人の判断を待っているものが一箇所で数えられます。
確定の一手間は、手間のための手間ではありません。カレンダーに空きがあれば何でも自動で受ける予約システムは、その日その技術者がいない予約を取りますし、10時が早く終わった場合にだけ成り立つ11時を取ります。受諾を人の行為にしておくことで、店自身が持っている知識が輪に残り、客には静かにずれていく枠ではなく、はっきりした答えが返ります。
予約はスタッフに割り当てられます。この一つの項目が、予約の一覧を働く一日に変えます。これを誰がやるのかに答え、常連を同じ担当者に戻せるようにし、顧客履歴に流れ込むので、常連が誰目当てで戻ってくるのかが店に分かります。
パッケージと前払いコース——N回、N日間有効
前払いの仕事は、普通の販売ではなく専用のモデルです。パッケージは、N日間有効なN回のコースか、N日間有効な会員資格です。客は買って、1回ずつ消化します。「マイパッケージ」のタブに、いま持っているものと残りが出ます。その残り回数は記録であり、財布の中のスタンプカードではなく、それを消費する予約と同じバックエンドの上にあります。
パッケージの購入は、レビュー資格のビューにある有資格の取引の一つでもあります。だからコースの客は、1回目を消化する前でもその店をレビューできます。
SMS のリマインダーはありません。SMS そのものがないからです。 電話番号の確認も SMS 送信も作られておらず、エンドポイントは 501 を返してそう言います。通知はアプリの中で客に届き、メールは確認済みのアドレスにだけ送られます。
クリニック業種はラベルの張り替えであって、診療録システムではありません。 予約を患者と施術コースに呼び替えるだけです。診療メモや処方など、電子カルテにあるべきものは保存しませんし、そのために作られてもいません。
その周りでオーナーが手にするもの——レポート、顧客台帳、勤怠
サービスまたはクリニックのビジネスには、予約・サービス・パッケージという3つのモジュールタイルに加えて、どの業種にも付くものが全部揃います。レポートは売上、件数、客単価、現金 / PromptPay / その他の内訳、売れ筋トップ5、7日間の売上グラフ、本日 / 7日 / 30日 / 全期間、レシート再印刷と共有可能なレシートのテキスト——税額票(タックスインボイス)は発行できません——発行できるのは VAT 登録事業者だけで、どの店の登録もこのシステムはまだ記録していないからです。サービス業では、売れ筋の一覧は「実際に儲かっている施術はどれか」として読めます。たいていポスターに出ているものではありません。
顧客台帳は販売台帳からメモとタグ、購入履歴、そして店舗が自店の通貨で自由に設定できるレートで貯まるポイントを、設定できる最低購入額と特典に対して組み上げます。人事はスタッフの側を扱います。GPS と備考つきの出退勤打刻、休暇申請、時給か月給での実労働分と1日8時間超の残業を含むシフトと給与、お知らせ、割り当て可能なタスク。給与は見える範囲が分かれていて、一般のメンバーは自分の分だけ、オーナーとマネージャーは全員分を見ます。
アクセスは権限マトリクスで動きます。13のコア権限に、インストールしたモジュールが宣言するぶん。オーナー・マネージャー・ホール・キッチン・スタッフの役割プリセット。そして個人ごとの上書き。権限のないメンバーにはタイルが消え、まだ何も権限のないメンバーには、バグに見える空のリストではなく、まさにそう書かれた画面が出ます。Android アプリではこの判定はクライアント側で走ります。同じマトリクスは has_capability(business_id, capability) としてデータベースにも存在し、行レベルセキュリティのポリシーのためにサーバー側で展開されます。
その下のモジュールの仕組みと、追加できる拡張
サービスは、飲食・宿泊・物販と並ぶ4つのコアモジュールの一つです——業種そのものがモジュールです。モジュールは id、担当する業種、ラベル、カタログの見出し、主要な行動ボタン、カタログ画面を宣言し、任意で権限、コンソールのタイル、コンソール画面、そして客に見えるページのセクションを宣言します。この契約があるから、インストールされたモジュールが宣言する権限から、権限エディタを自動で組み立てられます。
その上に、どの業種でも使える7つの追加インストール可能なアドオンが載ります。コンソールのプラグインストアから入れます。チーム権限、支払いチャネル、会員・サブスクリプション、更新リマインダー、プロジェクトとタスク、資材と生産、オートメーション。会員と更新リマインダーはサービス業と明らかに相性がよく、店のページから客が買えるプランと、失効前のリマインダーになります。アンインストールは「データは削除されません」と明記した確認の裏にあり、外したアドオンはタイルも権限も客向けセクションも一切提供しなくなります。サードパーティのプラグインはまだ開放していません。ストア自身がそう書いています。今日あるのは自社製アドオンによるモジュール型の構造で、外部からの提出を開くのが次の段階です。
施術のあとのレビュー
サービスの利用は、レビュー資格のビューにある確認済みの取引の一つです。だから実際に来た客はレビューを書けて、それ以外の人には、なぜボタンがないのかを説明する鍵のカードが出ます。星の評価はデータベースのトリガーがレビューの行から再計算するもので、誰かが入力するものではありません。レビューには写真、5から1の分布のまとめ、最新のレビューの編集と削除、再来店時に古いものを残したまま新しく書けること、そして公開されるオーナー返信があります。
その日に来店して時間を決めないお客さまには順番待ちのほうが向いています。QRで整理券を取り、いま何番目かが見えるので、先に時間帯を選ぶ必要がありません。
割り当てられた担当者が今日出勤しているか、休暇を取っているかはマイ職場の同じシフト表から来ます。この裏側を初めて開くなら店舗のかたへからです。