OpenTableの代替案：予約手数料が「成長への課税」のように感じ始めたとき

OpenTableは二つの問題を一度に解きます。だから多くのレストランが乗ります。予約、ウェイトリスト、テーブル、ゲストメモ、フロアプランを管理しつつ、大きな消費者向けマーケットプレイスにも載ります。運用ツールと発見トラフィックの両方を欲しい独立店や小規模グループには、最初は組み合わせが理にかなっています。

問題はその下のモデルです。OpenTableの価格は、店が忙しくなるほど請求が膨らむように組まれています。ソフトが余計なことをするからではなく、来店が増えるからです。成功とコストの関係は、大きな項目になる前によく見ておく価値があります。見始めると、他の問題も見えてきます。

OpenTableがすること

OpenTableのマーケットプレイスへのリーチは実在します。都市でディナー客がプラットフォームを検索して店を探すなら、掲載は本来取れなかった予約を生むことがあります。プロフィールを築く新しい店や、空きを埋めたい会場には一定の価値があります。

マーケットプレイス以外では、OpenTableは予約ワークフローをカバーします。テーブル計画とフロア管理、ゲストメモとVIPタグ、ウェイトリスト、基本的なCRM、フロント向けモバイルアクセスです。

発見がまだ主な課題で予約量が扱いやすいレストランなら、短期的にはトレードオフが成り立つこともあります。事業が成長すると、その計算は変わります。

成長するほど価格モデルが正当化しにくくなる

OpenTableは月額に加え、予約のソースと種類に応じた手数料を重ねます。マーケットプレイス予約、体験予約、プリペイドカバー、プロモ掲載はそれぞれレートが違います。業界の分解では、静かな週なら許容範囲に感じるカバー単価が、忙しいマルチサイトでは無視できない水準になる、と一貫して言われます。

最も表面化する不満は手数料そのものではなく、その論理です。オペレーターは、自サイト、自社のGoogle掲載、自社SNSから来た客にまでOpenTableにカバー単価を払っていると報告します。ディナーはマーケットプレイス経由ではありません。自社マーケが連れてきました。ただ予約がOpenTableウィジェットを通ったので、手数料がかかる、という動きです。

それがツールを依存に変えます。自社マーケがうまくいくほど、その特定の予約に貢献していないプラットフォームに補助金を出すことになります。経済性は複数店で積み上がります。五〜六店で月額＋大量のカバー手数料を払うグループは、OpenTableがウィジェットを外さないと削れない実質的な固定費になり得ると感じることがあります。

ゲスト関係は「借り物」に感じられる

価格の下にもう一つ深い問題があります。OpenTableはレストランにダイナーデータへのアクセスを与えますが、データはOpenTableのエコシステムの中にあります。履歴、連絡先、予約パターンは、店がコントロールしないプラットフォームにあります。

多くのオペレーターに、やがて特定の苛立ちが生まれます：他店での習慣まで含め、常連についてOpenTableの方が店より多く知っている、と。店は食事を提供し、より完全な絵はOpenTableが持ちます。

ロイヤルティ、CRM、ダイレクトマーケ、会員プログラムを本気で考え始めると効いてきます。それらを支えるべきゲストデータの一部がサードパーティに閉じ込められ、直接関係を築くにはより豊かなデータへの追加課金か、OpenTableが渡さない部分を補う別システムが要ります。

ブランディングの問題

OpenTable経由のゲストの予約体験はOpenTableの体験です。サイトのウィジェット、確認メール、来店前後のデジタル接点は、レストランではなくOpenTableのブランドです。個性的なブランドやプレミアムなアイデンティティを築くオペレーターにとって、予約プロセスの最初と最後が、同じUIで何千もの他店も予約する汎用プラットフォームに縛られるのは制約です。

特定の空気やメンバーズクラブのイメージを作るレストランにとって、築いたブランドと届けているテクノロジー体験のずれは実害があります。予約ジャーニーが他人のプロダクトの中にある限り、ゲスト関係を完全には所有できません。

本当に重要なときのサポート

OpenTableの対応の速さ、解決、自動チャネル依存への公的な批判の量は、真剣に見るに足ります。レストランにとって予約システムの障害は即時のリスクです。満席の土曜に消えた予約は、月曜まで待てるソフト問題ではありません。Trustpilotやオペレーターフォーラムには、遅い返答、実際に直せる人に届かない難しさ、問題と解決のギャップへの不満が繰り返し出ます。

代替を検討するサイン

店が忙しくなるほどカバー手数料が目立つようになった。自社マーケ由来の予約にもOpenTableに払っている。ゲスト関係が自社CRMではなくOpenTableの中にいるように感じる。ロイヤルティ、CRM、ギフトカード、会員、POS、決済に別システムが要る。

事業のあらゆる部分をまたいだゲストの全体履歴を一か所で見られない。重要な瞬間にサポートに裏切られた。予約体験がOpenTableであって自社ブランドではない。ホテル、イベント、会員、ウェルネスに広がったがOpenTableはその一片しかカバーしない。ゲストデータを完全に所有したいのであって、サードパーティ経由の版で妥協したくない。

なぜオペレーターがTiquoへ移るか

移行の主な論拠は経済と構造です。

Tiquoはプラットフォームに対して課金し、予約ごとには課金しません。カバー単価はなく、自社マーケ由来の予約への手数料もなく、店が忙しくなるほど不利になる価格モデルもありません。予約量の多いマルチサイトを運営するオペレーターにとって、それだけで月次コストの計算は大きく変わります。

より大きな変化は構造です。TiquoはCRMが少し付いた予約プラットフォームではありません。予約、POS、CRM、会員、ロイヤルティ、ギフトカード、ホテルPMS、スパ・ウェルネス予約、イベント管理、チケット、決済、分析が一つのシステムにあります。ゲストプロフィールの中身が変わります。

OpenTableではプロフィールは予約行動から作られます。Tiquoではすべてから：すべての予約、POS取引、ロイヤルティ利用、会員のやりとり、イベント券、ホテル滞在、物販。同じプロフィールがあらゆる接点の全スタッフにリアルタイムで見えます。予約の置き場と支出データと連絡先の間に断片化はありません。一つのレコードが常に最新で、常にアクセス可能です。

設定済みの接続アカウントでは、Tiquoがひとつの会計を複数の入金先に振り分け、その内訳を注文に紐づけたまま管理できます。予約、注文、決済、会員、ロイヤルティが同じ業務記録を共有するため、システム間の照合作業が減り、すべての決済が注文に直接紐づいて自動で照合されます。Club Payは施設全体で対象の商品やサービスに使えるストアクレジットを提供します。

予約からロイヤルティまで、顧客向けのあらゆる接点はプラットフォームではなくオペレーターのブランドです。事業がゲストと築く関係は事業のものです。データはサードパーティのマーケットプレイスにありません。記録、支出パターン、会員履歴、連絡設定は自社プラットフォームの中で、自社のマーケ、ロイヤルティ、商業判断に供されます。

判断

マーケットプレイスが意味のある発見を連れてきて、カバー経済性が得られる価値に見合うなら、OpenTableは引き続き理にかなります。本当の計算で、店・都市・オーガニック対マーケットプレイス由来の予約量によって答えは変わります。

転換点は計算が変わるときです。自社で連れてきた客へのカバー手数料が、自前の玄関に家賃を払うように感じられるとき。ゲスト関係が所有より借り物のアクセスに感じられるとき。ホテル、会員、イベント、ウェルネスまで成長し、予約プラットフォームは広がり続けるスタックの一層にすぎないとき。

その時点での問いは、OpenTableにもっと良い条件を引き出す方法ではありません。空席を埋めるように設計されたモデルのプラットフォームで回すべきか、運営全体のために設計されたプラットフォームで回すべきか、です。