CASE STUDY ・ 美容業界 ・ サロン予約を設計するとき、空き枠の責任範囲を決める｜SalonBridge開発事例（仮称）
- サロン予約
- 予約管理
- マッチング
- Stripe
- React
- NestJS
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
匿名化した美容サロン事業者の、予約業務基盤。
本事例は、AMELAの移行記録と匿名化した開発ストーリーをもとに構成しています。プロジェクト名と顧客名は機密保持のため匿名化しており、実在の顧客名やロゴの公開を前提にしていません。
利用者がサロンを探し、サロンが予約枠を管理し、運営本部が予約と決済を追跡するための業務基盤として、検索・予約・管理の範囲を整理しました。
空き枠を公開する前に、三者の責任を分ける。
検索機能とカレンダーを用意するだけでは運用は決まりません。空き枠の更新、予約の確定、決済状態、キャンセルの扱いを、利用者、サロン、運営本部の責任として分けます。
- 利用者
条件に合うサロンと空き枠を比較できるか。
- サロン
どの枠を予約可能にするか管理できるか。
- 運営本部
予約、決済、ペイアウトを追跡できるか。
- 状態変更
キャンセルや時間変更の正本を確認できるか。
サロン予約を検索・予約・管理で構成。
SalonBridgeは、匿名化した美容サロン事業者と共に、検索・マッチング、予約・決済、会員・サロン管理の3領域を構築しました。開発ストーリーに記載された構築期間は7か月、総工数は42人月です。これは開発範囲を把握するための記録であり、予約数や事業成果の測定値ではありません。
技術スタックはReact、NestJS、MySQL、Stripe、AWS Lambdaです。決済プロバイダーの責任範囲、返金・チャージバック、個人情報の保存期間は、契約と法務の確認を経て定義します。サーバーレス構成を採用していること自体が、ピーク時の事業成果を保証するわけではありません。
- 領域 01検索・マッチング課題
地域・メニュー・日時で候補を比較する必要。
解決策条件検索と空き枠表示で予約可能なサロンを確認。
- 領域 02予約・決済課題
30分単位の枠を選び、予約と決済を進める必要。
解決策時間枠、メニュー確認、Stripe決済を一つの導線で扱う。
- 領域 03会員・サロン管理課題
予約・稼働・入金を分断させず確認する必要。
解決策サロン、会員、予約、レポートを管理画面で確認。
導入判断に使える、予約状態の設計上の価値。
本事例で確認できるのは、利用者が条件を指定して空き枠を選び、予約と決済に進む導線を、サロンと運営本部の管理画面につないだことです。予約完了率、稼働率、処理工数、売上などの業務成果は本公開範囲で測定・掲載していません。
この事例の根拠と読み方
根拠は、AMELAの移行記録、匿名化したSalonBridgeの開発ストーリー、サロン検索・予約・予約一覧の動作デモです。対象期間は新規構築期間であり、稼働後の予約数や売上を示す期間ではありません。
開発期間と工数は移行元の開発ストーリーに記載された値です。決済の安全性や事業成果の保証値ではなく、成果を判断する場合は自社の対象店舗・期間・分母・キャンセル条件を別途定義してください。
読者が使える実践ツール
| 判断項目 | 記入例 | 自社で追加確認すること |
|---|---|---|
| 空き枠 | 地域・メニュー・日時から空き枠を検索できる | 受付締切、重複予約、臨時休業、枠の更新責任者 |
| 予約確定 | 30分単位の枠を選び、メニューを確認して予約する | 仮押さえ、変更、キャンセル、返金の状態遷移 |
| 決済・記録 | Stripe決済と予約情報を一つの導線で扱う | 決済失敗、チャージバック、売上計上、ペイアウトの照合 |
- Stakeholder利用者サロンを探す人一般的に
条件に合う空き枠を比較しにくい。
本プロジェクトでは条件検索と空き枠表示を一つの導線に配置。
事業インパクト探索条件をそろえる予約完了率は未測定 - Stakeholderサロン店舗・担当者一般的に
予約可能枠の更新と変更対応が分かれやすい。
本プロジェクトでは予約と稼働を管理画面で確認。
事業インパクト枠の責任を確認できる稼働率は未測定 - Stakeholder運営本部予約・決済管理一般的に
予約と入金の対応を別々に確認しやすい。
本プロジェクトでは会員・サロン・予約・レポートを統合。
事業インパクト照合単位をそろえる工数削減は未測定
