マルチトラックカンファレンス：会場とフローの管理方法

マルチトラックカンファレンスの実践的モデル：実効収容人数、セッション予約、実際の充足率、予備会場、導線、チームの役割。

マルチトラックカンファレンスの人流管理は、最初の参加者殺到が起きるまでは簡単に見えます。スケジュールには並行トラックが並び、ゲストはセッションを選び、扉には案内板が掲げられています。しかし人気の講演に行列ができ、隣の会場は半分空いたまま、チームは「今中に何人いるのか、次にどうすべきか」にすぐ答えられません。

私たちAventuraでは、まずプログラム、会場の実際の構成、セッション登録、計測方法、チームの権限を結びつけます。案内板や導線はこの設計に基づいて初めて登場します。そうすれば、満員の会場も想定外ではなくなります。早期のシグナル、意思決定の担当者、参加者向けの準備されたルートが揃うのです。

なぜ会場の収容人数は一つの数字ではないのか？

会場運営には4つの指標が必要です。安全上限、稼働収容人数、受付可能席数、実際の入場者数です。それぞれが異なる問いに答えます。これらを合わせることで、会場の物理的限界、設営後の実際の座席配置、受付の可否、そして現在中にいる人数が明らかになります。

安全上限または許可上限とは、特定の配置における絶対的な上限です。これは選択した座席配置と適用される要件を踏まえて会場が確認します。私たちは記事にある万能な計算式で再計算したり、予想される欠席を見込んで引き上げたりすることはありません。

稼働収容人数は、設営後に残った使用可能な席数を示します。これにはステージ、演出位置、カメラ、ケーブル経路、通訳、通路、車いすスペース、ベビーカー、業務エリア、視界制限席が影響します。会場の定員表が空の状態や別の配置を前提に作成されている場合、現在のカンファレンスの問いには答えられません。

受付可能席数とは、稼働収容人数のうち参加者に提供できる部分です。ここから業務用の予備枠があらかじめ除外されます。予備枠には、登壇者、同行者、運営チーム、事前に条件を合意した参加者、後期入場者用の席が含まれることがあります。万能なパーセンテージは存在しません。予備枠の構成と解放のタイミングは、個々のイベントのポリシーによって決まります。

実際の入場者数は、現在会場にいる人数を示します。これはセッション中に変動します。遅れて来る人、早く退出する人、トラックを変更するゲストもいます。そのため、申込者数はドアのカウンターの代わりにはなりません。

これら4つの指標は、それぞれ異なる問いに答えます。

私たちはシンプルなルールを採用しています。参加者の受付は稼働収容人数に制限され、稼働収容人数は確認された安全上限に制限されます。予想される欠席は、行列と人員の予測に役立ちます。ただし、絶対的な上限は変わりません。

会場と配置の選択は、最終的な付属文書に署名する前に確認することをお勧めします。別のガイドでは、会場の技術監査について詳しく説明しています。マルチトラックプログラムの場合、その結果が入力データとなります。どの会場が利用可能か、それらがどのようにつながっているか、実際のボトルネックがどこにあるかです。

各ホールのカードにある4つの数字

各ホールには、常に最新のカードが1枚必要です。プログラム、受付、技術チーム、本部は、このカードからのみデータを取得します。カードには、上限、現在のセッション、需要、入場記録、待ち行列、予備ホールの準備状況が表示されます。各項目には担当者が決まっており、更新タイミングはチーム全員が把握しています。

カードは共有表、ステータスパネル、受付システムのいずれで管理しても構いません。ツールは二次的なものです。それよりも、各項目の担当者と明確な更新タイミングを決めることが重要です。

最小構成は以下のとおりです。

カードに「ホールはほぼ満席」といった項目は不要です。チームは検証可能なステータスのみを使用します。例えば、着席中、空席あり、待ち行列が基準点に到達、入場停止、予備ホール開放、メイン入口再開などです。

異なるチームがそれぞれ独自の表を管理すると、食い違いは入口で発覚します。受付はある上限を見ており、技術担当者は撤去された列を知っており、ホールコーディネーターは別の計画で数え、案内はすでに閉鎖されたホールへ人を送り込んでしまいます。そのため、変更は単一の情報源を通します。

変更理由は個別に記録します。カメラのために2列を撤去した、舞台の位置を変更した、アクセシブル席を追加した、一部の視界を閉鎖した、操作室を移設した——それぞれの判断が稼働収容人数を変え、受付と本部に伝達される必要があります。

会場選定には会場カタログを利用できますが、ホールカードは具体的なレイアウトを確認した後にのみ作成されます。同じ面積でも同じ動線とは限りません。扉、ロビー、階段、エレベーター、隣接するアクティビティが影響します。

登録前に実働収容人数をどう計算するか

まず会場が選択した配置における厳格な上限を確認し、チームは設営後の実際のレイアウトをまとめます。次に利用可能な席を数え、視界が悪い席や動線と衝突する席を除外し、運営用の予備枠を設定して責任者を決めます。この確認を経て初めて、セッションの受付を開始できます。

最初の資料は選択した座席配置の図面です。「シアター」や「クラス」といった表現だけでは、ステージ、調整卓、カメラ、通路、出入口、利用可能な席、仮設構造物が見えない場合は不十分です。私たちは会場と技術チームに、同じバージョンの図面で作業するよう求めます。

確認はいくつかのステップで進みます。

1. 選択した配置における会場の確認済み上限を取得する。
2. ステージ、スクリーン、音響、照明、カメラ、調整卓、通訳を図面に落とす。
3. 主要扉と業務用扉、通路、その手前のゾーンを示す。
4. 利用可能な動線と、それに接続する席を明示する。
5. 実際に設置された椅子または作業位置を数える。
6. 視界が遮られる席、技術上の制約がある席、動線と衝突する席を除外する。
7. 運営用の予備枠を分かりやすいカテゴリーに分け、責任者と解放期限を定める。
8. 受付に開放する席数を確定し、それを変更できる担当者を明示する。

設営後は、実際に歩いて計算を照合します。図面では、出っ張ったカウンター、ケーブルブリッジ、扉の開閉、柱、コーヒーの行列、特定の列に届くスクリーンの光などは見えないことがあります。そのため会場コーディネーターは廊下から席まで参加者の経路をたどり、技術担当者は視界と聞き取りやすさを確認します。

扉は別途確認します。会場に十分な椅子があっても、着席が遅いことがあります。行列は狭い入口、バッジ確認、紛争のある登録によって生じます。この場合の制約は、入場プロセスの処理能力です。

通常の流れと紛争案件は分けた方がよいでしょう。確認済みの参加者は快速入口を通ります。プロフィールの誤り、登録の欠落、特別な条件、トラック変更の希望は、専用のコーディネーターが対応します。1件の複雑なケースが着席全体を止めてはなりません。

同様の原則を私たちはイベント参加者の登録で採用しています。主要な流れは短いシナリオで進み、例外は別の経路に振り分けます。複数トラックのカンファレンスでは、人気の会場でこのロジックが繰り返されます。

実働収容人数を口頭で変更することはできません。リハーサル後にカメラが追加されたり、列が撤去されたりした場合、責任者が会場カードの新しいバージョンを発行します。受付システム、会場チーム、会場ディスパッチャーは同じ更新を受け取ります。古い数値は無効としてマークし、チームがメールのやり取りから復活させないようにします。

セッション：予約、キャンセル待ち、実際の入場

事前選択は参加者の意向を示すものであり、会場での出席をまだ確定するものではありません。入場受付を済ませて初めて、席は実際に埋まったとみなされます。ゲストが遅刻した場合、チームはあらかじめ告知されたルールに従って対応します。すなわち、定められた時刻まで席を保持するか、キャンセル待ちの次の人に譲るかです。

フォームを設定する前に、申し込みから実際の入場までの間に席がどうなるかを記述してください。参加者はセッションを選択し、確認またはキャンセル待ちの順番を取得し、選択をキャンセルでき、トラックを変更し、会場に来て入場受付を済ませ、早退するか、来場しないこともあります。システムが最初の選択だけを保持していると、すぐに実態を反映しなくなります。

席が限られるセッションには4つのルールが必要です。

第一に、確認とは何を意味するか。一定の時刻までの保証された席なのか、優先入場なのか、それとも関心の登録にすぎないのか。文言はメール、アプリ、スタッフ向け指示で同一でなければなりません。

第二に、いつ席が解放されるか。チームは、出席が確認されていない席をキャンセル待ちの次の人に移せる時刻を定めます。万能な時刻はありません。形式、着席にかかる時間、登壇者の妨げにならずに入場できるかどうかによって異なります。

第三に、予約なしの入場を認めるかどうか。認める場合、会場コーディネーターは優先順位を理解している必要があります。確認済みの予約、キャンセル待ち、自由入場の順です。認めない場合、ナビゲーターは単に人を追い返すのではなく、代替案を提示します。

第四に、直前のトラック変更をどう処理するか。変更は参加者のメインプロフィールを更新しなければなりません。コーディネーターへのチャットメッセージでは需要予測は変わらず、会場に検証可能なステータスも与えられません。

個別の数値を保持しておくと有用です。

無断欠席率はイベント後に自社データで算出します。確認済み予約の数から差し引くのは、同じリストのうち定められた時刻までに入場受付を済ませた参加者だけです。予約なし入場は別途集計し、この計算式には含めません。一部の人が来ないことを期待して安全上限を超えて予約を受け付けることはしません。そのようなアプローチは、確認済みの収容人数を無断欠席の予測で置き換えてしまうからです。

キャンセル待ちはコミュニケーションと一体でのみ機能します。空いた席は次の参加者に提案し、入場を確認するわかりやすい方法を提供する必要があります。通知がセッション開始後に届いたり、その人が会場の場所を知らなかったりすると、形式的に空いた席は実際の着席にはなりません。

研修や必須のセッションでは、出席の証明が必要になることがあります。その場合、プログラム上での選択だけでは不十分です。チームは何をもって参加とみなすかを定めます。入場受付、退場受付、最低在席時間、その他合意された基準です。これらのルールはイベント前に発注者が承認します。

一日を通してホールの稼働状況をどう把握するか？

現在の稼働状況は入場と退場で算出し、事前登録はあくまで予想需要を示すにすぎません。すべての扉を対象とし、移動方向を区別するのであれば、集計は手動でもデジタルでも可能です。チームは事前に更新頻度、照合方法、最終的な数値に責任を持つ担当者を決めておきます。

小規模なホールであれば、一人のスタッフが扉を見て集中を切らさなければ、手動のクリッカーで十分です。入口と出口が分かれている場合は、二つのカウンターか、方向を区別する統合システムが必要です。扉が複数ある場合、チームは事前に誰が数値を集約するかを決めます。

QRによる入場記録は、入場権とユニークな来場の確認に便利です。しかし一度のスキャンでは、その人が最後まで残ったかは分かりません。参加者が自由に退出・再入場する場合は、退場記録、再スキャン、人数カウントセンサー、または定期的な照合再集計が必要です。

センサーも自動的に課題を解決するわけではありません。対向する人流、グループ、開いた扉、何度も通過するスタッフについて検証する必要があります。イベント前にチームは表示値と手動カウントを比較し、許容できる照合の程度を決めます。私たちは特定のシステムのデータなしに、普遍的な誤差を設定することはしません。

ステータスパネルに何十もの項目を表示する必要はありません。ホールディスパッチャーが素早く確認できるべきは：

• 各ホールの現在のステータス；
• 稼働上限；
• 実際の充足率；
• 待機列または待機列のチェックポイント；
• 次のセッションの予測；
• 予備ホールの準備状況；
• 最終更新時刻；
• 責任者。

色によるステータスはテキストと組み合わせて初めて機能します。通常モード、予備準備、入場停止には検証可能な定義が必要です。例えば、予備準備は待機列がチェックポイントに達したときに始まります。入場停止は合意された誘導の開始を意味します。事前に定められたアクションのない色は何も変えません。

私たちはデータ上見落とされやすい人々を別途カウントします：登壇者、同行者、請負業者、スタッフです。全体の実際の充足率と人数上限は、会場の規則と確認済みの図面に基づいて算出します。管理区域に物理的に存在するすべての人がこの集計に含まれます。個別カテゴリーは分析とチーム運営にのみ使用し、全体の上限から人を除外するものではありません。

データが食い違う場合、より安全な判断が優先されます。システムが空席を示していても、ホールコーディネーターが通路が塞がっている、または適切な着席ができないと判断した場合、チームは入場を続行しません。食い違いを記録し、入場を減速または停止し、その後照合を行います。

予備会場：事前に準備すべきこと

予備ルートはメイン会場と同時に準備します。事前に収容人数、合図、担当者、導線、質問のルール、開場と閉場の条件を確認しておきます。そうすれば、待ち行列が増えたときにチームはすでに検証済みのシナリオを起動でき、参加者は通路が塞がれる前に明確な代替案を得られます。

予備会場はメイン会場と同時に設計します。まず、どのセッションに必要かを決めます。通常は需要の高い講演、必須ブロック、収容人数の限られた小会場、または開始後に参加者を移動させるのが特に負担となるプログラムです。

起動には状態マトリクスが役立ちます：

明確な合図はわかりやすいものです。実際の充足率が運用収容人数に達した、適切な席がなくなった、または着席が通路をふさぎ始めた場合です。早期の合図は会場によって異なります。目印の地点での待ち行列、人気セッション前の持続的な入場の流れ、隣接トラックの終了などが考えられます。正確な数値は、巡回とテストの後に設定し、他人の事例から取るのではありません。

予備会場の技術的な準備には以下が含まれます：

1. メイン会場からの映像ソース。
2. 予備会場で聞き取りやすい音声。
3. 利用可能な席から見えるスクリーンまたはプロジェクター。
4. 検証済みの信号遅延。
5. 少なくとも音声またはプレゼンテーションのバックアップ。
6. メインセッションで提供されている場合は同時通訳または字幕。
7. 参加者を迎え、ステータスを伝える予備会場のコーディネーター。
8. 質問をする明確な方法、または質問はメイン会場からのみ可能であるという正直な案内。
9. セッション終了後に全体プログラムへ戻るための計画。

このような仕組みでは、両方の部屋の音響設備を事前に確認することが重要です。聞き取りやすい音声のない映像では課題を解決できません。予備信号が遅れる場合、予備会場のコーディネーターは、いつドアを開けるか、プログラム終了前に流れを廊下に出さない方法を知っておく必要があります。

参加者が隣室にいて一方向の配信を見るだけの場合、私たちは予備会場を完全なハイブリッドとは呼びません。同等の体験には、専用のモデレーション、質問、アクセシビリティ、サポートが必要です。それがなければ、約束は正直に表現します：具体的な機能を備えた予備視聴です。

予備会場への導線は待ち行列の前から始まります。参加者は前の分岐点で代替案を見られる必要があります。「メイン会場は満席です」というメッセージの後には、すぐに次のアクションを示します：予備会場の名称、方向、開始時刻、利用可能な機能です。

負荷が下がった後も、メインの入場を一度に開けるのではありません。会場コーディネーターが空席を確認し、会場ディスパッチャーが対向流を確認し、案内係が人を少しずつ通します。そうしないと、新しい待ち行列が退出する参加者と衝突します。

トラック間の移動はどう設計する？

移動は、ある会場の席から別の会場の席までの全ルートで測ります。参加者は列を出て、通路と分岐点を通り、階段やエレベーターを使い、入場許可を確認して再び席に着きます。これらすべてのステップをプログラムのグリッドに織り込み、設営後に動線を検証する必要があります。

スケジュール上の休憩は、画面上では十分に見えることがよくあります。しかし現場では、講演後の質疑応答、登壇者との会話、クローク、コーヒー、トイレ、ドアの行列、目的のフロアの探索に時間を取られます。そのため私たちは設営後に主要ルートを実際に歩き、実際の制約を記録します。

まず会場間の移動マトリクスを作成します。各ペアについて以下を記します：

• 通常ルート；
• バリアフリールート；
• ドアと進行方向；
• 階段とエレベーター；
• ボトルネック；
• 隣接する飲食・休憩ゾーン；
• 案内表示の設置場所；
• 分岐点に配置するスタッフ；
• 局所的な通行止め時の代替ルート。

必須参加者が一方の会場から他方へ移動しなければならない場合、グリッドを密にするためだけにこれらのセッションを連続して配置することはできません。バッファはプログラムの一部です。バッファは、大多数の参加者が着席し、次の会場が遅刻者の絶えない入場なしに開始できる状態になった時点で終了します。

隣接するトラックが同じ通路、エレベーター群、コーヒーゾーンを利用する場合、終了時刻をずらすのは有効な手法です。わずかなずれでも共通のピークを軽減します。正確な値はルート検証後のプログラム全体のタイミングで決まります。万能な長さはありません。

対向する人の流れは特にドア付近で危険です。前の聴衆がまだ退出しているのに、新しい聴衆がすでに入ろうとしています。解決策は、方向を分ける、退出が確認できてから入場を開始する、または会場が許せば別のドアを使うことです。

ナビゲーションは参加者の判断を基準に構築します。まず、どのフロアや棟へ行くべきかを理解する必要があります。次に分岐点の後に確認表示を見ます。ドアの前では会場名、現在のセッションと次のセッションを確認します。受付に一枚の地図を置くだけでは、この連鎖を代替できません。

バリアフリールートは全体を検証します。行列がエレベーター、スロープ、通路を塞いだなら、形式的に存在する経路は機能しなくなります。私たちはこの管理をインクルーシブな企業イベントの原則と結びつけています。各移動には特定のスタッフが責任を持ち、参加者は次のステップで何が見えて何ができるかを理解します。

会場の変更は一つの情報源から発信します。アプリ、スクリーン、紙の案内、スタッフ向け指示を更新します。一つのチャネルが古いままだと、一部の聴衆が以前のドアに来て、第二のエラーの流れを生み出します。

役割、権限、会場の短いステータス

会場コーディネーターは特定のオーディエンスを担当し、会場ディスパッチャーは全体の稼働状況と待ち行列を把握します。技術担当者は映像と音響を確認し、ナビゲーターは参加者を分岐点まで案内します。イベント前に、チームは誰が入場を停止し、予備会場を開き、メッセージを変更し、通常モードに戻す権限を持つかを明確にします。

会場コーディネーターは開始前に会場を引き受けます。作業定員、登録可能な席数、予備、遅刻入場のルールを把握しています。着席中は現在のカウントを取得または記録し、ドアを監視し、基準点到達を報告します。

会場ディスパッチャーは特定のドアに縛られません。すべての会場、通路、予備視聴のステータスを把握します。ここでナビゲーターの再配置、メッセージの変更、予備の開放、通常モードへの復帰の調整が決定されます。

会場の技術責任者はマイク、映像、ファイルの作業バージョン、主信号、予備を確認します。セッションが予備会場に中継される場合、チェーンの両側を確認します。セッション間の引き継ぎにはイベントの技術リハーサルの原則が役立ちます。チームには開始者、アクション、成功の指標があります。

ナビゲーターは選択ポイントの前に立ちます。代替案を知り、ルートを示し、本部の決定に従います。登録や特別な許可を確認する必要がある場合、専任コーディネーターがそのケースをメインの流れから引き受けます。

ステータスは短く、統一されている必要があります：

• 会場準備完了；
• 着席中；
• 早期シグナル到達；
• 作業上限到達；
• 入場停止；
• 予備準備完了；
• 予備会場への配信開始；
• 流れをリダイレクト；
• メイン入場を分割開放；
• 通常モード復帰。

メッセージは実行確認で閉じます。「予備会場を開けてください」というフレーズは指示を与えます。「予備会場開放、予備会場コーディネーター配置、ナビゲーション更新」というステータスは結果を確認します。

役割名はチームに合わせてロシア語化できます。より重要なのは、決定の境界を事前に明確にすることです：入場を停止する権利、予備を開く権利、画面を更新する権利、スピーカーに遅延を警告する権利、時間と理由を記録する権利。

権限とステータス引き継ぎの全体システムについては、イベント本部と無線通信の記事で詳しく説明しています。ここでは、緊急ステータスが日常的なリクエストに紛れないよう、会場専用のチャネルまたはメッセージ形式があれば十分です。

ドアを開ける前に何を確認すべきか？

各セッションの前に、チームは人、空間、資料、合図、入場許可を確認します。「ホール準備完了」というステータスだけでは不十分です。コーディネーターは列と通路を点検し、技術担当はファイルとバックアップを確認し、スピーカー担当スタッフは登壇者を引き継ぎ、ホールディスパッチャーは待ち列と隣接する導線を照合します。

ホールの受け入れは、前の観客が退出した後に始まります。コーディネーターは列と通路を点検し、技術担当はプレゼンテーションの作業版とバックアップを確認します。その後、スピーカー担当スタッフが登壇者をホールチームに引き継ぎます。その間、ホールディスパッチャーは待ち列を隣接する導線と照合し、それから初めて入場を許可します。

開場前の簡単なチェックリスト：

1. 前の流れが退出し、入口に立っていない。
2. 通路と利用可能なルートが空いている。
3. 実際の着席が作業カードと一致している。
4. 業務用の予備席が表示され、ホールコーディネーターに理解されている。
5. 現在のセッションとホールがすべてのチャネルで一致している。
6. 登壇者がホールに受け入れられ、マイクとタイミングが明確である。
7. 資料の作業版がアップロードされ、確認されている。
8. メインの音響と表示が機能している。
9. このセッションの予備ホールが最新のステータスを持っている。
10. 入退場カウンターが準備され、初期値が照合されている。
11. ナビゲーターが分岐点の前に立ち、代替案を把握している。
12. ホールディスパッチャーが入場許可を与えた。

受け入れ中に、チームはファイルのバージョンを別途確認します。確認後に登壇者が差し替えを持ち込んだ場合、影響を受けるステップが再び開かれます。ファイルは単にオペレーターのところで上書きされるのではありません。会議前のプレゼンテーションの凍結に関するガイドで、確認されたバージョンがメイン表示とバックアップの両方に入る必要がある理由を示しています。

開場前には、簡単な例外テストが役立ちます。チームは、入場のQRマークが利用できない場合の手順を示さなければなりません。誰がローカルジャーナルを管理し、システム復旧後にそれを照合するのか。別途、記録のないゲストのルート、予備席の解放ルール、予備ホールが信号を受信しなかった場合の代替シナリオを確認します。

テストは実際の行動で行います。スタッフは画面を表示し、ホールカードを開き、ステータスを変更し、バックアップを起動し、参加者にメッセージを伝えます。「やります」という回答は準備完了を証明しません。

別途、最初のトラック変更を確認します。これにより、標識が十分か、入口と出口が交差していないか、ホールチームがカウントを更新する時間があるか、ホールディスパッチャーが全体像を理解しているかがわかります。見つかったエラーは、次の大量移動の前に修正されます。

カンファレンス後のデータと意思決定の振り返り

イベント後は、各セッションについて予測・実際の需要・チームの対応を比較します。登録者数の総数だけでは、どこで行列が発生したのか、何人が会場まで到達したのか、予備の視聴が役立ったのかは分かりません。振り返りには、統一した集計ルール、意思決定のタイミング、そして振り分けられた参加者に関する個別データが必要です。

セッションごとの最小レポートには以下が含まれます。

自社データからは、来場率、ピーク時の負荷、予備会場へ移動した参加者の割合を算出できます。計算式は、集計ルールが同一の場合にのみ有効です。プレナリーセッション、ワークショップ、ラウンドテーブルでは観客の行動が異なるため、これらを一つの共通指標に混ぜるべきではありません。

振り返りでは、実際の満員になる前に早期シグナルが機能したか、そしてその判断がナビゲーションにまで反映されたかを確認します。次に、会場コーディネーターの連絡から予備会場の開場までの時間、参加者が移動を断った理由、手動集計とデジタル集計の差異を比較します。

これらの回答が次のタイムテーブルを変えます。人気のテーマは別の会場へ移し、隣接する終了時刻をずらし、確認の文言を明確にします。キャンセル待ちは入場チェックと連携させ、ナビゲーターは分岐点の手前に配置します。最終レポートは次のプロジェクトへの入力となります。

多トラックカンファレンスのフロー管理をどう構築するか?

登録受付開始前に各ホールにつき1行を記入し、設営後に会場で確認してください。カンファレンス当日、この表はステータスパネルと意思決定ログの基盤となります。チームは上限、需要、実際の充足率、待ち行列、予備の準備状況、役割、障害時の対応を把握できます。

多トラックカンファレンスは、チームが各ホールのスケジュールと状態を把握できて初めて管理可能になります。私たちは実際の座席数を数え、登録と出席を区別し、動線が塞がる前に待ち行列に気づき、合意された基準に従って予備を開放します。

出典

• Northamptonshire Fire and Rescue Service：収容人数制限を評価するためのガイド
• Nottinghamshire Fire and Rescue Service：収容人数の計算
• UK Government：大規模集会施設における火災安全リスク評価
• HSE：群衆を監視する
• HSE：群衆管理を実施する
• HSE：会場内の群衆管理
• U.S. Access Board：アクセシブルな経路のガイド
• U.S. Access Board：標識のガイド
• Microsoft Learn：セッションレベルの登録を設定する
• Microsoft Learn：イベントのキャンセル待ちを設定および管理する
• Microsoft Learn：イベントチェックインを最大限に活用する
• EventMobi：セッションのアクセスと定員設定
• EventMobi：参加者をチェックインする
• SUNY Cortland：オーバーフロー視聴会場
• TU Wien：LectureTubeによる部屋間ストリーミング