こんにちは、瓦.Tokyoの西田です。
以前、グルメサイトの活用についてご紹介した時に、Eparkグルメというサイトへの掲載契約にバンドルされている、Restyというアプリが使いたいが為に、有料契約を継続している、というお話をしました。
これは、リクルートさんであればレストランボード、食べログのカカクコムさんであれば、ヨヤクノートなどと同じような、有料の予約管理アプリなのですが、Eparkさんは、しばらく無料で使って良いよ！って事だったので、使っていたところ、今や(まんまと？)店舗運営上、無くてはならないアプリになってしまっています。
ちなみに、EparkさんのRestyじゃないと業務が回らない！という意味ではなく、別にレストランボードでも、ヨヤクノートでも問題は無い筈なので、ベンダーロックされている訳ではありません。Restyを使っている理由は、月額の使用料が他と比べて安いからです。
予約管理アプリを使う理由
【前提】即時WEB予約を受け付けている
まず、瓦.Tokyoは食べログやぐるなび等のグルメサイトからのWEB予約を受け付けています。これは、種類としては、ユーザーが予約リクエストを店舗に送信し、店舗側で空席を確認した後、予約可否を返信する「リクエスト予約」と、店舗側が各グルメサイトにテーブルを公開し、ユーザ側が空席のあるテーブルをリアルタイムで確保出来る、「即予約」の2種類があります。
このWEB予約、瓦.Tokyoは後者の即予約を採用しています。
※WEB予約は、営業時間外などでも予約を受け付ける事が出来る為、機会損を抑える効果があり、電話よりも簡単に席を確保できると感じるユーザ層の取り込みにも効果を発揮すると言われていますが、簡単に予約ができる反面、キャンセルへの心理的ハードルが低く、直前のキャンセルやノーショウが電話予約に比べて多い傾向にあるとも言われています。
実際に、体感としてもそれは正しいと思っています。また、電話予約であれば、手数料がかからない一方、WEB予約だと送客手数料がかかるのも、店舗にとってはデメリットです。
ダブルブッキングを防止する
即時WEB予約を受け付ける為には、グルメサイトにテーブルを公開する必要があります。当時、瓦.Tokyoは食べログとぐるなびの二つのサイトからWEB予約を受け付けていましたが、例えばテーブルがA卓〜D卓の4つあったとすると、食べログにはA卓とB卓、ぐるなびにはC卓とD卓、という感じで公開する必要がありました。
何故なら、複数のグルメサイトに同じテーブルAを公開してしまうと、それぞれのグルメサイトからのWEB予約がテーブルAに対して同時に入ってしまう、所謂ダブルブッキングが発生してしまう為です。
これを、予約管理アプリを使うと防止出来ます。
具体的には、テーブルA〜Dの全てを両方のグルメサイトに公開したとしても、例えば食べログからテーブルAのWEB予約が入った場合、アプリ側でぐるなび上で公開しているテーブルAをブロック(予約済ステータスへの変更)をしてくれる機能を活用する事で実現しています。
面倒なテーブルのステータス管理からの解放
とにかく、WEB予約を受け付けている、更にはそれが複数のグルメサイトにわたる場合、その管理事務は非常に面倒臭いの一言です。
席の予約は、WEBだけではなく、来店による予約、電話による予約(←これが一番多い)、メールでの予約など、様々な方法で予約の問い合わせがあります。
そして、例えば電話で予約を受け付け、テーブルAを抑えた場合、今後は食べログとぐるなびの管理画面(ブラウザベース)にログインし、それぞれのテーブルAを予約済に変更する必要があります。
一回の電話予約で、二回ブラウザを立ち上げ、二回IDとパスワードを入力し、各管理画面でそれぞれ予約されたお客様の人数などを入力する必要があります。
これを、予約管理アプリを使うと、アプリ上でテーブルAを確保すると同時に、食べログとぐるなびの2つのグルメサイト上のテーブルAの一括ブロックをアプリが自動で行ってくれます。
これは非常に便利で、特に忙しい営業時間中の予約の電話などを受けた時には大変重宝しています。
尚、即時WEB予約を受け付けていない店舗であれば、こんなシステムは不要です。恐らく、紙の台帳で十分だと思います。
リクエスト予約ではなく、即予約を受け付けるている事の効果測定は難しいですが、、どうなんでしょう笑
瓦.Tokyo 西田