この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
予約サイトを作りたいとき、最初に決めるべきなのはカレンダーの見た目ではありません。どのサービスを予約対象にするのか、所要時間や担当者をどこで管理するのか、予約が入ったあとに誰が何を確認するのか。この順番を外すと、Elementorで画面はきれいに作れても、あとから運用が苦しくなります。
この記事では、JetEngineを中心に「小さな相談予約サイト」を作る前提で全体像を整理します。サービス紹介ページはElementorで作り、サービスのデータはJetEngineに持たせ、実際の予約受付は予約用の部品としてJetBookingや申し込みフォーム（JetFormBuilder）につなぐ考え方です。JetEngineだけで予約業務のすべてを置き換える話ではなく、予約対象のデータ設計を整える話として読んでください。
たとえば、個別相談、初回ヒアリング、Zoom相談、来店相談のようなサービスを複数持つサイトです。静的なElementorページなら、各ページに料金や所要時間を手入力できます。ただ、料金変更や受付停止が起きるたびに複数ページを直すことになります。ここが少し面倒です。
この記事で分かること
- 予約サイトでJetEngineに持たせるデータの考え方
- サービスCPT、担当者、予約フォームを分けて設計する理由
- Elementor側でサービス詳細ページと一覧を表示する流れ
- Query Builderや表示条件で受付中だけ案内する例
- 予約機能が複雑になりすぎる境界線
まず作るのは小さな相談予約サイト
今回のサンプルは、1社のサイト内に「相談メニュー」を作り、各メニューから予約フォームへ進める構成です。データの箱（CPT）は service、管理画面の表示名は「相談サービス」とします。1件の投稿が1つの予約対象です。
入力項目としては、サービス名、所要時間、料金、対応方法、担当者、予約受付状態、予約フォームURLを分けます。ここで全部を本文欄に書いてしまうと、一覧で並べ替えたり、受付中だけ表示したり、料金だけをカードに出したりするのが難しくなります。最初は面倒に見えても、項目を分ける方が後で楽です。
| 管理する内容 | フィールド名 | 型 | サンプル値 | 使い道 |
|---|---|---|---|---|
| 所要時間 | duration_minutes |
Number | 60 | 一覧カード、予約前の確認 |
| 料金 | price |
Number | 11000 | 料金表示、並び替え |
| 対応方法 | method |
Select | online / visit | 絞り込み、ラベル表示 |
| 担当者 | staff_name |
Text | 山田 | 詳細ページに表示 |
| 受付状態 | accept_booking |
Switcher | true | 予約ボタンの表示条件 |
| 予約フォームURL | booking_url |
URL | /booking/first | 予約ボタンのリンク先 |
ここで迷いやすいのは、担当者をテキストで持つか、担当者用のデータの箱を別に作るかです。担当者が1人か2人なら、最初はテキストでも十分です。担当者別プロフィール、担当者別空き枠、担当者別通知まで必要になった時点で、担当者CPTや関係づけを考えた方が自然です。
JetEngineは予約対象のデータを整える中心にする
JetEngineの役割は、予約そのものの決済や空き枠管理を全部背負うことではありません。今回の構成では、JetEngineは「予約対象となるサービス情報をWordPress内で扱いやすくする中心」です。サービスをCPTとして作り、入力項目を分け、一覧テンプレートで表示し、条件に合うものだけを出します。
予約受付の実処理が必要なら、日付選択や予約記録を扱う予約用プラグイン、または申し込みフォームを使います。Crocoblock内で考えるなら、予約エンジン側はJetBooking、フォーム送信側はJetFormBuilderが候補です。読者が最初に覚えるべきなのは名前の羅列ではなく、JetEngineはサービス情報、予約プラグインは空き枠と送信処理という分担です。
公式ドキュメントでも、JetEngineはCPT、入力項目、一覧、Query Builder、表示条件などの動的コンテンツ機能を持つプラグインとして説明されています。JetBooking側は、予約フォーム、予約データ、カレンダー表示、Plain modeやWooCommerce連携など、予約受付に寄った領域を扱います。ここを混ぜて考えると、設定画面を開いた瞬間に少し迷います。
Elementor側では詳細ページと一覧を分ける
Elementorでは、まず1件の相談サービスを表示する詳細ページを作ります。サービス名、料金、所要時間、対応方法、担当者をDynamic Fieldで読み込み、予約フォームURLをDynamic Linkのボタンに入れる形です。見た目はElementorで作り、値だけJetEngineから差し込む、と考えると分かりやすいです。
一覧ページでは、Listing Itemを作って、サービスカードを1枚設計します。カード内には「オンライン相談」「60分」「11,000円」のような短い情報を出し、詳細を見るボタンを置きます。Listing Gridでこのカードを並べれば、サービスが増えても同じデザインで表示できます。
静的ページとの違いは、更新場所が1つになることです。料金が変わったらサービス投稿の price を直す。受付停止なら accept_booking をオフにする。Elementorのページを何枚も開いて直すより、管理画面の作業が読みやすくなります。ただし、項目名を途中で変えると表示側の参照も直す必要があるので、最初にフィールド名を雑に決めない方がいいです。
受付中だけ予約ボタンを出す
実務でよくあるのが、「ページは残したいけれど、予約ボタンだけ一時的に消したい」という状態です。たとえば受付枠が埋まった、担当者が休み、キャンペーンだけ終了した、という場面です。このときサービス投稿に accept_booking を持たせておくと、Elementor側の表示条件でボタンを出し分けやすくなります。
設定としては、予約ボタンのウィジェットに表示条件（Dynamic Visibility）を設定し、accept_booking が true のときだけ表示します。受付停止時には、代わりに「現在受付を停止しています」という短いテキストを出すのもありです。ここで予約ページそのものを削除してしまうと、検索流入や内部リンクが切れるので、停止表示にした方が扱いやすい場合があります。
Query Builderを使うなら、一覧側でも accept_booking = true のサービスだけを表示できます。さらに method = online のような条件を足せば、オンライン対応の相談だけを出すページも作れます。ただ、条件を増やしすぎると、なぜ表示されないのかを追いにくくなります。最初は受付状態と対応方法くらいに絞るのが無難です。
実装順は画面よりデータから決める
予約サイトを作るとき、先にElementorでトップページや予約ページの見た目を作りたくなります。気持ちは分かります。ただ、予約対象のデータが決まっていない状態で画面から作ると、あとで「このボタンはどのサービスの予約に進むのか」「この料金はどこを直せば変わるのか」が曖昧になります。
おすすめの順番は、まず service の入力項目を作ることです。次にテスト用のサービス投稿を3件だけ入れます。例として「初回相談 60分」「オンライン相談 30分」「来店相談 90分」のように、料金、対応方法、受付状態を少し変えて登録します。そのあとでListing Itemを作ると、カードの中に必要な項目が自然に見えてきます。
ここで1件だけのサンプルで確認すると、表示条件のミスに気づきにくいです。受付中と停止中、オンラインと来店、料金ありと無料相談のように、状態が違うデータを最低3件用意しておくと、一覧や詳細ページの挙動を見やすくなります。小さなことですが、後半の手戻りを減らせます。
予約フォームへつなぐときの考え方
予約受付まで作る場合、フォーム側で最低限必要になるのは、サービスID、希望日、氏名、メールアドレス、連絡事項です。JetFormBuilderを使うなら、送信後アクションでメール通知や投稿作成を設定できます。JetBookingを使うなら、予約対象や予約フォーム、空き状況の扱いを公式手順に沿って設定します。
ここで気をつけたいのは、フォームの項目を増やしすぎないことです。初回相談なのに住所、会社規模、予算、複数ファイル、細かい希望時間まで全部聞くと、入力する側も運用する側も重くなります。まずは予約成立に必要な項目だけにして、詳細ヒアリングは予約後のメールや別フォームに分ける方が扱いやすいです。
運用フローは次のように置くと、作業の抜けが見えやすくなります。
管理画面では、誰がどの項目を更新するのかも決めておきます。料金は管理者だけ、受付状態は現場担当も変更可能、本文説明は制作担当が確認する、というように分けると運用しやすいです。WordPressの権限設定や運用ルールを曖昧にしたまま、複数人で予約情報を触るのは少し危ないです。
また、予約URLをサービス投稿に直接入れる場合、URLの変更に注意します。フォームを作り直したとき、古い予約URLが残っていると、サービスページから古いフォームへ進んでしまいます。フォーム側のスラッグをなるべく変えない、変更したらサービス投稿の booking_url をチェックする、という小さな確認手順を作っておくと安心です。
運用すると何が楽になるのか
JetEngineでサービス情報を分けておくと、日々の更新はかなり単純になります。新しい相談メニューを追加したいときは、固定ページを複製するのではなく、相談サービスを1件追加します。料金変更も入力項目を直すだけです。受付停止もスイッチで管理できます。
さらに、一覧の並び替えや表示条件も作りやすくなります。たとえば price の安い順、duration_minutes の短い順、method が online のものだけ、といった見せ方です。静的Elementorページでは、このあたりを手作業で並び替えることになります。小さなサイトなら手作業でも構いませんが、サービスが10件を超えるとミスが出やすいです。
もう一つの利点は、予約サイトを閉じずに内容を調整できることです。たとえば繁忙期だけ新規受付を止めたい場合、サービス投稿の受付状態をオフにして、詳細ページには説明文を残せます。料金改定前の案内も、公開日や本文メモを分けておけば、ページ全体を非公開にせず調整できます。こういう細かい更新は、静的ページだけで管理していると意外と散らかります。
ただし、データ化したからといって、全部を自動化する必要はありません。予約確定の連絡や日程変更は、最初は手動メールでも十分な場合があります。最初から自動返信、リマインド、キャンセルリンク、決済まで一気に入れると、テスト項目が急に増えます。まずは「サービス情報を一元管理し、予約フォームへ迷わず進める」くらいで区切るのが現実的です。
逆に、ここから先は慎重にした方がいい
予約サイトは、見た目よりも業務ルールが複雑です。キャンセル期限、担当者ごとの休日、複数枠、同時予約、オンライン決済、リマインドメール、顧客情報の保管、個人情報の削除依頼。ここまで入ると、JetEngineのデータ設計だけではなく、予約専用の仕組み、セキュリティ設計、運用ルールが必要になります。
特に個人情報を扱う予約フォームでは、必要以上の情報を集めないこと、通知メールに機密情報を詰め込みすぎないこと、管理画面の閲覧権限を分けることが大切です。プラグインを入れれば安全になる、という話ではありません。公式プラグインを使い、ライセンスとアップデートを維持し、テスト環境で変更を確認するのが前提です。
この構成が向いている人、向いていない人
向いているのは、まず小さく予約導線を作りたいElementorユーザーです。相談サービスやレッスンメニューを複数持っていて、料金や受付状態を管理画面で直したい人には分かりやすい構成です。静的ページから一歩進めるには、サービスCPTを作るだけでも効果があります。
向いていないのは、最初から本格的な予約システムを作り込みたいケースです。空き枠管理、決済、キャンセル、会員連携、スタッフごとの権限まで一気に必要なら、JetEngine中心というより、予約機能全体の設計から入るべきです。ここを曖昧にしたまま進めると、あとで「どこに予約情報があるのか」が分からなくなります。
まとめ
JetEngine中心で予約サイトを考えるなら、まず予約対象となるサービスをデータ化します。今回の例では、service というデータの箱を作り、料金、所要時間、対応方法、担当者、受付状態、予約フォームURLを分けました。Elementor側では詳細ページと一覧カードを作り、予約ボタンや停止メッセージを条件で出し分けます。
運用面では、料金変更、受付停止、新サービス追加が管理画面で扱いやすくなります。一方で、空き枠、決済、個人情報、キャンセル処理まで含めるなら、JetBookingやJetFormBuilder、場合によっては別の予約専用システムとの役割分担が必要です。最初は小さく作り、複雑な予約業務をいきなり全部WordPressに押し込まないことが大事です。
