複数のホテルや旅館を運営すると、問い合わせ窓口をまとめることで、応援や承認をしやすくなります。一方、全員にすべての施設を見せる設計では、別施設の予約を開く、違う屋号の送信元から返信する、担当外の情報を変更するといった事故につながります。
一つの画面で管理は、情報を無条件に一か所へ集めることではありません。必要な人が、必要な施設で、許された操作だけを行えるようにすることです。
「施設の範囲」と「役割」を分けて考える
権限には二つの軸があります。一つは、どの施設の情報を見られるかという施設範囲。もう一つは、閲覧、担当、返信作成、承認、設定変更など、何をできるかという役割です。管理者だから全施設、担当者だから一施設と固定せず、業務に合わせて組み合わせます。
たとえば本部の承認者は複数施設を確認し、現地スタッフは所属施設だけを扱う、といった設計が考えられます。
送信元と施設ルールを取り違えない
複数施設で似た問い合わせを扱っていても、名称、連絡先、チェックイン時刻、設備、案内方法は異なります。返信画面では、対象施設、確定予約、使用する施設ルール、送信元を同時に確認できるようにします。
おもてなしメーラーは、複数施設の受信箱と施設別アクセス制御、送信元選択、承認を扱う設計です。ただし、公開時には実際の契約、接続済みメール、利用者の役割が正しく設定されているか個別に確認する必要があります。
異動・退職・応援時の変更手順を決める
権限は最初に設定して終わりではありません。新しいスタッフの招待、施設間の応援、役割変更、退職時の停止を、誰がいつ行うか決めます。不要になったアクセスを残さず、担当中の案件や承認待ちを別の人へ引き継ぎます。
メール承認の流れと組み合わせ、誰が作成でき、誰が承認できるかを施設ごとに確認すると、運用の境界がはっきりになります。
権限は定期的に洗い出す
名簿とシステム上の利用者を照らし合わせます。所属施設、役割、最終利用状況、担当中案件を確認します。繁忙期だけ付けた応援権限や、役割変更前の権限が残っていないかも見直します。洗い出しの実施者と記録先を決めると、設定変更を個人の記憶に頼らず継続できます。
権限を追加するときは「念のため全施設」ではなく、担当期間と対象業務をはっきり書きます。期限付きの応援であれば終了日に見直しを予定し、解除時には未完了案件を先に移します。アクセス停止と引き継ぎを一つの手順として扱うことが重要です。
現場で確認してみましょう
- 利用者ごとに閲覧できる施設が業務範囲と一致しているか
- 閲覧、返信作成、承認、設定変更を分けているか
- 対象施設と送信元を送信前に確認できるか
- 施設固有のルールを別施設へ誤用しないか
- 異動・退職時の停止と案件引き継ぎ手順があるか
一つの画面で管理と全件公開は同じではない
複数施設の問い合わせを一つの画面に集めると、応援対応や本部監督がしやすくなります。一方で、施設をまたいだ顧客情報の閲覧、誤った送信元、別施設ルールの混用という新しいリスクが生まれます。一覧の見やすさは保ちながら、本文閲覧、返信、設定、データの書き出しを役割と施設で分ける必要があります。
本部スタッフは全施設の未対応件数を見たい一方、各施設スタッフは自施設の本文だけで足りるかもしれません。件数・期限の集計と、個別メール本文の閲覧権限を分ければ、全体最適と必要最小限のアクセスを両立できます。
迷わないための考え方
施設権限と役割権限を掛け合わせる
施設Aの返信担当、施設Bの閲覧のみ、本部の集計閲覧など、施設範囲と操作範囲を別軸で設計します。役職名だけで広い権限を与えません。
閲覧と操作を分ける
一覧件数を見る、本文を開く、返信案を作る、送信する、施設情報を変更する、データを出力する権限は別です。事故時の影響が大きい操作ほど限定します。
送信元施設を固定確認する
別施設の署名、住所、電話番号、ルールで返信しないよう、案件の施設と送信元を連動させます。施設を切り替えた場合ははっきりに表示し、送信前に再確認します。
応援対応の期限を決める
繁忙期の応援や一時的な兼務に期限のない権限を与えません。開始日、終了日、承認者を設定し、期限後に自動または定期的な見直しで解除します。
複数施設の権限を設計する手順
- 職務と必要情報を洗い出す本部、施設責任者、予約、フロント、料飲、外部委託など、実際の職務ごとに必要な施設・情報・操作を書き出します。人名からではなく役割から設計します。
- 最小権限の役割を作る最初は必要最小限で付与し、不足が業務で確認されたら追加します。便利だから全施設管理者にする運用を避けます。
- テストアカウントで境界を確認する施設A担当が施設Bの本文、検索結果、通知、添付、顧客カルテを見られないことを実際の画面で確認します。URL直接アクセスも試します。
- 送信と設定変更を二重確認する施設横断の担当者が返信するときは施設名と送信元を目立たせ、設定・連携変更は管理者だけに限定して操作履歴を残します。
- 異動・退職・応援終了で見直す人事イベントと権限削除を同じ手順へ組み込みます。長期間使われていないアカウントと過剰権限を定期的に確認します。
施設横断で必要な三つの視点
施設スタッフ
自施設の担当案件と必要な顧客情報だけを扱い、別施設への応援ははっきり表示的な期間付き権限で行います。施設切替時に送信元、署名、ルールを再確認します。
本部・統括担当
未対応件数、期限、品質指標は横断で見ても、個別本文は支援・監査など目的があるときだけ開きます。集計閲覧と本文閲覧を同じ権限にしません。
権限管理者
施設、役割、操作、期間を組み合わせ、申請・承認・付与・削除を記録します。異動、退職、応援終了で即時見直し、直接URLや出力の境界も検証します。
複数施設の権限を説明できる記録
「管理者」「社員」だけでは広すぎます。誰が、どの施設で、何を見る・送る・変更する必要があり、いつまで有効かを明文化します。例外権限には理由と終了日を付けます。
- 施設Aフロント：自施設の本文閲覧、返信、担当変更。全件CSV出力と連携設定は不可。
- 施設B応援：9月1日から7日まで返信作成可、送信は施設B責任者の承認が必要。
- 本部：全施設の未対応件数と期限を閲覧。個別本文は監査案件として理由入力後に閲覧。
- システム管理：連携設定と権限変更が可能。顧客対応の代理送信は通常権限に含めない。
- 退職者：最終勤務終了時にアカウント、セッション、APIトークンを停止し、共有秘密を変更する。
一か月で施設横断権限を整える
- 第1週全利用者、所属、担当施設、実際の操作、外部委託、一時応援を一覧化し、管理者権限の理由を確認します。
- 第2週施設範囲と閲覧・返信・送信・設定・出力を分けた標準役割を作り、例外へ期限を付けます。
- 第3週テストアカウントで、画面、検索、通知、添付、直接URL、出力、APIの施設境界を実機確認します。
- 第4週過剰権限、施設誤選択、権限変更ログを確認し、人事イベントと即時停止手順をつなぎます。
責任者が見ておきたいこと
本部の利便性を理由に、全施設の顧客本文を常時公開しません。責任者は、集計で足りる目的と個別閲覧が必要な目的を分け、応援権限には終了日を設けます。施設誤送信が起きた場合は個人注意だけでなく、選択中施設と送信元の表示を改善します。
よくある失敗と防ぎ方
- 本部だから全本文を常時閲覧可能にする。集計閲覧と個別案件閲覧を分け、必要時の承認の流れを作ります。
- 施設を切り替えても署名やルールが前施設のまま残る。案件施設と送信設定を強く連動させます。
- 応援終了後も権限が残る。期限付き付与と定期洗い出しを行います。
- 画面だけ隠し、検索や直接URLで別施設データへ到達できる。サーバー側のアクセス権限の確認を実機で検証します。
改善できたかを数字で確かめる
システムを入れただけで終わらせず、現場の仕事がどう変わったかを定期的に確認します。
- 過剰権限アカウント数
- 現在の職務より広い施設・操作権限を持つアカウントを定期確認し、理由のない権限を削除します。
- 施設誤選択・誤送信件数
- 別施設の署名やルールを使った事例を追い、施設表示と送信前確認を改善します。
- 権限変更の未記録件数
- 付与・変更・削除の申請者、承認者、日時が残っているかを監査し、口頭依頼だけの変更をなくします。
よくある質問
本部は全施設のメール本文を見られるべきですか？
業務目的によります。未対応件数や期限の集計だけで足りる場合、本文閲覧は不要です。個別支援や監査に必要なときだけ、役割と手続きに基づいてアクセスできる設計が適切です。
一人が複数施設を担当する場合、毎回ログインし直しますか？
必ずしも必要ありません。単一アカウントに施設別権限を持たせ、現在選択中の施設をはっきりに表示できます。ただし施設切替時の送信元、署名、ルール、検索範囲を確実に分離します。
外部のコールセンターへどこまで見せますか？
委託業務に必要な施設、期間、項目、操作だけに限定します。契約、秘密保持、再委託、ログ、データ持ち出し、終了時削除を確認し、設定変更や一括出力など不要な権限は与えません。
まとめ
複数施設の問い合わせを一つの画面で管理するには、全情報を全員へ開くのではなく、施設範囲と役割を組み合わせます。さらに、予約、施設ルール、送信元を同じ施設の背景や流れで確認し、異動や退職時には速やかに更新します。共有と分離を同時に設計することが、多施設運営の安全性と応援しやすさを支えます。関連する記事はおもてなしOSジャーナルでご覧いただけます。
