飲食店のサイトに「ご予約はこちら」というボタンが一つある。店頭受取の注文をしたい人が押すと、人数と席の希望時間を聞かれ、備考欄に商品名を書くしかない。店側には席予約の通知として届き、厨房は注文に気づかない。反対に席を取りたい人が注文フォームへ入ることもあります。利用方法の違いを、最後の自由記入欄で判別する運用には無理があります。
店頭受取と店内予約では、入力する時刻の意味も、店で確認する担当も、返信で伝える内容も異なります。最初に「店頭受取」と「店内で食べる」を選べるようにし、二つの経路で必要な情報を分けます。この記事はメニューや席数を仮定して受付を増やす提案ではありません。現行の注文・予約方法と通知先を照合し、公式サイトで何を説明し、どこを改修するか判断するための設計です。
一つの「予約」で違う行動を受けない
「予約」という言葉だけでは、席を確保するのか、商品を作っておくのか、受取時間を指定するのかが伝わりません。トップページ、メニューページ、SNSプロフィール、検索画面から来る人が、同じ入口で迷わないようにします。ボタンの表示を「席を予約する」「店頭受取を注文する」と分け、現在その方法を受け付けているかも合わせて示します。
受取と席予約を両方受ける店でも、どの時間帯・商品・席種でも使えるとは限りません。昼だけ持ち帰りを受ける、特定の商品は前日まで、席は電話でのみ受ける、など実際の条件を先に調べます。条件を把握せずフォームだけ二つ作ると、受付できない依頼を集めます。店主、厨房、ホールの担当で、受けられる方法と更新責任を確定してから公開文を作ります。
既存の飲食店サイトの総合的な導線を扱う記事は、混雑告知や再来店まで含めて説明しています。本稿では、持ち帰りの注文が席予約へ混ざる一点を詳しく見ます。繁忙日の告知や売り切れ表示も、どちらの利用方法に適用するかを決めなければ、両方が停止したように見えます。
店の現行経路を紙に並べる
まず、店が実際に受ける経路を洗い出します。公式サイトのフォーム、電話、SNSのメッセージ、外部の注文サービス、席予約サービス、店頭での口頭受付。入口が複数あっても、最終的に厨房とホールがどの画面・帳票を正本として見るかを確認します。どの経路で受けても同じ枠へ反映されるとは限らないためです。
次に、最近の受付で聞き直しが起きた項目を見ます。「受取希望」とだけ書かれて商品が不明だった、席の時間と来店人数が違った、変更の連絡が元のサービスへ届かなかった、といった実際の事例があれば、必要項目を決める材料になります。個別の顧客情報は公開原稿へ移さず、店の運用上の不足だけを抽出します。改善率や注文件数は測定していないなら記載しません。
公式サイトの役割も決めます。サイトで注文・予約を完結させるのか、条件を説明して外部サービスへ渡すのか。店頭受取は外部サービス、席予約は電話という組み合わせもあり得ます。二つの行動の入口を明確にすることと、すべてを自社フォームで処理することは別です。店が使っている仕組みとスタッフが確認できる画面に合わせます。
利用方法を分ける二経路の図
分岐図の最初には「店頭受取」「店内で食べる」を置きます。受取経路では、対象商品、数量、希望受取時刻、受取方法と連絡先を確認します。店内経路では、人数、希望来店日時、席の条件、連絡先を確認します。どちらも、店側が確認した後の状態を知らせるまでを一つの経路として描きます。以下の図は設計例です。実際の入力や担当は店の運用に合わせて調整します。
店頭受取の時刻は、商品を渡したい時刻です。調理の開始や受付締切と同じではありません。席予約の時刻は来店や席の利用を始めたい時刻です。二つの時刻欄を「希望時間」だけで共通化すると、店側で解釈し直す必要があります。画面と通知の両方で「受取希望時刻」「来店希望時刻」を使い分けます。
分岐後に共通化できるのは、連絡先や規約の確認など、意味が本当に同じ項目です。変更・キャンセルの受付先や返信の文面は異なる場合があります。共通のフォーム部品を使うとしても、利用方法ごとの見出しと確認画面を設け、送信前に自分がどちらを申し込むか分かるようにします。W3Cのフォーム項目のグループ化は、関連する選択肢を視覚的にもコード上もまとめる考え方を示しています。利用方法の選択肢も、意味が分かるラベルとグループで示します。
一人の利用者が店内で食べ、帰りに別の商品を持ち帰りたい場合もあります。その組み合わせを一度に受け付けるのか、席予約と店頭受取を別々に申し込んでもらうのか、店が判断します。同時に受けるなら、同じ連絡先でも二つの依頼と時刻を別に記録します。別々に受けるなら、二件の受付番号が届くことと、必要に応じて店へ伝える方法を案内します。複合利用を想定していないフォームへ自由記入で押し込めないようにします。
入力と通知の内容を分ける
店頭受取と席予約で、送信後に誰へ何を知らせるかを表にします。下表は設計のたたき台です。どの項目が必須か、どの時間帯を選べるか、確認を誰が行うかは、実際の店で決めます。
表は左右にスクロールして確認できます。
| 確認する点 | 店頭受取の注文 | 店内の席予約 | 公開前の照合先 |
|---|---|---|---|
| 先に選ぶ利用方法 | 持ち帰りたい商品 | 店内で利用したい席 | メニューと営業時間 |
| 時刻の意味 | 商品の受取希望時刻 | 来店希望日時 | 厨房・ホールの受付枠 |
| 主な入力 | 商品、数量、受取名、連絡先 | 人数、日時、連絡先、必要な席条件 | 現行の注文票・予約台帳 |
| 店側の確認 | 調理と受渡しの可否 | 席と時間の可否 | 担当者と代行者 |
| 返信で示すこと | 注文の受付状態、受取場所、変更先 | 予約の受付状態、来店案内、変更先 | 自動返信と人手の確認文 |
アレルギーなど個別の食事相談を受ける場合は、店の実際の対応方針と確認担当を定めた上で、注文前に連絡する方法を示します。フォームの自由記入だけで対応可能と約束しません。受取の準備時間や席の確保も、送信直後に自動的に確定できるかどうかは店の運用次第です。自動返信は受付の事実、人手またはシステムによる確認は注文・予約の状態、と区別して文面を作ります。
通知先を分けるときは、誰が受けるかだけでなく、どの画面に記録が残るかを確認します。厨房に受取注文、ホールに席予約を通知しても、変更の連絡が共通メールにしか届かないなら、最初の分岐は途中で途切れます。受付番号や注文番号を使って、変更と元の依頼を結び付ける方法を決めます。個人の端末一台だけが通知を受ける運用なら、不在時の代行も必要です。
確認メールの件名にも利用方法を入れます。店側が多数の通知を一覧で見るとき、本文を開く前に店頭受取か席予約かが分かります。利用者向けにも「注文を受け付けました」「席予約の希望を受け付けました」のように状態を分け、まだ確定していないものを確定と書かないようにします。人手の確認が必要なら、確認後にどの方法で連絡するかを表示します。返信メールへそのまま変更を送れるのか、外部サービスで操作するのかも明示します。
外部サービスのリンクも役割を分ける
公式サイトから外部の注文・予約サービスへ進める場合、ボタンの名前と遷移先が一致しているか確認します。「店頭受取を注文する」を押して席予約サービスへ進む、または「席を予約する」から配達注文の一覧へ進む状態は避けます。外部側のページで店名、受取方法、予約種別がどう表示されるかを、公開前にスマートフォンで確かめます。
Google Business Profileの店舗リンクの案内では、予約、食品注文、受取・配達などの行動を別の種類のリンクとして扱います。利用可能な表示や機能は地域や事業によって変わるため、実際のプロフィール画面で確認します。公式サイトだけ分けても、検索結果のプロフィールから違うサービスへ送られるなら利用者は迷います。自社サイト、プロフィール、SNSの主要なリンクを同じ利用方法の名前で点検します。
外部サービスが在庫や席枠の正本なら、公式サイトへ古い空き状況を手入力で重ねない方がよい場合があります。公式サイトではメニュー、対象、受取場所、変更方法を説明し、確定できる枠は外部サービスで見せる分担です。反対に自社フォームを正本とするなら、外部サービスからの重複予約が起きないか確かめます。どちらが管理画面の正本かを、店の担当者が答えられる状態にします。
変更・キャンセルまで二つの経路で確認する
注文や席予約は、送信時だけで終わりません。受取時刻の変更、商品の変更、人数の変更、来店の遅れでは、店が見る担当と必要な対応が異なります。確認メールには、現在の状態、変更できる方法、連絡が必要な期限を、店が守れる内容で示します。具体的な締切は商品や営業日により異なり得るため、実際の運用を確認して掲載します。
キャンセルの案内も、一つの「お問い合わせ」へ戻すだけでは足りない場合があります。どの受付番号に関する連絡か、いつまでにどこへ伝えるか、外部サービスで操作する必要があるかを整理します。サイトと外部サービスで条件が食い違うなら、公開前に正本を決めます。急ぎの連絡をフォームだけで受けない店なら、電話の受付時間と対象の用件を示します。
営業時間外に届いた依頼は、店が確認できる時間を考慮します。「送信できた」と「店が確定した」を同一に扱わず、受付通知の文面を分けます。特に受取希望時刻までが短い場合、オンラインでは受けず電話で確認するなど、店が実行できる入口にします。Webの便利さを優先して、厨房やホールが確認できない約束を作らないことが大切です。
公開前に二つの操作を試す
公開前には、店頭受取の人、店内で食べたい人の順に、スマートフォンから実際の入口をたどります。どちらのボタンを押すか迷わないか、時刻の意味が分かるか、確認画面で利用方法と内容を見直せるかを試します。外部サービスへ進む場合は、その先の画面でも店名と目的が一致するか確認します。テスト送信は店側の通知と台帳へどう届くかまで見る必要があります。
テストでは、取り消しや変更の連絡も行います。受取注文の変更が席予約担当へ届く、席予約の人数変更が厨房の注文票に入る、といった混線がないか確認します。テストデータを実際の注文・予約と区別し、確認後に店の運用に沿って削除します。開店前後や繁忙時間帯に通知を見られる担当がいるかも、店の実態で判断します。
スマートフォンでは、入口のボタンが近くに並んでも押し間違えないかを確かめます。注文と席予約を色だけで区別せず、文字で利用方法を示します。入力途中で別の経路に切り替えたとき、先に入力した商品名や人数が違うフォームへ残らないかも試します。店側の台帳では、二つの依頼が同じ顧客名でも別件として記録されるか確認します。画面、通知、台帳を順にたどることで、入口だけ整って裏側で混ざる状態を見つけられます。
飲食店・カフェ向けサイト制作では、メニュー、営業情報、予約と持ち帰りの案内を整える相談ができます。既存の宿泊・飲食サイトの総合記事は多言語やアクセスなども扱います。本稿の判断材料は、店頭受取と席予約の二つの入口、入力、通知、変更先を分ける図と表です。
