Makeでイベントの受付と補欠を分ける｜定員判定と繰り上げの手順

完成するものと対象範囲

講座の参加申込みを受け付け、定員内の候補と補欠候補を管理表へ分けます。フォーム送信直後の受領通知と、席が確保された確定通知は分けます。単純な表の行数だけで同時申込みの席を保証する構成にはせず、最終確定の担当者を決めます。

定員は回答数ではなく参加人数で扱います。同行者を含む一回答が三席を使う場合、表の行数と座席数は一致しません。講師用の席、運営者用の席、車椅子等に関する会場側の制約も、販売できる人数と分けて定義します。募集開始後に定員を変更すると既存の案内へ影響するため、変更者、変更理由、対象開催回を履歴へ残し、未確定の案内を先に照合します。

項目と保存先を準備する

入力と保存先に用意する項目は、申込ID、開催回ID、申込日時、参加人数、確認状態、補欠順、確定通知日時です。元の値と担当者が確認した値は区別し、同じ名前の列を別の意味へ使い回さないようにします。実運用の情報を入れる前に、練習用の識別子で一件を作成し、必要な担当者だけが参照・編集できる保存先を選びます。

補欠の順番は受信時刻だけでなく、組単位の扱い、回答期限、連絡がつかない場合の規則を運営側で決めます。自動化はその規則を実行する補助にします。新たな申込みが入るたびに補欠順位を全員へ送り直すと、順位が席の保証だと誤解されやすくなります。まずは運営表で順位を確認し、実際の案内が必要な候補だけへ連絡する構成にします。

設定を順に進める

開催回ごとの定員と締切を別の表に持ちます。Makeは新しい申込みを受けたら申込IDで重複を確認し、人数が空欄・ゼロ・上限超過なら要確認にします。同じメールアドレスでも別開催回の申込みは別件として扱います。

開催回の既存確定人数を取得し、残席と申込人数を比べて候補を分けます。この判定は仮の振り分けとして記録し、受領メールには確定前であることを表示します。複数人の一組を分割するかどうかも、先に運営規則を決めます。

取消で空席が出たら補欠の受信順を見て、対象者に回答期限付きの案内を出します。承諾後に確定人数へ反映し、期限切れなら次の候補へ進めます。案内中を確定済みと混ぜず、運営者が現在の保留人数を確認できる表にします。

少数のデータで確かめる

定員八人、確定六人の開催回に三人組が申し込む例では、残席二人だから自動確定しません。一組を分けない規則なら補欠候補に置きます。一人の取消後に三人分が空いた場合も、先に案内済みの申込みがないか確認してから繰り上げます。

運用中の変更を扱う

参加費の支払いを追加する場合は、入金済みと参加確定の状態を別に設けます。支払リンクを送っただけで入金済みにしたり、返金予定の人を自動で参加者へ戻したりしません。練習では同時刻の二件、締切直後の申込み、連絡期限切れ、二重送信を含めます。どの申込みが何席を使うかを説明できない状態なら、確定メールを送らず運営担当の確認へ止めます。

費用と利用量を見積もる

受付の費用は申込み件数、定員確認の検索、通知、補欠の案内、取消の反映で見積もります。開催回が増えるほど確認先や例外も増えるため、一回分の練習から全月の費用をそのまま推測しません。確定を人が確認する運用では確認時間も含め、即時予約が必要なら専用予約サービスの契約と比べます。利用枠の上限や通知の送信制限も公開前に確認します。

不具合が出たときの確認

二つの申込みが同時に届いた場合、どちらも同じ残席を見る可能性があります。Makeの実行順だけで解決できると思い込まず、確定前の照合を必須にします。定員超過が起きたら通知を止め、確定履歴と案内履歴から運営担当が調整します。

運用を始める前の確認

公開・運用前の確認では、通常の一件だけでなく、必須項目が欠けた一件、同じ識別子を再利用した一件、確認後に内容を変更した一件を分けて試します。特に「申込ID」が元の記録へ戻る手掛かりになり、受領・補欠・案内中・確定を分け、定員を最終確認してから確定通知するという条件を満たすか確認してください。結果を担当者と共有し、どの入力をどの状態へ残すかが説明できてから対象を広げます。

補欠を繰り上げる際、申込者が人数を減らせる運用かも決めます。三人組が二人で参加することを了承したなら、元の申込人数を消すのではなく、確認後の参加人数と合意日時を別に記録します。受領時点の情報を残すことで、後の問い合わせでも経緯を説明できます。練習では補欠三人の申込みへ二席を案内するケースを作り、了承前は二人を確定人数へ入れないこと、了承後は二人分だけが反映されることを確認します。組を分割しない規則なら、この案内自体を作らないようにします。

• Googleカレンダーへの予定登録
• 日付とタイムゾーンの設定
• Tallyの問い合わせフォーム