講座の日程変更を受け付ける｜変更先の空席と受付番号を照合する

変更受付と変更確定を分ける

土曜午前の工作教室を予約した２人が日曜午後へ変更する例で考えます。変更フォームを受け付けた瞬間に元の予約を削除すると、移動先が満席だった場合に両方の席を失います。申込台帳はそのまま残し、変更依頼を別行へ保存してください。状態は未確認、空席確認中、承認済み、反映済み、見送りに分けます。参加者へ最初に返す案内も「変更依頼を受け付けた」とし、新しい日程が確定したとは伝えません。単なる連絡先修正とは異なり、２回分の定員が変わる処理です。

受付番号と人数を照合する

変更フォームには元の受付番号、予約時の連絡先、変更希望回、変更人数を置きます。氏名だけでは同姓や表記ゆれがあるため照合しません。台帳側には元の回ID、移動先の回ID、人数、確認担当、確認日時、適用日時を保持します。入力された人数が元の予約を超えた場合や、一部だけ移動する場合は自動更新せず担当者へ回します。Tallyの必須設定や条件分岐は入力漏れを減らせますが、別台帳にある予約と一致することまで証明する仕組みではありません。

空席は申込数と仮押さえを合わせて数える

日曜の定員を12人、確定を９人、別の変更依頼による仮押さえを２人とすると、残りは１人です。２人の変更をそのまま承認してはいけません。この数字は説明用の例です。日付の表示名ではなく回IDで集計し、取消済みや期限切れの仮押さえを除きます。少人数なら担当者１人が台帳を確認して承認する運用が簡単です。複数人が同時に最終席を割り当てる規模では、フォームと一覧の組合せだけで同時更新を防げると考えず、予約専用の仕組みも比較します。

反映の順序と途中の失敗を決める

承認後は移動先の仮押さえ、元予約の変更記録、新しい回への紐付け、元の席の解放、案内の送信という順序を決めます。どこまで済んだかを依頼IDで残し、失敗した処理だけを確認します。変更済みなのにメールだけ失敗した場合は、もう一度席を移すのではなく案内の再送へ進みます。反対に空席を取れなかった場合は元予約を保持します。Airtableの自動化は起点と更新対象を明確にし、完了フラグの更新が同じ処理を再び起動しないかも確認してください。

変更期限と参加者向けの案内を揃える

「開催前日まで」のような表記だけでは時刻が曖昧です。主催者が決めた変更期限を日付、時刻、タイムゾーンで示し、当日変更や差額がある場合の窓口を分けます。これは変更条件を設計する例であり、特定の返金義務や契約条件を示すものではありません。確定案内には新しい回の日時と会場、人数、元の予約がどうなったかを含めます。参加者のメール返信が来ない場合に備え、連絡待ち一覧と期限も用意しておくと、仮押さえが無期限に残るのを防げます。

少ない件数では手動確認を残す

月に数件の変更なら、既存のフォームと台帳を使い、確認担当が承認するだけでも運用できます。Makeを追加する前に、入力項目の抜け、担当者の不在、期限切れ仮押さえの見落としを減らしてください。費用はフォームの通知機能、台帳の共同編集人数、自動化の実行量で変わります。自動化するとしても最初は依頼の登録と担当者通知までにし、席を動かす判断は人が行う構成が始めやすいです。料金記事では必要な機能がどのプランに含まれるかを確認します。

本番前に試す変更パターン

空席あり、満席、同じ回への変更、期限後、受付番号不明、同じ依頼の再送、グループの一部変更を試します。成功時だけでなく、元予約の保持と仮押さえの解除も確認してください。検証用の架空データで、適用済みの依頼を再度処理しても人数が変わらないことを見ます。最後に元の回、新しい回、参加者向けメールの３つを突き合わせます。申込み自体の設計は講座受付の記事、単純な登録修正は変更受付の記事、補欠からの繰り上げは待機列の記事へ進むと、それぞれの役割を混同せずに組み立てられます。

• Tallyで登録内容の変更を受け付ける｜照合番号と確認後の更新
• Tallyで講座の参加申込みを受け付ける｜希望回・人数・受付後の確認
• Makeでイベントの受付と補欠を分ける｜定員判定と繰り上げの手順