WordPress予約プラグイン比較：Amelia・Bookly・Booking Calendar

相談・レッスン・サービスの予約ならAmeliaとBooklyを、日付や時間枠の空き状況と申込を管理するならBooking Calendarを比較しましょう。見た目より、担当者・設備の重複防止、確定・決済の条件と無料版の範囲が重要です。Booking Calendarも時間枠予約に対応しており、日単位専用ではありません。

問い合わせフォームでは足りない場合

問い合わせフォームは希望時間を受け付けられますが、担当者や部屋が空いていることまでは保証しません。予約プラグインは予約可能な時間・日付・設備を提示し、予約状態に応じて空き状況を管理します。一枠一名の相談と、定員まで複数人を受け入れる講座では必要な制御が異なります。

最初に予約単位と、実際に数が限られる対象を決めます。講師の45分相談は担当者の時間、定員8名の授業は参加枠、宿泊は客室と日付が基準です。講師二人が一つの会議室を使うなら、講師別の予定だけでは部屋の重複を防げません。人と設備を同時に管理する必要があるか確認してください。

候補と無料・有料の範囲を比較する

表は各製品の配布案内、Amelia、Bookly、Booking Calendarを基に比較しています。製品全体のデモで見た機能が無料版にすべて含まれるわけではありません。必要な項目を、導入する版と購入予定のライセンスに一つずつ照合してください。

SMS・WhatsAppの送信料、決済手数料、外部サービス料金はライセンスとは別の場合があります。Squareなどの決済サービスも運営国・通貨・事業条件に対応している必要があります。無料で連携できることと、決済事業者の処理手数料が無料であることは別です。

Amelia：担当者・サービス・フォームをつなぐ

Ameliaの開始ガイドは、担当者一名、サービス一つ、予約フォームから始める流れです。Amelia → Employeesで担当者と勤務時間を設定し、カテゴリーとサービスを作って担当者を割り当てます。サービス管理は文書や版によってCatalogまたはServicesと表示されるため、導入した画面の該当項目を使います。

1. 担当者の氏名・メールアドレス、勤務時間と休日を設定します。初期値の平日勤務時間を実際の営業に合わせて変更してください。
2. サービス名・カテゴリー・担当者・所要時間・料金を設定します。フォームに出ない場合は、担当者とサービスのShow on websiteも確認します。
3. 予約ページへAmeliaブロックや対応する段階式フォームを配置します。例えば[ameliastepbooking]を使えますが、その版で利用できるフォームを確認してください。
4. 未ログインの画面から予約し、Amelia → Bookings → Appointmentsで日付・担当者・状態を照合します。承認・変更・取消も試します。

General settingsのDefault time slot stepは、設定したい所要時間に対応している必要があります。45分の相談と15分の余裕を設定したいのに30分刻みしか選べない場合は、この基本間隔を確認します。担当者別タイムゾーンと顧客の現地時間表示は別機能であり、必要なプランも分けて確認してください。

Bookly：サービスの割り当てと個別勤務時間を確認する

Bookly無料版では小規模な予約の流れを検討できます。オンライン決済、複数担当者や多くのサービス、高度な予約条件には、Proと購入経路ごとのプラン・追加機能を照合します。現在の料金プランと個別アドオンの案内が併存しているため、購入する構成に必要な機能が含まれるか確認しましょう。

Bookly → Servicesでカテゴリーとサービスを作り、担当者を割り当てます。サービスの文書では、カテゴリーへの所属と少なくとも一名の担当者がフォーム表示に必要とされています。料金を入力してもオンライン決済が自動設定されるわけではありません。現地払いとオンライン払いは別の流れです。

個別の勤務予定はStaff Members → 対象者 → Schedule / Days Offで確認します。勤務時間の案内によると、会社全体のBusiness Hours・Holidaysは新しく作る担当者の初期値であり、既存担当者の予定までは自動変更しません。「営業時間を直したのに予約可能時間が変わらない」場合は個別設定も見てください。

Booking Calendar：空き表示と申込フォームを区別する

Booking Calendar無料版でも終日・時間枠予約、通知、管理者承認などの基本操作を構成できます。客室・設備ごとに別のカレンダーを持つには複数資源に対応する版を、決済・季節料金・定員などは該当する上位版を確認します。二つの客室を色分けするだけでは、在庫が別々に管理されるとは限りません。

設定ウィザードとWP Booking Calendar → Settingsで日付・時間選択、フォーム、通知を設定し、ページへBooking Calendarブロックか管理画面が生成したショートコードを配置します。配置ガイドのとおり、空き状況だけを表示する方式と予約フォームを含める方式は異なります。カレンダーは見えるのに申し込めない場合は、ここから確認しましょう。

承認待ちの申込が時間を確保するかも重要です。公式FAQには、承認待ちの日を空きとして扱い、一件を承認するまで同じ日の申込を複数受け付ける構成も説明されています。先着で確定する運用なら、別々の二つのセッションで確認してください。複数の希望を集めて選ぶ運用と重複予約を防ぐ運用では設定が異なります。

タイムゾーン・準備時間・外部カレンダー

WordPressの設定 → 一般 → タイムゾーンを確認します。夏時間がある地域は、固定UTC差より都市名のタイムゾーンを使うと季節変動に対応できます。顧客の現地時間で表示する場合は、予約画面・確認メール・管理者の予定が同じ時点を指すか比較してください。海外の利用者と日付がずれる場合は時間帯名も明示します。

サービスの所要時間は顧客へ提供する時間であり、前後の準備・片付け時間は別の予約を入れられない時間です。下図は開始前の余裕を設けず、09:00から45分の相談と終了後15分を合わせ、次の予約を10:00から受ける概念例です。実際の開始可能時刻は勤務時間、枠の刻みと前後の余裕設定によって変わります。Ameliaの所要時間・余裕設定やBooklyのPadding timeなど、必要機能の提供版も確認してください。

一度だけ予定を追加するボタン、定期的に読むiCalendar（.ics）フィード、外部の予定で埋まった時間まで調べる同期は別の仕組みです。.icsを接続しただけで即時・双方向になるとは限りません。外部にテスト予定を作り、予約枠がいつ閉じ、取消後いつ戻るかを確かめます。同じ設備を別サイトでも販売する場合は同期遅延中の重複リスクも判断してください。

受付・確定・決済を分けて試す

次の項目は実際に運営するサイトで確認する基準です。製品デモを見ただけで、自分の構成でも検証済みとはいえません。

1. 受付：一つのサービスと担当者・設備で始め、通常時間、休日、終了間際を試します。利用者側と管理側の日付・時間・定員が一致する必要があります。
2. 同時申込：二つのブラウザーセッションで同じ枠を開きます。二件目が拒否されるのか、承認待ちになるのか、定員まで受け入れるのかを運営条件と照合します。
3. 決済状態：決済事業者のテストモードで成功・失敗・途中離脱を確認します。支払い前に確定するのか、未決済の枠がいつ解放されるかも確認します。自動取消機能が標準で有効とは考えないでください。
4. 取消・変更：利用者の変更期限、管理者変更、旧枠の解放と新枠の確保を確認します。予約取消が返金まで行うとは限らないため、決済記録も照合します。
5. 通知：受付・承認・変更・取消のメールが正しい状態と時間帯で届くか確認します。訪問者が少ない場合も、予約前の通知が予定どおり動く必要があります。

予約記録があるのにメールが届かない場合は、再予約する前に送信処理と実際の受信を分けて調べます。空きが更新されない、セキュリティチェックに失敗する場合は、テスト環境でキャッシュやスクリプト最適化の影響を確認してください。動的な予約・決済応答を古いキャッシュで置き換えない構成が必要です。

導入・更新前にはファイルとデータベースをバックアップします。既存予約を日付・時間帯・状態・決済識別子とともに書き出せるか確認し、移行中の新規申込が二つのシステムへ分散しないように経路を決めます。テストサイトから実際の顧客通知や請求が出ないよう分離してください。問題時には受付を一時停止し、既存予約一覧を基に案内と復旧を進められるようにします。