1. 情報がすべてそろった新規予約だけでなく、変更が入った予約でもテストします。
2. 挨拶に使う任意の情報がない場合は、汎用的な表現で補えます。金額、住所、入室案内が不確かな場合は、送信を停止します。
3. 各ボタンのリンク先も含め、受信者が実際に受け取る内容を確認して承認します。
テンプレートの合格基準は、送信時点の予約状況に合った最終メッセージが生成されることです。誤字がなく、プレビューが正常に表示されるだけでは十分ではありません。ゲストメッセージングシステムは、変更される情報を正しい宿泊予約から取得して反映し、送信ルールもその宿泊予約に引き続き適合している必要があります。
以下のチェック項目を使い、送信するか、修正して再テストするか、スタッフの確認まで保留するかを判断してください。確認するのは、フィールドに何らかの文字が表示されるかではなく、その内容が適切かどうかです。
プレビューを確認する前に、期待するメッセージを書き出す
変数とは、氏名や到着日などの予約情報に置き換えられるプレースホルダーです。ソフトウェアが対応するフィールド選択機能から選んでください。別のシステムからコピーしたフィールド名は、正しく見えても機能しない場合があります。
スタッフが管理する架空のテスト予約を例にします。Maya様の到着日は11月24日、宿泊料金は240米ドルで、予約金60米ドルをすでに受領しています。ほかに請求がない場合、客室料金の未払い残額は180米ドルです。実際の客室はまだ割り当てられていません。
残額の支払い案内であれば、適切な出力例は「Maya様、こんにちは。ご到着日は11月24日です。客室料金の未払い残額は180米ドルです。」となります。240米ドルを請求したり、未確定の客室番号を伝えたりしてはいけません。
プレビューとは別に、反映されるべき情報を書き出します。前日のメッセージではなく、予約情報とホテルに記録された決済情報に照らして確認してください。そうしないと、すべてのプレースホルダーが置き換わったというだけで、もっともらしい出力をスタッフが承認してしまうおそれがあります。
誰に送るべきかも確認してください。Maya様の予約をアシスタントが代行しているかもしれません。メッセージ内の宿泊者名が正しくても、送信先が間違っていれば不合格です。
Smart Orderでは、ゲストとの会話の横に予約情報が表示されるため、フロント担当者は返信内容を宿泊情報と照らし合わせて確認できます。日付や支払いに関する問い合わせへの回答は、この情報を使って確認してください。テンプレートを選択できること自体は、テストに合格している証明にはなりません。
ゲストの次の行動を左右する情報を確認
支払い、来館、施設固有の手順をゲストに案内する前に、会話の横に表示される予約情報を確認しましょう。
テンプレートに不具合が生じやすい予約をテストする
引き続きMaya様のテスト予約を使い、条件を1つずつ変更します。承認済みのテストデータとスタッフが管理する送信先を使用し、実際のゲストへの送信や本番の支払い請求は行わないでください。以下はテストケースであり、決められた画面操作の手順ではありません。
メッセージの準備後に到着日が変更された場合
システムが対応する手順で、テスト予約の到着日を11月24日から26日に変更します。新しいプレビューに加え、準備済みまたは送信待ちのメッセージも確認してください。変更後の日付が反映されるか、古いメッセージの差し替えが必要な状態として送信が保留されれば、適切な結果です。
新しいプレビューだけが更新される場合、日付フィールド自体は正しくても、保存済みのメッセージには以前の値が残っている可能性があります。システムが対応する操作で、古いメッセージを削除または差し替えてください。この制約は送信手順に記録しておきます。
送信前に追加の入金があった場合
承認済みの決済テスト方法で、追加の40米ドルを受領したとします。客室料金の未払い残額は180米ドルではなく、140米ドルになるはずです。支払い案内が更新されるか、以前の支払い請求が引き続き有効になっていないかを確認してください。
現在の残額を確実に確認できない場合は、金額を記載せず、スタッフが確認した請求内容で案内する運用にしてください。予約総額で代用してはいけません。OTAで事前決済済みのテスト予約では、ホテルが徴収すべきでない客室料金を請求していないか確認します。
任意の情報が未入力の場合
適切なテストデータから、任意項目である名を削除します。エディターが対応していれば、「こんにちは」のような汎用的な挨拶でも問題ありません。フィールド名がそのまま表示されたり、挨拶が空欄になったり、メールアドレスから推測した名前が使われたりする場合は不適切です。
必須情報が欠けている場合は、別の対応が必要です。通貨、施設の住所、到着時に必要な案内が欠けている場合は、メッセージを保留して確認してください。親しみやすい表現にしても、安全性に問題のある案内は解消できません。
予約者、施設、客室が異なる場合
アシスタントがMaya様の予約を代行するケースと、必要に応じて別の施設の予約をテストします。送信先、挨拶、住所、連絡方法、到着時の案内をそれぞれ個別に確認してください。1つの値が正しくても、ほかの値が正しいとは限りません。
客室ごとのメッセージでは、割り当てられた客室をフロントデスクの予約画面と照合します。入室案内には、別途承認済みの送信前チェックが必要です。予約が確定したという理由だけで、客室番号や暗証番号を送信してはいけません。
送信チャネルや言語が変わる場合
利用可能であれば、実際に使う送信チャネル上で、安全なテスト用の送信方法を利用します。受信したメッセージをスマートフォンで読み、リンク、改行、翻訳された表現を確認してください。メールのプレビューが正常でも、OTAの会話画面に同じ内容が表示されるとは限りません。
翻訳後もフィールドが正しく機能する状態を保ち、支払い依頼が支払い完了の通知に変わらないようにしてください。テスト用リンクを開き、用途が正しいことを確認します。共有する品質確認メモには、実際の入室用認証情報や本番の決済リンクを記載しないでください。
送信、修正して再テスト、保留のいずれかを判断する
このテンプレートの目的に不可欠なケースを確認して承認します。歓迎メッセージでは残額のテストが不要な場合もありますが、支払い案内では必要です。すべてのフィールドを一律に確認するのではなく、誤ったメッセージがもたらす影響に基づいてテストを選んでください。
原因が特定できている場合は、修正して再テストします。たとえば、未対応のフィールド、任意項目が空欄の場合の代替表現の不足、古い固定文などが該当します。問題が生じたケースと、その変更の影響を受けるほかのケースを再度テストしてください。通常の予約1件が正しく表示されるだけでは十分ではありません。
安全に送信できる最新の値や送信先を確認できない場合、または送信待ちのメッセージを確実に更新できない場合は、スタッフの確認まで保留します。正しい返信を1件手入力すれば、そのゲストには対応できますが、再利用するテンプレート自体の修正にはなりません。
目的とバージョン、テストした条件、期待した結果と実際に受信した結果、承認者を記載した承認記録を残します。決済ルール、施設情報、言語、送信タイミングを変更した場合は、関連するテストを再実施してください。確認表を埋めるためだけに、関係のないフィールドを再テストする必要はありません。
誤ったメッセージをすでに送信してしまった場合
該当するテンプレートまたは送信待ちキューを一時停止します。バージョンと送信期間から受信者を特定し、承認済みの方法で、内容を明確にした訂正メッセージを1通送信してください。挨拶の間違いと、別のゲストの客室情報の送信や誤った支払い請求とでは、必要な対応が異なります。
決済や入室に関する誤りは、担当責任者と連携し、以前の請求の取り消しや認証情報の無効化が必要か判断してください。再度支払いを依頼する前に、入金状況を確認します。他者の情報が開示された場合は、ホテルの個人情報保護手順に従って対応してください。
不合格となった条件で再びテストに合格してから、自動送信を再開してください。再開の判断基準は、エディターで保存できるかどうかではなく、受信者が実際に受け取る内容です。
