この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
申込フォームを置くだけなら、Elementorのページにフォームを埋め込めばすぐに形になります。問題は、そのあとです。メール通知だけで受けていると、誰が申し込んだのか、希望日はいつか、対応済みなのかを毎回メールボックスから探すことになります。
この記事では、JetFormBuilderを入口にして、JetEngine側に申込データを残す流れを作ります。例にするのは、セミナー申込ページです。フォーム送信をきっかけに、WordPress内へ「申込1件」を保存し、Elementor側では案内ページと管理用一覧を分けて考えます。
JetFormBuilderは入力を受ける場所、JetEngineはその入力を管理できるデータに変える場所です。静的ページのまま申込を受けるより、申込を管理データとして残す方が、あとから確認しやすくなります。
JetFormBuilderの送信後アクションや、JetEngineのデータの箱（CPT）をまだ触ったことがない場合は、先に公式ページで全体像を見ておくと、この構成の役割分担がつかみやすいです。
この記事で分かること
- 申込フォームをメール通知だけで終わらせない考え方
- JetEngineで作る申込用のデータの箱と入力項目
- JetFormBuilderの送信後アクションで何を対応づけるか
- Elementor側で案内ページと管理用一覧を分ける理由
- 運用が楽になるところと、複雑にしすぎない境界
まず何を作るのか
今回作るのは、セミナー詳細ページに置く申込フォームと、その送信内容を保存する申込管理の仕組みです。ユーザーはフォームに名前、メール、希望日、人数、質問を入力します。送信後、管理者への通知メールを送りつつ、同じ内容をJetEngineで作った申込用のデータの箱へ保存します。
静的なElementorページだけで作る場合、ページ内にフォームを置いて終わりになりがちです。最初の数件ならそれでも困りません。ただ、開催日が複数ある、担当者が複数いる、あとで参加人数を確認したい、という段階になるとメールだけでは追いにくくなります。
ここで考えるべきなのは、フォームそのものの見た目ではなく、送信後にどこへ情報を置くかです。入力を受ける場所と、管理する場所を分けると、後から一覧化したり、対応状況で絞り込んだりしやすくなります。
JetEngineでどのデータを持たせるのか
先に、申込を保存するデータの箱（CPT）を作ります。ここでは公開記事として見せるためではなく、管理者が確認する記録として使います。サンプルの設定は次の通りです。
| 設定 | 値の例 | 考え方 |
|---|---|---|
| データの箱 | seminar_entry |
セミナー申込だけを入れる箱 |
| 管理画面ラベル | セミナー申込 | 担当者が迷わない名前にする |
| 表示目的 | 管理用 | 一般公開ページに直接出さない |
| タイトル | seminar_title + applicant_name |
一覧で誰の申込か分かるようにする |
入力項目は、後から探したい単位で分けます。1つの自由入力欄にまとめると簡単そうに見えますが、希望日別に見る、人数で確認する、未対応だけ見る、といった運用がしにくくなります。
| 入力項目 | フィールド名 | 型 | サンプル値 |
|---|---|---|---|
| お名前 | applicant_name |
Text | 佐藤 花子 |
| メール | applicant_email |
Text | sample@example.com |
| 希望日 | preferred_date |
Date | 2026-06-20 |
| 参加人数 | participant_count |
Number | 2 |
| 対象講座 | seminar_name |
Select | Elementor実践講座 |
| 対応状況 | entry_status |
Select | 未対応 / 確認中 / 対応済み |
| 連絡メモ | message |
Textarea | 事前質問など |
対応状況は、ユーザーに入力してもらう項目ではありません。管理者が後で変更する項目です。このように、フォームに出す入力項目と、管理用に持つ入力項目は同じではありません。ここは少し迷いやすいです。
JetFormBuilder側でフォームを作る
JetFormBuilder側では、申込者が入力する項目だけを作ります。お名前、メール、希望日、参加人数、質問、同意チェック。ここでは対応状況を出しません。対応状況は管理者用なので、送信時の初期値として「未対応」を入れる方が自然です。
フォームの項目名は、JetEngine側のフィールド名と近づけておくと設定が楽です。完全一致でなくても対応づけはできますが、最初は applicant_name のように同じ名前にしておくと、送信後アクションの画面で迷いにくくなります。
送信後アクションでは、少なくとも次の3つを考えます。
公式ドキュメントでも、送信後アクションはフォーム送信後に実行する処理として説明されています。投稿を追加・更新するアクションでは、フォームの値を投稿のフィールドへ対応づけられます。今回なら、保存先のデータの箱は seminar_entry です。
Elementor側ではどう表示するのか
Elementor側では、1つの画面に全部を詰め込まない方が分かりやすいです。公開側のセミナー詳細ページには、講座説明と申込フォームだけを置きます。管理者用の一覧ページ、またはWordPress管理画面では、申込データを一覧で確認します。
公開ページの構成例は次のようにします。
- 講座タイトル
- 開催日、対象者、料金
- 申込フォーム
- 送信後の案内文
管理用一覧では、1件のカードに「お名前」「希望日」「人数」「対応状況」を出します。JetEngineの一覧テンプレート（Listing）を使う場合は、1件分の見た目を作り、それを一覧表示に流し込みます。同じレイアウトを何度も手で複製しないのが、静的ページから進むポイントです。
運用すると何が楽になるのか
この構成にすると、フォーム送信後の確認作業が少し整います。メールだけを見るのではなく、申込データの一覧から「未対応だけ見る」「希望日で並べる」「対応済みに変える」といった確認ができます。
たとえば、管理用一覧の表示条件を次のように考えます。
- Query Builder相当の条件:
entry_status = 未対応 - 並び順:
preferred_date ASC - カード内表示: 名前、希望日、人数、メール、対応状況
- 詳細ページ: 連絡メモと送信日時を確認
申込数が少ないうちは、WordPress管理画面だけでも十分です。担当者が管理用ページで見たい、日付別に見たい、一覧カードの見た目を整えたい、という段階でElementorの一覧表示を足すと無理がありません。
実際の管理画面ではどう使うか
申込データを作っただけでは、まだ運用は楽になりません。担当者が毎日見る画面で、必要な情報だけを素早く確認できる形にしておく必要があります。最初に作るなら、WordPress管理画面の一覧と、Elementorで作る簡易的な管理用一覧のどちらかで十分です。両方を最初から作ると、確認場所が増えて逆に迷います。
WordPress管理画面で使う場合は、投稿タイトルを見ただけで内容が分かるようにします。たとえば 2026-06-20 / 佐藤花子 / 2名 のようなタイトルです。本文やメモ欄を開かなくても、希望日と申込者が分かります。ここを「申込」だけにしてしまうと、一覧に同じ名前の投稿が並び、後から探すのが大変です。
Elementorで管理用一覧を作る場合は、一般ユーザーに見せるページとは分けます。ログイン中の管理者だけが見られるページにし、カードには次のような情報を置きます。
- 左上: 希望日
- 中央: 申込者名と参加人数
- 下部: メールアドレスと連絡メモの一部
- 右上: 対応状況のラベル
- ボタン: 詳細確認または管理画面へのリンク
この一覧は見た目を作り込むより、担当者が「今日見るべき申込」を見つけられることを優先します。カードにすべての情報を詰め込むと読みにくくなります。詳細な質問や長いメモは、詳細画面または管理画面で確認すれば十分です。
送信後アクションで間違えやすいところ
一番多いミスは、フォーム項目と保存先フィールドの対応づけがずれることです。画面上では送信が成功しているように見えても、保存先のフィールド名が違うと、申込データの一部が空になります。最初のテストでは、1件だけ送信して終わらせず、管理画面を開いて各入力項目に値が入っているか確認します。
次に気をつけたいのは、メール通知とデータ保存の順番です。通知メールだけ成功して、データ保存に失敗していると、担当者はメールには気づくものの、一覧には申込が出てきません。逆に、データは保存されているのに通知メールが届かない場合もあります。テストでは、メールと保存の両方を別々に確認するのが大切です。
また、同意チェックの扱いも軽く見ない方がいいです。個人情報を保存するなら、フォーム内に同意チェックを置き、プライバシーポリシーへの導線を明示します。JetFormBuilderの入力項目として同意を受けるだけでなく、保存するデータの中にも同意日時や同意状態を残すかを検討します。小さなサイトでも、ここを曖昧にしない方が後で説明しやすいです。
小さく始めるための初期構成
最初の構成は、かなり絞って構いません。申込CPT、基本の入力項目、管理者通知、申込者控えメール、未対応一覧。この5つが動けば、フォーム送信から管理までの流れは確認できます。日程別の絞り込み、担当者別表示、講座データとの関連づけは、運用で必要だと分かってから足す方が安全です。
講座自体もJetEngineで管理している場合は、申込データと講座データを関連づけると便利です。たとえば、講座CPTを seminar、申込CPTを seminar_entry として、1つの講座に複数の申込が紐づく関係にします。関係の向きは「講座から申込を見る」方を基本にすると、講座詳細から申込一覧を確認しやすくなります。
ただし、最初から関連づけまで入れると設定項目が増えます。セミナー数が少ない段階なら、フォームの選択肢に講座名を入れるだけでも運用できます。大事なのは、将来の理想形を全部先に作ることではなく、今の申込管理で本当に見る項目を選ぶことです。
静的Elementorページとの違い
静的ページでは、申込フォームの見た目と説明文を手で整えることが中心です。ページを1枚作るだけなら速いです。けれども、申込データそのものはページの外に流れていきます。メール、スプレッドシート、担当者のメモなどに分かれやすく、後から状態を揃えるのが面倒になります。
JetEngineを挟むと、申込データをWordPressの中に置けます。Elementorは、そのデータを見せる画面を作る役割になります。つまり、ページ作成の延長でありながら、裏側ではデータ管理の考え方が入ってきます。ここが静的LPとの大きな違いです。
この違いを理解せずに作り始めると、フォームの見た目だけは整っているのに、運用時に誰も一覧を見ない、対応状況が更新されない、同じ申込が重複しても気づかない、という状態になりがちです。見た目を作る前に、担当者がどの画面を見て、どのタイミングで状態を変えるのかを決めておきます。
もう1つ大事なのは、あとから削除しにくい項目を軽い気持ちで増やさないことです。入力項目が多いほどフォームは長くなり、保存する個人情報も増えます。担当者が見ない項目なら、最初は入れない判断も必要です。申込者にとっても、入力が短い方が迷いません。運用側が本当に確認する情報だけに絞ると、JetEngine側の管理画面も扱いやすくなります。月に数件の申込なら、細かなステータスや担当者欄を増やすより、未対応と対応済みの2段階だけで十分なこともあります。小さく始めるほど、あとで直しやすいです。
どこから複雑になりすぎるのか
申込管理は、便利にしようと思えばどんどん広げられます。会員登録、決済、予約枠、担当者ごとの権限、メール配信、キャンセル処理まで入れたくなるかもしれません。ただ、最初から全部をJetEngineとJetFormBuilderだけで抱え込むのはおすすめしません。
特に、個人情報を扱う場合は慎重にした方がいいです。保存する項目を最小限にし、誰が見られるのか、どのくらい保管するのか、削除依頼が来たらどうするのかを決めておきます。JetEngineやCrocoblockは、セキュリティ設計や運用ルールの代わりにはなりません。
また、申込数が多いサイトでは、一覧表示や条件検索の作り方で表示速度に差が出ます。最初は「申込を保存する」「未対応だけ見る」程度に絞り、必要になってから検索条件や担当者別ページを足す方が失敗しにくいです。
この構成が向いている人・向いていない人
向いているのは、Elementorで案内ページは作れるけれど、申込後の管理をメールだけにしたくない人です。セミナー、相談会、掲載申請、資料請求のように、送信後に人が確認する業務と相性が良いです。
逆に、複雑な予約在庫、決済、会員権限、外部CRM連携まで最初から必要な場合は、専用サービスや個別開発も含めて設計した方が安全です。JetFormBuilderとJetEngineで入口を作れるとしても、業務全体の責任まで自動で解決されるわけではありません。
まとめ
JetFormBuilderとJetEngineを組み合わせると、フォーム送信を単なるメール通知で終わらせず、WordPress内で確認できる申込データに変えられます。ポイントは、最初にデータの箱と入力項目を決め、フォーム項目を送信後アクションで対応づけ、Elementor側では公開ページと管理用一覧を分けることです。
まずは、申込者名、メール、希望日、人数、対応状況くらいの小さな構成から始めるのが現実的です。必要になったら、講座データとの関連づけや担当者別の一覧へ広げていけば十分です。
