#1で作った予約Botは、お客様側の体験を完成させた。 でも、予約が入った後のサロン側の動きが抜けていた。
サロンはどこで予約を確認するのか。確定はどうする。スタッフが急病になったら。 キャンセルしたいお客様からメッセージが来たら。 Bot だけでは答えられない問いが残っていた。
— 管理画面（左）で確定ボタンを押すと、お客様のLINE（右）に即座に通知が届く。
管理画面でできること
Botから届いた予約を一覧で確認。確定ボタンを押すとお客様のLINEへ即通知。
予約済みのお客様に、管理画面から直接LINEメッセージを送れる。
お客様からの自由なメッセージをチャット形式で受け取り、返信できる。
スタッフが当日欠勤した場合、影響する予約を一覧表示して担当を振り替えられる。
月次・日次の売上をグラフで確認。メニューごとの件数も集計される。
お盆や年末など休む日を登録すると、Botが自動でその日を候補から外す。
「即確定」をやめた理由
最初の設計では、お客様が予約を入れたら自動で「確定」にする予定だった。でも実際に使うことを想像したとき、それだと困る場面が見えてきた。
スタッフが急病で来られなくなったとき。その日の予約がすでに満杯なときに、何かの間違いで入ってしまったとき。お客様の希望をよく確認してから返事したいとき。
「人が確認してから確定する」という一歩を挟むことで、トラブルを未然に防げる。自動化はするが、最後の判断はサロン側に残す。そのバランスを「仮受付」という仕組みで実現した。
お客様がLINEで予約を入れる。
サロン側の管理画面に「仮受付」として届く。内容を確認して、確定ボタンを押す。
その瞬間、お客様のLINEに「ご予約が確定しました」と通知が届く。
お客様からのメッセージを受け取る
予約以外の問い合わせ——「カラーについて相談したい」「前回と同じデザインにできますか」——をどう受け取るかが課題だった。
解決策は受信ボックス機能だ。予約フローに当てはまらないメッセージが来たとき、Botは「スタッフが確認次第ご連絡します」と返しながら、そのメッセージを管理画面の受信ボックスに届ける。
管理画面にはLINEのようなチャット画面があり、お客様のメッセージを読んで返信できる。返信はお客様のLINEに直接届く。Bot経由ではなく、本当の意味での「直接やりとり」だ。
セキュリティをどう考えたか
管理画面はお客様の名前・予約情報・LINEとのやりとりを扱う。個人情報が含まれるページだ。作り始めの段階から、セキュリティをちゃんと考えておく必要があった。
最初の実装では「?token=xxxx」とURLにパスワードを含めていた。ブラウザの履歴やサーバーのログに残るため、URLに秘密を載せない形へ切り替えた。本番でお客様情報を扱う場合は、独自ログインではなくCloudflare Accessなどの認証基盤で管理画面を保護する前提にする。
一度ログインしたら永遠に入れる状態は危険だ。5日間でログアウトされるようにした。万が一デバイスをなくしても、被害が限定される。
誰がいつどのお客様にどんなメッセージを送ったか、データベースに記録が残る。「送ったっけ？」「何を送った？」を後から確認できる。
同じDB、別の画面という設計
管理画面は、Botとまったく同じデータベースを使っている。お客様がLINEで予約を入れると、同じデータベースにデータが書き込まれ、管理画面にはそれが即座に反映される。
別々のサービスが同じデータを見ている——これが「リアルタイムで同期されている」ように見える理由だ。実際には管理画面が「5秒ごとにデータベースに問い合わせている」だけで、魔法ではない。シンプルな仕組みが、使いやすい体験を作っている。
サーバーレス構成なので、管理画面の維持コストもほぼゼロ。月に何百万件アクセスがあっても、数千円で収まる設計だ（架空のサロンなので実際にはかからないが）。
次に作るとしたら
今回の管理画面で基本的な機能は揃った。実際のサロンで使うとしたら、次に必要になりそうなのはこのあたりだと思う。
複数スタッフのシフト管理。顧客カルテ（過去のメニュー履歴・アレルギー情報）。定期的に来るリピーターへの一斉通知。支払い記録との連携。
どれも今の構成に積み上げていける。Bot・管理画面・データベースという基盤が整っているので、機能追加は比較的素直にできる。