フロントが「清掃済み」と思っている部屋を、清掃チームはまだ仕上げていない

フロントスタッフがPMSの画面を見て、「805号室、Clean になってますね。ご案内できます」とゲストに伝えた。しかし清掃チームに確認すると、「805はまだインスペクション前です」。ゲストを案内した部屋のバスルームにはまだ使用済みタオルが残っていた。

この種の食い違いは珍しくありません。フロントと清掃が「同じステータス」を見ているつもりで、実は別の情報を見ているのです。原因は「清掃済み」という言葉の定義が、フロントと清掃で異なることにあります。

同じ言葉、違う意味── 「Clean」が指すもの

フロント: 「805号室、PMSでCleanになっています」

清掃リーダー: 「いえ、清掃は終わりましたが、まだチェックしていません」

フロント: 「えっ、Cleanって清掃完了じゃないんですか」

清掃リーダー: 「清掃完了とインスペクション完了は別です。チェックが終わっていない部屋はまだ出せません」

フロント: 「……じゃあ805号室はいつ入れるんですか」

清掃リーダー: 「今からチェックするので、15分くらいかかります」

フロントにとって「Clean」は「ゲストを案内できる状態」を意味しています。清掃チームにとって「Clean」は「清掃作業が完了した状態」であり、リーダーのインスペクション前のステージです。同じ「Clean」という単語が、部門によって異なる状態を指している。これがステータスの食い違いの根本です。

食い違いが起きる構造的な理由

理由1：ステータスの段階数が足りない

多くのPMSは、客室の清掃状態を「Dirty（未清掃）」と「Clean（清掃済み）」の2段階で管理しています。しかし現場では、「清掃中」「清掃完了・検査前」「検査完了・販売可能」という中間ステージが存在します。2段階のステータスでは、この中間を表現できません。清掃スタッフが「清掃完了」を報告した時点でPMS上はCleanに変わりますが、フロントから見ると「もう入れる」と解釈してしまうのです。

理由2：更新のタイミングが合っていない

清掃スタッフが清掃を完了し、リーダーに報告する。リーダーがインスペクションに向かう。インスペクションを終え、OKを出す。リーダーがPMSのステータスを更新する。この一連の流れの中で、PMSのステータスが更新されるのは最後のステップです。つまり、清掃完了からステータス更新まで、10分から30分のタイムラグがあります。

フロントがPMSを見るタイミングがこのタイムラグの間に当たると、実態と画面が合いません。「Dirty表示だけど本当はもう入れる部屋」と「Clean表示だけど実はまだ入れない部屋」が混在する状態です。

理由3：例外が反映されていない

PMSのステータスは定型のフローを前提に設計されています。しかし現場では、例外が日常的に発生します。清掃完了後に設備故障が見つかった、インスペクションで手直しが必要になった、ゲストの要望でアメニティの追加が必要になった。こうした例外が発生しても、PMSのステータスが自動的に「差し戻し」されないため、画面上は「Clean」のまま実態は「対応中」になります。

2段階
多くのPMSのステータス設計
10〜30分
清掃完了〜ステータス更新のラグ
5〜10件/日
ステータスに反映されない例外

食い違いが引き起こすこと

ステータスの食い違いは「小さなミス」に見えますが、連鎖的に問題を引き起こします。

ステータスの食い違いで最も危険なのは、フロントがシステムを信じなくなることです。一度信頼が崩れると、正確な情報がPMSに入っていても電話確認をやめなくなります。情報基盤そのものへの信頼が損なわれるのです。

統合の考え方── 「同じものを見る」状態を作る

食い違いを解消するためには、フロントと清掃が「同じ情報源」を「同じ定義」で見ている状態を作る必要があります。

ステップ1：ステータスの定義を統一する

まず、「Clean」「Ready」「Dirty」がそれぞれ何を意味するのか、フロントと清掃で合意します。2段階（Dirty/Clean）では現場の実態を表現できないため、少なくとも4段階（Dirty → Clean → Inspected → Ready）に分けることを検討します。「Clean」は清掃完了だがまだ売れない、「Ready」はゲストに案内できる、という区分が明確になれば、フロントが「Clean」の部屋に案内してしまうミスは防げます。

ステップ2：更新のタイミングをリアルタイムにする

ステータスの更新が遅れるのは、更新作業が別のタスク（リーダーがPCでPMSを操作する）になっているからです。清掃スタッフが作業完了と同時にスマートフォンからステータスを更新し、リーダーがインスペクション完了と同時にステータスを更新する仕組みがあれば、タイムラグはほぼゼロになります。

ステップ3：例外をステータスに反映できるようにする

設備故障やアメニティ追加要請などの例外が発生したとき、ステータスを「対応中」に差し戻す仕組みが必要です。手動で差し戻すルールを決めるだけでは漏れが出るため、故障報告や追加作業の起票と連動してステータスが自動的に変わる設計が望ましいです。

フロントと清掃、同じステータスを見ていますか

リアルタイムのステータス同期で、食い違いをなくします

資料を請求する

「違うものを見ている」ことに気づけるか

厄介なのは、食い違いが起きていることに両部門とも気づいていない場合があることです。フロントはPMSの画面を正しいと思っている。清掃チームは自分たちの管理表を正しいと思っている。互いに「自分の情報が正しい」と信じているから、食い違いの原因を探ろうとしません。

確認する方法はシンプルです。ある時点でPMSに表示されている各部屋のステータスと、清掃リーダーが把握している各部屋の実態を突き合わせてみてください。10部屋中2〜3部屋で食い違いがあれば、それは個別のミスではなく構造の問題です。

フロントと清掃が「違うもの」を見ている状態では、どれだけ個人が注意しても食い違いは繰り返されます。問題の根本は人のミスではなく、情報の構造にあります。同じ情報を、同じ定義で、リアルタイムに共有する仕組みがあるかどうか。それが、ステータスの食い違いを解消する唯一の方法です。