FIELD NOTE / 折り返し・日程調整
予約変更の電話で確認すること｜変更前後の記録を残す
元の予約を見失わずに変更を受け付けるため、対象確認、変更希望、可否照会、新旧予約の確定、通知までをチェックシートにします。
最初に押さえること
予約変更は元予約を上書きせず、対象を特定してから変更希望を受け、可否確認後に新予約を確定し、旧予約との関係を履歴へ残します。
1. 変更内容を聞く前に、対象予約を特定する
同じ顧客が複数の予約を持つ場合、氏名と希望日だけで変更すると別の予約を動かす恐れがあります。受付番号、現在の日時、サービス、場所、担当など、自社で必要な識別項目を照合します。本人確認が必要な予約は、正式な手順を終えるまで詳細を案内しません。
対象が見つからない、複数候補がある、すでに変更や取消が行われている場合は、その場で新しい日時を確約しません。候補IDと不一致項目を記録し、予約管理の正本と担当者へ確認します。顧客には、特定のために何を確認しているかを簡潔に案内します。
2. 元予約、希望、可否、確定を一つの記録でつなぐ
以下は架空の変更チェックシートです。新しい日時だけを上書きせず、元予約IDと変更理由、追加確認が必要な条件を残します。料金や取消条件が変わる場合は、権限のある担当が現行規程を確認してから案内します。
| 段階 | 確認・記録する項目 | 確定前の注意 |
|---|---|---|
| 対象確認 | 元予約ID、現日時、サービス、場所、本人確認 | 候補が複数なら変更しない |
| 希望受付 | 新しい希望、変更理由、連絡可能時間 | 希望を確約へ書き換えない |
| 可否照会 | 空き枠、担当、設備、料金・条件への影響 | 根拠版と承認者を記録 |
| 変更確定 | 新日時、新予約ID、旧予約の状態 | 新旧両方の表示を確認 |
| 通知 | 顧客・担当・関係部署への案内内容 | 送信先と到達・回答要否を確認 |
3. 新予約の確定後に、旧予約の扱いを更新する
旧予約を先に取消すと、新しい候補が取れなかったときに両方を失うことがあります。仮押さえが可能か、承認が必要かを確認し、新予約が確定してから旧予約を変更済み・取消済みへ更新します。システム上の順序は利用中の予約管理仕様に合わせて試験してください。
顧客には、変更後の日時だけでなく、元予約が無効になったこと、場所・担当・料金など変わる条件、再変更や取消の方法を復唱します。関係部署への通知も同じ内容にそろえ、顧客向けと社内向けの表示が食い違わないかを確認します。
4. 変更履歴を残し、当日の混乱から改善点を拾う
変更前の情報を消さず、受付者、日時、顧客希望、確認結果、承認者、通知先を履歴に残します。顧客の個人情報は必要な範囲に限定し、閲覧権限と保存期間は社内規程に従います。誤変更が起きた場合は、復元と顧客連絡の手順も用意します。
振り返りでは変更件数だけでなく、対象予約の取り違え、通知漏れ、旧予約の残存、追加料金の案内漏れを確認します。同じ原因が続くなら、識別項目、画面表示、復唱文、承認順序のどこを変えるかを決めます。
よくある質問
新しい候補日が決まったら、元予約をすぐ削除してよいですか？
候補と確定は別です。新予約が必要条件を満たして確定した後に、旧予約を変更済みまたは取消済みへ更新し、両者の関係を履歴へ残します。
予約変更の理由は必ず聞くべきですか？
業務上必要な場合だけ、目的を説明して必要最小限を聞きます。詳細な私的事情を必須にせず、手配・料金・再調整に必要な分類で足りるかを確認します。
参考資料・この記事の位置づけ
本文の帳票や進め方は、ContactXによる運用設計の提案です。効果を保証する数値や、特定企業の導入実績ではありません。
- Amazon Connect：Casesによる顧客案件の管理
複数回のやり取り、対応手順、結果を一つの案件として追跡する考え方を確認するための一次資料。記事中の項目名・状態・記入例はContactXによる架空の運用設計です。
- Amazon Connect：Tasksの設定
フォロー作業を担当者や共有キューへ割り当て、必要項目をテンプレート化する機能例を確認するための一次資料。特定製品の導入を前提とせず、実際の設定は利用中のシステムで確認してください。