予約システムとスマートロックの連携確認｜変更後の鍵・支払い・案内をそろえる
無人サロンの開業前に、予約システムとスマートロックの連携を確認するなら、一度入れた予約を変更してみてください。予約したときに鍵が発行されるのは、連携で確かめる経路の一つです。完成の判断には、変更やキャンセルの後も、最新の予約、誰がいつ入れるか、支払い、お客様への案内がそろっていることを含めます。
14時の予約を16時へ変更したら、何がそろうか
ここでは、1室だけの無人サロンで、Aさんが14:00〜15:00の予約を16:00〜17:00へ変更する架空の例を使います。前払い済みで、時間変更による料金差はなく、入室を認めるのは予約時間内だけとします。実在店舗の導入事例や実機の検証報告ではありません。
変更後に残す有効な予約は、Aさんの16:00〜17:00です。Aさんが変更前の案内を手元に残していても、この予約を根拠に14:00〜15:00には入れない状態にします。一方、16:00〜17:00には、新しい案内に従って入れることを確かめます。
暗証番号を変えるか、同じ番号の有効時間を更新するかは、利用するサービスや機種によります。番号が変わったかどうかより、変更前の時間帯の入室権限が無効になり、変更後の時間帯だけ正しく使えるかが確認の対象です。
支払いは、この例で決めたルールどおり、支払済みの代金を引き継ぎ、追加請求をしない扱いにします。顧客に届く案内にも16:00〜17:00と、実際に使う鍵の情報が必要です。店側の予約表を直しただけで終えず、受け取った案内まで照合します。
管理画面と実機の結果を並べる
次の表は、同じ架空予約の確認メモを記入した例です。確認結果も説明用の仮定で、実測値ではありません。一部を確認できても、まだ無人運用へ進めない状態を示しています。
| 確認する対象 | 期待する状態 | 確認結果の記入例 |
|---|---|---|
| 予約と利用者 | Aさん・1室・16:00〜17:00が有効 | 予約画面は一致 |
| 変更前の14:00〜15:00 | Aさんの変更前の予約では解錠できない | 管理画面は時間変更済み。実機確認待ち |
| 変更後の16:00〜17:00 | 案内した鍵で時間内に解錠でき、時間外はできない | 16:00の解錠は確認済み。開始前・終了後は実機確認待ち |
| 支払い | 支払済みを引き継ぎ、追加請求なし | 決済記録は一致 |
| お客様が受け取る案内 | 16:00〜17:00と使う鍵が分かる | 受信した案内は一致 |
この表なら、無人運用開始の判定は保留です。16時に開くことが確認できても、14時に開かないことや、新しい予約時間の前後に使えないことは未確認だからです。
管理画面の変更表示と、設置した鍵への反映は分けて確かめます。クラウド側で削除・変更済みになっても、その表示だけで実機が設定を受け取ったとは判断しません。実機確認待ちの行には、担当者と確認予定を添えて残します。
キャンセル後は、入室停止と返金を分けて確かめる
同じ予約を利用開始前にキャンセルした場合、今度は16:00〜17:00にも、その予約では入れないことを確認します。先ほど変更した14時の入室権限も、無効のままか確かめます。
代金については、店側のキャンセルルールを先に当てはめます。たとえば、この予約をキャンセル料なし・全額返金の対象とするなら、予約取消の完了と返金の完了を別々に確認します。返金手続き中なら、その状態を残し、返金済みと案内しないようにします。
お客様への通知では、予約が取り消されたこと、以前の鍵の案内では入室できないこと、返金の扱いが食い違っていないかを見ます。取消、鍵の無効化、返金、通知がどこまで自動で連動するかは、選んだ構成で確認が必要です。
決済失敗時の扱いも、利用プランごとに決めます。利用を止めるのか、再決済を待つのかを決めたうえで、その間の予約、入室の可否、通知をそろえます。一律に即時キャンセルされるものとして扱わないようにします。
反映待ちの間に誰が対応するかも決める
変更内容が鍵に反映されるまで待つ場合、来店時刻までに確認を終えられるかが問題になります。導入先には、反映をどう確認するかに加え、確認できないときに誰へ連絡が届き、誰が店舗で対応するかを聞きます。
店側では、来店前のどの時点までに確認を終えるかを決めます。その時点で確認待ちなら無人での受け入れを止め、現地担当者が確認・対応できる利用に限定します。対応者を用意できなければ、利用を見合わせてお客様へ連絡する運用にします。
通信が途切れた後や、処理をやり直した後も、最後に確定した予約と実機の状態を再照合します。再試行が終わったという表示だけで確認待ちを消さないことが、引き継ぎの条件になります。
なお、鍵の有効時間が終わっても、室内の人が退室したことにはなりません。退室の確認と緊急時の入退室対応は、別に決めておきます。
開業前の実演は、同じ予約の変更から依頼する
納品時には、導入先にこの例のような予約変更を実演してもらい、店側が期待する状態と、確認できた結果を並べます。続けて同じ予約をキャンセルし、使える時間が残っていないか、代金と案内が決めた扱いになっているかを確認します。
標準の連携機能でこの確認を満たせるなら、追加開発を増やす必要はありません。店内のルールが決まっていなければ先にそろえ、標準機能で足りない箇所が分かってから追加の連携や個別開発を比べます。その場合も、修正や保守を誰に頼むかまで決めます。
開業前に残しておくのは、確認済みの結果と、未確認の項目、その担当者です。最新予約に対して入室、支払い、案内がそろい、実機の確認待ちがなくなったことを、無人運用へ進む条件にしてください。