予約後の体験を作る — 宿泊者専用ポータル

はじめに

予約が完了した瞬間、お客様との接点は途切れがちです。次に連絡が来るのはチェックイン前日、というケースも珍しくありません。その間、お客様は「本当に予約できているのか」「どうやって入るのか」と不安を抱えることになります。

この記事では、予約完了から宿泊終了までをカバーする宿泊者専用ポータルの設計を紹介します。無人チェックインの宿では、ここが体験の質を大きく左右します。

アカウントを作らせない

会員登録という壁

「マイページ」と聞くと、IDとパスワードでログインする画面を想像すると思います。しかし宿泊予約では、これは大きな障壁になります。

年に1回泊まるかどうかの宿のために、パスワードを作って覚えておく人はいません。ログインできずに問い合わせが来れば、無人運営のメリットも薄れます。

そこで、予約ごとに推測不能な専用URLを発行し、それを知っている人だけがアクセスできる方式にしました。URLそのものが鍵の役割を果たします。

安全性の詳しい設計は「URLひとつで安全に」で解説していますが、ポイントは「推測できないURL」「有効期限がある」「失効させられる」の3点です。

URLはメールと予約管理システムの両方に

発行したURLは、予約確認メールに記載するだけでなく、予約管理システムの予約データにも記録しています。メールが迷惑メールに埋もれてしまっても、運営者が予約データから確認して再送できるようにするためです。

時間とともに開いていく

情報を段階的に公開する

ポータルは予約直後から開けますが、最初からすべての情報が見えるわけではありません。チェックインが近づくにつれて、段階的に内容が増えていきます。

暗証番号を前日まで見せないのは、セキュリティ上の配慮です。半年前に予約した方の画面に暗証番号が表示され続けていると、その間にURLが漏れたときのリスクが大きくなります。

見せないのではなく「読み込まない」

ここで重要なのは、公開時期が来ていない情報は画面に出さないのではなく、そもそもデータベースから読み込まないという点です。

画面上で隠すだけの実装だと、ページの中身を調べれば暗証番号が見つかってしまいます。読み込んでいなければ、どこを探しても存在しません。

緊急連絡先だけは常に見せる

段階的な公開の例外が、緊急連絡先です。管理会社の電話番号と公的な緊急番号は、準備中の期間でも必ず表示します。

安全に関わる情報を「まだ公開時期ではない」という理由で隠すべきではありません。ルールには必ず例外を検討する余地がある、という一例です。

ポータルでできること

宿泊に必要なものを一箇所に

ポータルには、宿泊に必要な情報をひととおり集約しました。

決済の状況はあえてポータルに載せていません。金額に関わる情報はメールで確実に届けるほうが、記録としても残って確実だと判断しました。

セルフキャンセルを用意する

キャンセルの連絡は、電話やメールで受けると運営者の対応が必要になります。そこでキャンセル料が発生しない期間内であれば、お客様自身が手続きできるようにしました。

ただし手続きの前には、注意事項の確認とメールアドレスの入力を求めます。URLを知っている人なら誰でもキャンセルできてしまうと、いたずらの余地が生まれるためです。予約時のメールアドレスと一致しなければ手続きは進みません。

なお、OTA経由の予約ではこの機能を表示しません。OTA側の規約に従って手続きしていただく必要があるためです。

キャンセルの順序にも意味がある

キャンセル処理は、次の順番で実行します。

まず予約管理システムでキャンセルし、これが失敗したら全体を中止します。次に決済側の後始末（保存したカードの削除など）、そして自社データベースの更新、最後にURLの失効と通知メールの送信です。

外側から内側へ、影響の大きいものから順に。もし自社データベースだけ先に更新していたら、予約管理システムのキャンセルが失敗したとき「自社では取消済み、実際には予約が残っている」という最悪の状態になります。

まとめ

宿泊者専用ポータルの設計で軸にしたのは、次の3点です。

1. アカウントを作らせない — 専用URLひとつで完結させ、ログインの壁をなくす
2. 時間とともに開く — 暗証番号は前日まで読み込みもしない。ただし緊急連絡先は常に表示
3. キャンセルは外側から — 予約管理システムを最初に、失敗したら全体を中止する