キャスト管理では、登録画面の使いやすさだけでなく、公式サイトのどこへ表示され、予約枠とどう整合し、退店時に何が残るかを決めます。運用中に例外が起きる前提で設計することが重要です。
入店・公開・出勤・受付・退店を分ける
01
登録
管理用情報と公開用情報を分ける。
02
公開
確認後に一覧・詳細へ反映する。
03
出勤
日時と受付可能枠を更新する。
04
終了
非公開、予約停止、URL処理を行う。
管理項目を用途別に分ける
表示名、プロフィール、写真、対応コース、公開コメント、SNS、出勤などの公開項目と、店舗内だけで使う連絡・契約・管理項目を分けます。API連携では公開可能な項目だけを渡し、管理情報が意図せず出ない設計にします。
出勤時間と予約可能時間は同じとは限らない
出勤していても移動、準備、休憩、既存予約により受付できない時間があります。「出勤中」と「予約可能」を別状態として扱い、利用者へ誤解のない表現を決めます。WEB予約の確定方法はWEB予約の導入設計と一緒に決めます。
一元管理の確認点公式サイトの出勤表だけ同期しても、予約台帳やポータルが別更新なら転記は残ります。どこまで同期し、どこから人が確認するかを明確にします。
公開範囲と権限を最小化する
入力担当、公開承認、予約閲覧、料金変更など、役割ごとに権限を分けます。写真・プロフィールの公開同意、SNSリンクの扱い、キャッシュや外部連携先に残る期間も運用ルールに含めます。
退店時は削除だけで終わらせない
一覧・出勤・予約から外し、詳細URLは検索流入と代替ページを見て、非公開、410、関連一覧への転送などを判断します。別人へURLを使い回すと内容と評価が混ざるため避けます。
NEXUS LUNAを情報源にするキャスト・出勤・料金の元データを整理し、公式サイトや予約へ反映する範囲を店舗ごとに設計します。
よくある質問
出勤表と予約枠は自動で一致しますか？
連携仕様によります。出勤、既存予約、準備時間などから受付可能枠をどう作るかを個別に決めます。
退店したキャストページは削除すべきですか？
検索流入、代替情報、プライバシーを確認して処理します。新しいキャストへ同じURLを流用することは避けます。