FCオーナー・本部ログイン
登録済みアカウントでログインすると、担当店舗のデータが表示されます。
未ログイン
本部はFC3店舗、オーナーは自分の担当店舗を表示します。
FC

FC デイリー売上ダッシュボード

8月実績 · 日別表示
FC集計 · FCオーナー・本部用 データ取込済み
全社 売上累計
—
—
目標との差分
—
—
着地見込み
—
—
月間集客数
—
—
全社稼働率
—
30分枠ベース
営業利益概算(全社)
—
売上 − 月間販管費
選択日〜月末 予約数(実売上取得済み日のみ除外)
—
SALON BOARDスケジュール基準
選択日〜月末 推測売上(税抜)
—
予約数 × 目標客単価
日次売上(全社)
実績・日別
15101520—
累計 vs 目標ペース
月間目標との進捗比較
デイリー売上差分
月間目標を日数で割ったデイリー目安と実績の差分
日次集客(新規 / 既存・全社)
月間集客
15101520—
店舗別 新規 / 既存割合(当月)
当月累計 · 新規比率の高い順
新規既存
新規比率の推移(月次・全社)
新規 ÷(新規+既存)
店舗別サマリー(当月累計)
売上累計順で店舗比較 · 目標差・達成率・新規/既存・客単価・稼働率・営業利益を一覧
店舗売上累計 ↓目標との差分達成率集客客単価稼働率営業利益
店舗別 日次売上トレンド
月次売上 vs 目標
過去12ヶ月 · 全社実績 / 月次目標
売上目標
月次サマリー
1期:9月〜翌年8月
月売上目標との差分達成率集客客単価稼働率営業利益
当日売上
-
-
当日までの目標進捗
-
-
集客数
-
-
客単価(税抜)
-
-
選択日〜月末 予約数(実売上取得済み日のみ除外)
-
SALON BOARDスケジュール基準
選択日〜月末 推測売上(税抜)
-
sales_synced_at未取得日は予約数を推測売上に含める
売上目標との比較
-
-
客単価目標との比較
-
-
新規目標との比較
-
試作では目標未設定
空枠率目標との比較
-
警戒ライン 50%
月別目標の設定
店舗ごと・月ごとに目標数値を変更できます
売上目標・客単価目標は税抜金額で入力してください。保存した目標は日別・月別・年間推移の比較に反映します。
新規 / 再来の手動修正
SALON BOARDの判定が実態と異なる場合だけ修正できます
修正値は選択中の店舗・日付だけに適用し、月間累計・推移グラフにも自動反映します。
次回予約数の手動入力
新規・再来それぞれ、その場で次回予約が取れた人数を入力します
スタッフ報告ベースで新規・再来を分けて保存し、月間の新規次回予約率・再来次回予約率・全体次回予約率に自動反映します。
全店舗の進捗
選択日までの月間累計と日別売上推移
月間目標達成率-
新規
-
既存
-
空枠率
-
空枠数(30分枠)
-
総予約可能枠(30分枠)
-
予約済み枠(30分枠)
-
8/18/58/108/158/19
今日から7日間の店舗別空枠
Todayを基準に7日間の空枠を店舗別に確認できます
経営アラート
優先的に確認したい指標
店舗毎営業利益概算
-
店舗別スコアカード
店舗名を押すと、その店舗の詳細に切り替わります
店舗売上目標達成率集客客単価空枠率営業利益概算状態
店舗推移グラフ
選択店舗の推移をグラフで確認できます
売上推移
月初月中月末
客単価・集客推移
月初月中月末
月初→現在 売上変化
-
平均日商
-
客単価トレンド
-
SALON BOARD連携
店舗ごとの連携状況と自動集計ステータス
連携店舗
-
最終取得
未取得
取得状態
未取得
過去データ一括取込
開始日〜終了日を指定し、選択店舗または全店舗のSALON BOARD実績を日ごとに順番に取り込みます
既存の日付はupsertで最新値に更新します。手動補正・次回予約・月別目標は上書きしません。
店舗管理
本部管理用です。新店舗を登録すると、店舗選択・目標設定・分析・推移へ自動反映します
本番運用ステータス
実運用に必要な接続状況を確認します。Supabase接続後はデータを永続保存し、画面更新後もログイン状態を維持します。
FCオーナー・本部ログイン
Supabase Authを使い、本部メンバーだけがメールアドレス+パスワードでログインできる構成にします。
Supabase採用
DB永続保存
Supabase PostgreSQLへ、店舗・月別目標・日次入力・新規/再来補正・次回予約数・同期履歴を保存します。
Supabase採用
SALON BOARD自動取得
日別売上集計と予約スケジュールを定期取得し、出勤スタッフの30分枠だけで空枠率を自動計算します。
同期サーバー接続待ち
本番接続チェック
実運用開始前に、下記3点をサーバー側で接続します
認証
Supabase Auth
本部アカウントのみログイン可能にする
データベース
Supabase PostgreSQL
自動取得値と本部入力値を別テーブルで保持
自動同期
未接続
店舗別に定期取得し失敗時は再実行
SALON BOARD同期サーバー
Cloudflare Workersを同一ドメインの同期APIとして利用し、店舗ごとのSALON BOARD取得 → Supabase保存まで自動化します
同期API
未接続
日別売上集計を取得
予約スケジュール
未接続
出勤者のみ30分単位で空枠計算
自動実行
未接続
定期同期+失敗時再試行
※ API URLやTokenの手入力は不要です。SALON BOARDのID・パスワードやSupabase Service Role KeyはWorkers Secretsで管理します。
同期サーバー本番仕様
SALON BOARD取得からSupabase保存までの処理を、この構成で固定します
1. 認証
店舗ごとに安全に保持
SALON BOARDのログイン情報はサーバー側Secretで管理し、ブラウザへ返しません。
2. 売上取得
日別売上集計
純売上・施術・店販・オプション・客数・新規・再来・客単価・指名を取得します。
3. 予約取得
予約スケジュール
出勤スタッフだけを対象に、30分=1枠で総枠・予約済み枠・空枠を算出します。
4. DB保存
Supabaseへupsert
daily_metricsは再同期で更新し、daily_overridesやstaff_dailyは上書きしません。
5. 同期履歴
sync_runsへ保存
開始時刻・終了時刻・成否・エラー内容を店舗単位で残します。
6. 定期実行
日次+手動再取得
毎日の自動同期と、「今すぐ自動集計」からの手動同期の両方に対応します。
Cloudflare公開設定
本番公開はCloudflare Pages + Workersを前提にします。画面はPages、SALON BOARD同期APIはWorkers、定期同期はCron Triggersで分離します。
フロントエンド
Cloudflare Pages
本部ダッシュボードをHTTPSで公開します。
同期API
Cloudflare Workers
SALON BOARD取得・Supabase保存・手動再同期APIを実行します。
定期実行
Cron Triggers
毎日の自動同期と失敗時の再試行をWorkersから行います。
ブラウザ接続設定
SupabaseのURLと公開キーはconfig.jsで設定します。担当店舗の閲覧範囲はRLSで制限します。
自動設定
サーバーSecret
Supabase Service Role Key、SALON BOARD認証情報はWorkers Secretsに保存します。
Secrets管理
公開ドメイン
初期はpages.devで公開し、運用確認後に独自ドメインへ切り替えられます。
公開準備
本番実装チェックリスト
Cloudflareへ公開して実運用へ移るための残タスクを、実装単位で整理しています
Pagesこのダッシュボードを静的配信。Supabase URL / Anon Keyはビルド時環境変数から注入します。
Workers API/api/health と /api/sync を実装し、SALON BOARD取得とSupabase保存をサーバー側で行います。
Cron Triggers毎日の自動同期をWorkersから実行し、失敗時はsync_runsへ記録して再試行します。
必要なCloudflare環境変数 / Secrets SUPABASE_URL SUPABASE_ANON_KEY SUPABASE_SERVICE_ROLE_KEY (Secret) SALON_BOARD_* 認証情報 (Secret) Workers API GET /api/health POST /api/sync フロント側では pages/config.jsにFC専用SupabaseのURLと公開キーを設定します。
Cloudflare Workers 実装ひな型
/api/health・/api/sync・Cron・Supabase保存までを1つのWorkerで実装する本番ベースです
FCオーナー対応版の設定は、同梱README.mdとsql/01_bootstrap.sqlを参照してください。
FCオーナー対応版の設定は、同梱README.mdとsql/01_bootstrap.sqlを参照してください。
ログインアダプター
SALON BOARDの認証リクエスト、Cookie、CSRFトークン、追加認証の有無を確認してWorker側へ実装します。
仕様確認待ち
売上取得アダプター
日別売上集計画面または内部通信から、純売上・客数・新規・再来・客単価・指名などを取得します。
仕様確認待ち
予約取得アダプター
予約管理スケジュールから出勤スタッフと予約時間帯を取得し、30分=1枠で空枠数・空枠率を算出します。
仕様確認待ち
SALON BOARD実装確認
本番同期に必要な3箇所の仕様を確認するため、ログイン後のブラウザ開発者ツールで下記を確認します
ログイン
Network → Doc / Fetch
送信先URL、POST項目名、Cookie、CSRFトークン、追加認証の有無を確認します。
日別売上集計
Network → Fetch/XHR
期間・店舗・スタッフ変更時に動くリクエストを確認し、レスポンス内の売上・客数・新規・再来項目を特定します。
予約スケジュール
Network → Fetch/XHR
日付変更時の通信から、スタッフ名・勤務時間・予約開始/終了・休憩/ブロック時間を特定します。
次に必要な確認データ
SALON BOARDの画面を開いた状態で、Chrome DevToolsのNetworkから下記3操作をHARで保存すると、Workers側の実装へそのまま落とし込めます
1. ログイン
ログイン操作のHAR
ID・パスワードそのものは共有不要です。送信先、項目名、CSRF、Cookie遷移を確認します。
2. 日別売上
日付変更時のHAR
日別売上集計を開き、日付を1日変更した際のXHR/Fetchを保存します。
3. 予約管理
日付変更時のHAR
予約管理で日付を1日変更し、スタッフ勤務・予約枠を返す通信を保存します。
取得仕様の登録
通信仕様が確認できたらここへ登録し、Workers実装へそのまま反映できるようにします
URLだけでなく、必要に応じてHTTPメソッド・フォーム項目名・CSRF・レスポンス形式もWorkers側へ実装します。認証情報そのものはここには保存しません。
Supabase設定
まずSupabaseを先に実装します。Auth・Database・RLSを完成させてからCloudflare連携へ進みます
実装順:Supabase → Cloudflare → SALON BOARD
① Supabaseプロジェクト作成 → ② 下記SQLを実行 → ③ FCオーナー・本部ログインユーザー作成 → ④ 接続確認、の順で進めます。Project URL・Anon Keyはログイン画面では入力しません。
※ Project URL・Anon Key・Service Role KeyはCloudflare側の環境変数/Secretsで管理し、この画面では入力しません。
Auth
未設定
本部ユーザーのみ作成
Database
未設定
6テーブルを作成
RLS
未設定
本部ユーザー以外を拒否
1. FCオーナー・本部ログインSupabase Authとfc_profilesに本部・オーナーを登録します。未ログイン時は表示しません。
2. DB初期化stores / daily_metrics / daily_overrides / monthly_goals / staff_daily / sync_runs を作成して保存先を確定します。
3. RLS保護本部はFC3店舗、各オーナーは自分の担当店舗だけを参照・入力できます。
Supabase初期SQL
FC専用の新規プロジェクトで、同梱sql/01_bootstrap.sqlを実行してください
FCオーナー対応版の設定は、同梱README.mdとsql/01_bootstrap.sqlを参照してください。
FCオーナー・本部用運用のため、fc_profilesと担当店舗を使って閲覧・編集範囲を制限します。SALON BOARDのID・パスワードはこのDBには平文保存せず、サーバー側Secretで管理します。
本番DBデータ構成
この構成で保存すれば、SALON BOARD再取得後も本部入力値を安全に維持できます
stores
店舗情報
店舗名・SALON BOARD識別子・開店日・連携状態
daily_metrics
自動取得実績
売上・総客数・新規・再来・客単価・予約枠
daily_overrides
本部補正値
新規/再来補正・次回予約数を再同期から保護
monthly_goals
月別目標
店舗×年月で売上・客単価・新規・空枠率目標を保存
staff_daily
スタッフ日次入力
スタッフ名・出勤・新規/再来・次回予約を日付別保存
sync_runs
同期履歴
開始/終了・成否・エラー内容・再取得状態を保存
DB保存ルール
SALON BOARD再同期後も、本部で修正した値を保持する前提です
自動取得データ
売上・客数・予約枠
再同期時は最新値へ更新
手動補正データ
新規 / 再来
再同期しても上書きしない
本部入力データ
次回予約・目標値
本部入力値を優先して保持
同期履歴
店舗ごとの最終取得結果を確認し、失敗時は再取得できる想定です