お客様へのメールを送信すると、受信箱では対応済みに見えます。しかし「ケーキを用意します」「到着時刻に合わせて確認します」と返した場合、施設には新しい約束と作業が生まれます。返信完了と業務完了は同じではありません。
当日担当がPMSを見る施設では、確定した内容をPMSにも残したいという要望が自然に生まれます。大切なのは全文転記ではなく、現場が判断できる記録と、実行が必要な手配を分けてつなぐことです。
PMSには「確定した結果」を短く残す
記録する候補は、問い合わせの要点、施設から回答した内容、確定した約束、提供日時、担当、期限、詳細を確認できる場所です。会話の途中経過をすべて貼り付けると、何が最新か分かりにくくなります。
「相談あり」ではなく、「誰に、いつ、何を提供するか」「まだ確認中の点は何か」が分かる表現にします。返信本文の原文はメール側で残し、PMSの要約からたどれるようにします。
作業が生まれたら記録とは別に手配を登録する
PMS備考へ書いただけでは、担当者への通知や期限管理ができないことがあります。発注、在庫確認、部署への依頼、当日提供など行動が必要なら、対象予約、手配内容、担当、期限、状態を持つ仕事として登録します。
一通のメールから複数の手配が生まれる場合もあります。大きなメモ一件にまとめず、完了条件が異なる作業は分け、同じ会話と予約に結び付けます。基本項目はホテル手配管理の基本をご覧ください。
手入力・CSV・APIはPMSの対応範囲を確認して選ぶ
PMSへの記録方法は、製品、契約、権限、提供機能によって異なります。APIでの書き込みが可能とは限らず、CSVも取込対象が限定されることがあります。未確認の連携を前提にせず、仕様と運用責任を確認します。
件数が少なく人の判断が必要なら、承認後の手入力が安全な場合もあります。自動化する場合は、予約の見分け、重複防止、上書き範囲、エラー通知、再実行を設計します。詳しくはPMS連携チェックを参照してください。
送信前承認と書き込み後確認を分ける
メールの承認は、お客様へ送る内容が正しいかを確かめる工程です。PMSへの記録確認は、正しい予約に、必要な要約と手配が残ったかを見る工程です。どちらか一方だけでは、誤送信や誤登録を防げません。
送信、記録、手配作成の操作履歴を持ち、失敗時は未完了として目立たせます。自動処理が止まっても、担当者が手作業へ切り替えられるようにします。
訂正するときは元の記録を無言で消さず、誤りと正しい内容、訂正者を追えるようにします。当日担当には最新情報をはっきりに見せ、監査用の履歴とは表示を分けます。
現場で確認してみましょう
- メール送信済みと、関連作業の完了を分けているか
- PMS要約に確定事項、担当、期限、確認先があるか
- 行動が必要な約束を手配として登録しているか
- PMSへの書き込みできるかどうかと対象項目を確認したか
- 誤予約・重複・失敗を検知し、訂正できるか
送信後に残すべきものは、返信文と未完了の仕事
メールを送った事実だけでは、次の担当者は「何を約束し、何がまだ終わっていないか」を理解できません。原文、返信、送信者、時刻、予約ひも付け、約束・手配、担当、期限、同期状態を一つの案件で確認できることが重要です。ただし、メーラー内保存とPMS本体への書き込みははっきりに分けます。
お客様へケーキの手配を案内し、メーラー内へ商品明細を登録できても、PMSやOS本体に同じ明細が存在するとは限りません。未同期のままなら、現場はメーラー内記録を確認し、決められた方法でPMSへ転記する必要があります。画面に保存先と状態を正直に表示します。
迷わないための考え方
記録先を三段階で区別する
メール案件内だけ、PMSへ転記済み、API等で同期確認済みを分けます。「登録済み」という一語で保存先を曖昧にしません。
PMSへ残す最小項目を決める
メール全文を貼るのではなく、予約番号、約束内容、数量、提供日時、担当、状態、参照先など、当日業務に必要な項目を定めます。
自動書き込みは対象を限定する
対象予約の確定、項目対応、権限、重複防止、失敗時再送、キャンセルを検証できる項目だけを候補にします。曖昧な予約へ自動更新しません。
送信と記録の原子性を考える
メール送信は成功したが記録に失敗した、または逆の状態を想定します。両方の結果を表示し、利用者が再送や手動記録を判断できるようにします。
メール送信からPMS記録までの安全な流れ
- 予約を人が確定する施設、予約番号、宿泊日、代表者を照らし合わせます。候補ではなく確定予約にします。確信できなければ問い合わせへ戻ります。
- 本文から約束と明細を抽出する返信前に、施設が実行する内容を明細化し、数量、日時、担当、料金を確認します。
- メールを承認して送信する宛先、予約条件、施設ルール、約束明細を確認し、権限を持つ人が送信します。送信IDと時刻を記録します。
- 保存先と同期結果を記録するメーラー内保存、PMS書込要求、PMS成功応答、再取得確認を段階表示します。失敗は未同期として担当へ通知します。
- 当日業務で照らし合わせるPMSまたは正式な当日一覧に明細が見えるかを確認し、提供完了後に結果を閉じます。自動連携前は標準転記チェックを使います。
送信・記録・同期を分ける担当
メール送信担当
予約を確定し、返信内の約束を明細化してから送信します。送信成功を確認し、本文、送信者、時刻、関連約束を同じ案件へ残します。
PMS・OS記録担当
正式な記録先へ最小項目を転記し、メーラー内記録とOS本体同期を区別します。未同期一覧を確認し、手動転記済みも記録します。
連携・監査担当
書込API、予約一意キー、項目対応、権限、重複防止、再送を検証します。送信要求だけを同期成功とせず、相手側反映と再取得を確認します。
送信後の状態を正直に示す記録
メール送信、メーラー内保存、PMS転記、OS同期は別イベントです。それぞれの成功・失敗・担当を記録すると、「登録したはず」という思い込みを防げます。
- 送信：お客様へ18時のケーキ手配を案内。送信ID、本文、送信者、時刻を保存。
- 明細：4号一台、18時、レストラン、厨房担当、税込金額。予約番号へひも付ける。
- メーラー内：保存成功。OS本体へは書き込まれていないため「OS未同期」と表示。
- 手動転記：PMSの予約メモへ必要項目を転記し、転記者と時刻を記録。未同期表示の運用上の意味をはっきりさせる。
- 将来同期：書込成功応答とPMS再取得を確認した明細だけを同期済みとする。
30日で送信後記録を安定させる
- 1週目送信後にPMSへ残す項目、現在の転記流れ、漏れ、二重登録を調べます。
- 2週目予約確定、明細、送信、メーラー内保存、PMS転記、同期状態の完了条件を分けます。
- 3週目未同期の標準転記を少数案件で試し、当日一覧と手配担当が確認できるかを実機確認します。
- 4週目送信済み未記録、未同期仕事の停滞、重複手配を測り、API連携の優先項目と受入条件を決めます。
責任者が見ておきたいこと
責任者は「記録済み」という表示の保存先を確認します。現時点のメーラー内記録をOS本体の自動同期と説明せず、未同期の仕事を担当付きで追います。将来連携でも、送信・書込・相手側反映が部分失敗する前提で復旧手順を用意します。
よくある失敗と防ぎ方
- メーラー内の登録をPMS同期済みと取り違える。画面、通知、記事で未同期をはっきり書きます。
- メール全文をPMSメモへ貼り付け、重要な手配が埋もれる。構造化した最小項目と原文参照を使います。
- 送信成功だけで完了にする。記録と手配の結果を別々に確認します。
- 同期失敗時に同じ明細を何度も作る。外部IDと冪等性、手動対応履歴で重複を防ぎます。
改善できたかを数字で確かめる
システムを入れただけで終わらせず、現場の仕事がどう変わったかを定期的に確認します。
- 送信済み・未記録件数
- メール送信は成功したが必要な約束・手配が記録されていない案件を最優先で確認します。
- 未同期止まっている時間
- メーラー内登録から正式なPMS記録確認までの時間を測り、手動転記と将来連携の優先度を決めます。
- 重複手配件数
- 再試行や手動転記で同じ明細が二重になった事例を追い、共通の管理番号と確認手順を改善します。
よくある質問
現在、おもてなしメーラーからOS本体へ自動で書き込まれますか？
現在のデモ画面では、確定予約にひも付けた手配品をメーラー内へ残せますが、OS本体への書き込み・同期は行わず「OS未同期」と表示します。実装済みと取り違えさせないことを優先しています。
自動連携がなくても運用できますか？
できます。確定予約、転記する最小項目、担当者、完了チェックを決め、メーラー内の未同期一覧からPMSへ標準転記します。件数と負担を測り、効果の大きい項目からAPI連携を検討します。
将来自動連携するには何が必要ですか？
OS・PMS側で何を書き込めるかを確認します。あわせて、ログイン方法、予約番号の扱い、権限、重複防止、変更やキャンセル、失敗時の再送も確認します。最後に、テスト予約を使って、書き込みと読み取りが正しく動くかを実際の画面で確かめます。
まとめ
メール送信後にPMSへ残すべきなのは、現場が使える確定事項の要約です。さらに、返信から発注や準備が生まれたら、担当と期限を持つ手配として実行まで追います。PMSの仕様を確認し、人の承認、予約見分け、操作履歴、失敗時の復旧を備えることで、便利な機能ではなく守れる業務になります。完了後の記録は手配の実施履歴、全記事はこちらです。
