1. 予約可能な客室が見つからない検索、客室選択時の離脱、フォームの問題、最終確認画面での離脱を分けて把握します。
2. イベントの未記録を予約機会の損失と判断する前に、予約エンジンへの移動後もゲストの行動を計測できているか確認します。
3. 確認できた障害を1つ改善し、ウェブサイト全体のコンバージョン率だけでなく、同等の条件の予約プロセスを比較します。
ゲストがホテル予約エンジンから離脱する理由は、すべて同じではありません。希望に合う客室が見つからない人もいれば、電話番号を入力できない人もいます。合計金額の確認まで進んで初めて、想定していなかった支払い条件に気づく人もいます。
経営者がすべきことは、実際にどの障害が存在するかを特定することです。すべての客室料金を引き下げても、スマートフォンで動作しないフォームは直りません。また、ホームページを刷新しても、誤って販売停止にした客室の空室状況は元に戻りません。
本記事では、決済前の予約プロセスを扱います。ゲストが決済を開始した後に支払いを拒否された場合は、単なる離脱として扱うのではなく、決済に関する調査が必要です。
予約プロセスを計測できているか確認する
ウェブサイトと予約エンジンの管理担当者に、予約プロセスの簡単なレポートを依頼しましょう。日程の検索、販売可能な選択肢が表示された検索、客室または料金プランの選択、予約手続きの開始、決済ステップへの到達を区別できる内容が必要です。
各段階の定義を文書化しましょう。ウェブサイトの予約ボタンをクリックすることと、客室を選択することは異なります。決済ページへの到達だけでは、ゲストが決済情報を送信した、支払いを済ませた、または宿泊予約を確定したとは判断できません。
計測には設定が必要です。予約エンジンが別のウェブアドレスで開く場合は、その移動を一貫して計測できているか、提供会社に確認してもらいましょう。ブラウザーのプライバシー設定や同意設定によっても、確認できる情報が制限されます。計測できていない訪問者を、離脱したと断定してはいけません。
確定済みの直接予約をいくつか抽出し、記録された予約完了データと照合しましょう。実際の予約があるのにレポートに表示されない場合は、まず計測を修正します。現地払いのプランでは、オンライン決済がなくても予約が正しく確定している場合があります。
ゲストの氏名、メールアドレス、カード情報、決済認証情報を、一般的なウェブ解析ツールに送信しないでください。経営者に必要なのは、各段階の件数と、権限のある担当者が照合するための安全な予約参照情報です。ゲストの非公開の決済情報ではありません。
ホテル予約エンジンの離脱を段階ごとに読み解く
ここでは、集計を終えた対象期間に計測された、240件の予約プロセスを仮の例として取り上げます。各プロセスは各段階で1回ずつ数えられ、後の段階の件数は前の段階の件数に含まれます。
- 240件で日程が検索されました。
- 180件で、販売可能な客室プランが1件以上表示されました。
- 72件で客室と料金プランが選択されました。
- 36件でゲスト情報を入力する予約手続きが開始されました。
- 24件が決済ステップに到達しました。
これは予約プロセスの件数であり、必ずしも240人の異なる利用者を意味するわけではありません。ある段階ではページの再読み込みや客室の再検索によって件数が増える一方、別の段階ではユニーク訪問者数を数える、といった集計は避けましょう。また、完了までに認める時間を統一し、後から完了するプロセスを早まって離脱と数えないようにします。
最初の差は、販売可能な結果が表示されなかった60件の検索です。これは空室状況に関する問題であり、この時点で予約手続きの画面設計を評価することはできません。プランが表示された180件から選択に至った72件までの差はさらに大きいものの、日程や料金を比較しているだけの訪問者もいます。
フォームから決済までの間で進まなかったのは、予約手続きを開始した36件のうち12件、約33.3%です。実際の利用者が必須項目を入力できないのであれば、対応が必要です。ただし、この数値はホテル全体の離脱率ではなく、この例も業界のベンチマークではありません。
十分な件数がある場合は、モバイルとデスクトップ、流入元、宿泊日程ごとに比較しましょう。少数のサンプルはテストの着眼点にはなりますが、コンバージョンに継続的な問題があると判断する根拠にはなりません。
予約の確定結果を照合する
予約エンジンには、ゲストが選択できた内容が表示されます。一方、ホテルの業務記録には、実際に成立した予約が記録されます。完了記録が見当たらない理由を解釈する際は、この役割の違いを踏まえましょう。
ホテル管理システムと連携したホテル予約エンジンでは、完了した直接予約がホテルの一括物件管理ソフトに登録されます。Smart Orderでは、最新の空室状況と客室料金が直接予約向けのプランに反映され、成立した予約をフロントデスクで確認できます。この連携を活用して最終結果を確かめれば、ウェブサイトの完了記録がないだけで、すべてを予約機会の損失と判断せずに済みます。
直接予約向けのプランと、そこから生まれる予約をつなぐ
ウェブサイトの空室状況、客室料金、確定した直接予約を連携させ、スタッフがゲストの予約プロセスの結果を手間なく確認できるようにしましょう。
離脱箇所に応じて、実施できる確認を選ぶ
検索しても希望に合う客室が表示されない
実際と同じ日程と宿泊人数で再検索しましょう。客室の定員、子どもの年齢、最低宿泊日数、販売停止中の料金プラン、販売対象から外した客室を確認します。空室のあるホテルでも、特定の検索条件ではプランが表示されないことがあります。
一般公開されている検索結果と、販売が承認されている空室状況を比較しましょう。実際に満室であれば、予約不可という結果は正しい表示です。設定に誤りがある場合は、客室在庫を一律に開放するのではなく、該当する制限や客室の販売設定を修正します。
機能が対応している場合は、別の日程や条件に合う客室を提案しましょう。実際には予約できない代替案を案内してはいけません。
客室は表示されるが、料金プランが選択されない
複数の画面を開かなくても、ゲストがプランの内容を理解できるか確認しましょう。ベッド構成、定員、朝食の有無、キャンセル条件、宿泊料金の総額を簡単に比較できることが大切です。
広告や客室ページで案内している条件で再検索しましょう。広告に掲載したプランが見つからない場合は、料金が高すぎると判断する前に、その不一致を解消します。紛らわしい重複プランを整理する際は、残す料金プランで実際のゲストのニーズを満たせることを先に確認しましょう。
フォームの入力を始めても、決済に到達しない
一般的なスマートフォンでフォームを最後まで入力してみましょう。海外の氏名や電話番号の形式、日程変更、エラーメッセージを確認し、前の画面に戻ったときに入力内容が消えないかもテストします。
予約や適用される規則のためにホテルが本当に必要とする情報は残しつつ、不要な必須項目がないか提供会社と確認しましょう。予約手続きを短くするためだけに、必要な本人確認や決済の安全対策を省いてはいけません。
一般的なモバイル回線で読み込みを確認しましょう。予約エンジン全体が遅いと伝えるだけでなく、該当する画面、入力項目、端末、テスト結果を具体的に示して修正を依頼します。
合計金額の確認時や決済への移行時に離脱する
初めて利用するゲストの視点で最終確認画面を読みましょう。請求通貨、必ず支払う金額、今支払う金額、後日支払う残額、キャンセル条件を明示する必要があります。予約金の支払いが、説明もなく突然、全額前払いに見えるような表示は避けましょう。
表示されているホテルのオンライン決済方法が、テスト対象の市場と予約で実際に利用できるか確認しましょう。ゲストが決済を送信した後に認証を完了できない場合や、支払いを拒否された場合は、決済担当者向けに別途記録します。
予約を最後までテストして、1つの改善を検証する
テスト用の宿泊条件を定め、提供会社が承認したテスト手順に従いましょう。合意した計画なしに、本番環境で繰り返し課金したり、残り少ない客室をテスト予約で押さえたりしないでください。
- 同じ日程、宿泊人数、プラン、端末で、特定した問題を再現します。
- 電話番号欄の修正や予約金に関する表現の明確化など、範囲を限定した変更を1つ行います。
- 問題のあった段階を含めて予約プロセスを再度進め、許可されている場合はテスト予約を完了します。
- 予約完了の通知と、登録されたフロントデスクの予約を照合し、日程、客室、客室料金、支払い条件、必要な客室在庫の調整まで確認します。
その後、変更前後で同等の条件の予約プロセスを比較します。流入の質、端末の構成比、日程ごとの空室状況、販促施策も考慮しましょう。同時期に大規模な新規キャンペーンで訪問者層が変わっているのに、ボタンの改善だけが成果につながったと断定してはいけません。
メールアドレスを入力した訪問者全員に連絡しないでください。予約再開を促すメッセージを送るには、連絡が認められる根拠、正確な予約状況、今後のマーケティング配信を拒否できる明確な方法が必要です。通常のメールでカード情報を求めてはいけません。
得るべき成果は、具体的な検証結果です。予約条件を満たす利用者がどの段階で離脱したのか、どの障害を確認したのか、何を変更したのか、そして予約や決済のエラーを生じさせずに、その段階を完了するゲストが増えたのかを明らかにしましょう。
