event-no-show-management

活动未出席管理

由你决定：

• 对于给定规模的场地，接受多少人报名。
• 何时将哪些候补者转为正式名额。
• 活动当天如何消化报名名单与实际到场人数之间的差距。
• 向餐饮团队报哪个人数。

不由你负责：

• 为票定价。
• 撰写提醒邮件。
• 安排签到台工作人员。
• 判断活动是否有市场需求。

以下所有排序都是此技能自行拟定的，并非基于测量得出的排序：它们只是默认方案，不是定律，而且会随情境和执行者而变化。每个选项菜单都会说明哪种访谈回答会让哪个选项移动。访谈结束后，根据你对主办方的了解，重新排列全部三个菜单——以下任何一项都可能推翻默认排序：

• 付费活动。
• 没有过往数据的首届活动。
• 不允许现场临时报名者入场的场地。
• 提前一个月就要锁定的餐饮保证人数。
• 在最后一周没有空闲时间的志愿者团队。

其他地方已决定的事项

将以下内容视为固定输入，不要重新讨论：

• 票务策略（免费、象征性收费或定价售票）归 samber/dev-event-organizer-skills@event-ticket-pricing 负责。它负责象征性收费策略，其中减少未出席人数是定价带来的附带效果（只要收取任何费用，未付款的 RSVP 就会变成可用于承诺支出的确定人数）。无论票价如何，剩余事项都由你负责。
• 提醒序列的设计和全部文案归 samber/dev-event-organizer-skills@event-attendee-email-sequences 负责。该技能将超额预订比例、候补名单、押金和释放名额列为你的职责。将提醒序列视为已在你的计算开始前降低了未出席率的一项杠杆；不要在此处撰写提醒内容。
• 出席率背后的需求判断归 samber/dev-event-organizer-skills@event-market-fit 负责。它将这个数字视为活动概念、价格和受众的证据；你则将同一个数字作为容量输入。读取它的判断结果，不要重新推导。
• 签到台的组织安排（现场报名通道如何安排人员、排队和分流）归 samber/dev-event-organizer-skills@event-attendee-experience 负责。你决定该通道应预期接待多少现场报名者，以及哪个比例得出了这个数字。

以上每条边界都只从本技能的角度表述。依赖这些分工之前，请先阅读相关技能对边界的说明。

访谈

一次只问一个问题，尽可能采用选择题。第 8 至 10 个问题之所以存在，是因为下面各项措施在见效时间、持久性和投入上差异很大；不能替用户选定默认项。

1. 场地的硬性容量是多少（消防规范、场地合同或座位数实际限制的人数）？是否有弹性空间（站席、备用场地），谁必须批准使用？
2. 持有席位的人为此付出了什么：除了注册之外什么也没付、象征性费用，还是实际票价？这一点已在上游确定；请说明具体情况，不要重新讨论。
3. 目前有多少人注册了，注册是否仍开放，是否有必须关闭注册的日期？
4. 哪些费用已经按人数承诺，分别何时锁定？请说明餐饮保证人数的日期、任何场地最低消费，以及周边商品或胸牌的印制批次。这些因素会决定高估人数的代价。
5. 提醒邮件序列是否已经设计好并确定发送日期？如果没有，请先运行 samber/dev-event-organizer-skills@event-attendee-email-sequences；以下所有比例都假定提醒邮件已经发挥作用。
6. 未注册的人在活动当天能否实际到达签到台，还是场地设有出入管制、需要佩戴胸牌，或距离足够远，不会有临时到场的人？另外，你是否有能在一天内联系到候补名单的渠道？
7. 你是否有同一活动、同一形式往届的注册人数与实际出席人数？
8. 各项措施最晚何时还能改变结果（实际上就是第 4 题中餐饮或场地保证人数的日期）？如果保证人数下周就要锁定，所有需要预留注册时间的措施都无法实施。
9. 这是单届活动，还是定期举办的活动，今年测得的出席率会成为明年的规划依据？
10. 活动前最后两周的投入上限是多少：组织者可投入多少小时、是否有人能手动联系候补名单并做宣传，以及签到台能否安排第二条通道？

票价情况

在这个领域，所有有来源的数据都会按持有席位的人为此付出了什么分成两类。

• 付费活动：90-97% 的门票会转化为实际出席，未到场率为 3-10%（数据归因于 Event Tech Live）。
• 免费活动：未到场率为 40-60%（数据归因于 Event Tech Live）。
• 比较未到场率（3-10% 对比 40-60%），差距接近一个数量级。
• 若用到场率来计算可容纳人数对应的注册人数上限，该差异会让上限大致减半。

请引用你实际采用的两种数据之一。票价情况是这里所有数据所依据的分类标准。

一项规模更大的跨平台样本也呈现出相同的差异，只是中位数更低，并补充了较小样本无法提供的一点提醒。一项经签到记录验证、涵盖 860 多场活动的分析，将范围缩小到 195 场活动进行后续研究，发现总体未到场率中位数约为 20%：免费活动约为 28%，付费活动约为 17%。免费与付费活动之间的大部分差距体现在活动层面，而不是个人层面。

在同一场活动中，付费只让个人到场的几率提高约 2-4 个百分点，远低于活动层面对比所体现的 11 个百分点差距。要判断上限，请参考上面的区间。看待这个数据时，请记住：“免费还是付费”的影响，大于“这位注册者有没有付费”的影响。

雇主出资的席位只是一种假设，不得作为可调整措施。 雇主出资购买门票，意味着参会者本人从未亲自感受到这笔费用，所以这类席位的表现可能更接近免费席位，尽管票面价格并非如此。这里没有任何数据对此进行衡量：以上所有到场数据都以票价情况为依据，而非由谁付费；下一节的定金证据也受同样的数据覆盖范围限制。samber/dev-event-organizer-skills@event-ticket-pricing 讨论了定价中“由谁付费”这一维度，但并未得出关于出席率的结论。如果有人问起，请说明这一点，并以票价情况为规划依据。

社区运营还是供应商运营，决定了你吸引到的_人群_范围，但无法决定采用哪个比例。

超额预订策略

针对固定容量的场地，接受多少个注册。

人数上限是一道门槛，不是这个选项列表中的一个档位。 场地可同时容纳的人数上限由消防法规、场地合同以及据此购买的保险固定规定（Q1）；绝不能拿它与餐饮成本效益或让场地坐得更满作交换。这项义务带来两点要求，两者都不能排序：

• 根据_预期到场人数_而非注册人数来判断是否触及上限：只有在预期未到场率能够维持的前提下，上限才是安全的，因此要说明到场假设，以及假设不成立时的处理方式。
• 在针对站立区或溢出空间接受注册前，取得场地指定负责人的书面批准——绝不能等到当天在门口才处理。

如果你想采用的比例会让预期到场人数超过上限，就调整比例；上限不变。

排序（默认排序，并非定律；请根据 Q2、Q7、Q9 重新排序）：

• 工作量（得出并论证这个数字所需的小时数，以及注册期间的监控工作）：自定比例上限 > 引用的 2x 上限 > 不超额预订
• 价值（已承诺支出的场地容量所容纳的人数）：自定比例上限 == 引用的 2x 上限 > 不超额预订
• 合规成本（相对于场地规定上限及以此为前提的保险所产生的超员风险，以及接受注册后这一安排的可逆性）：引用的 2x 上限 > 自定比例上限 > 不超额预订
• 效率：引用的 2x 上限 > 自定比例上限 > 不超额预订

支配性检查：3 组配对，严格支配关系为零——只有在结构设计上才算干净，而结构设计上的干净从来不等于过关。 有两种机制阻止了这 3 组配对出现支配关系；两种都要说明：

• 与不超额预订方案配对的两组，在成本上不成立：每种上限都会让更多人进入场地，而在工作量和超员风险这两方面都严格更差。
• 第三组是自定比例与引用的 2x 上限：两者价值相同，但每个档位在不同的成本维度上更低（引用上限的工作量较少，自定比例的风险较低），因此任何一方都无法在两项上同时做到至少相等。

这两个理由都不是证据；效率排序的依据是以下论证。

两个上限的价值相同，因为两者都会让场地达到满员。某一届活动自身的注册人数与到场人数之比只是单次样本；引用的 2x 则基于覆盖 323 场活动的汇总图表。两者都不能明确算作更好的估算值，因此这种平局是真实的，不是回避决策；工作量随后让引用上限胜出。

效率上的赢家在合规成本维度上也是最差的。 借用的比例比实测值有更大的方差，因此引用上限是预期到场人数最接近上述门槛的档位。只有在不触及该门槛时，效率才会选择它。

如果方差可能导致预期到场人数超过上限，就由门槛决定，不让选项列表参与决策。在设定人数前，要向场地合同的签署人说明这种风险。

• 有来源依据的 2 倍上限——免费报名活动的默认选项：接受报名人数最多达到目标出席人数的 2 倍，然后停止。MLH 黑客马拉松组织者指南明确指出：免费活动的报名者中约有 50% 会到场，因此报名目标应设为出席人数的 2 倍，且不得超过 2 倍。上限是这条指示中承重的部分，不是对它的取整。
• 按自身比例设定上限——被冷落的选项：它的价值评分并列最高，投入程度最高，因此在每一轮效率比较中都会落败。根据上一届的报名人数与实际出席人数计算自身倍率，并将其控制在有来源依据的上限以内。适用条件：重复举办的免费报名活动（Q9），你掌握同一活动、同一形式（Q7）的这项数据，并且有一笔已承诺的费用会在开场前按人数锁定（Q4）；只有这种组合下，借用 50% 与采用自身测得的比例之间的差异才关系到金钱，而非无关紧要的细节。
• 不超额报名——接受报名至容量上限，然后关闭报名。对于收费活动，这样做是正确的，不是偷懒；对于免费活动，这会让已付费的餐饮场地空出一半。

对于收费或象征性收费的活动（Q2），请从此菜单和上方的轴线中删除这两个上限选项，并且不要超额报名。 两种错误的代价并不对等：空一个座位损失一份餐饮费用，而拒绝已付款者则要退款，还会招致公开议论。3–10% 的未到场率是规划餐饮时要考虑的数字，绝不是可以拿来超额售票的余量。

删除，而非降级：不设任何上限、持续开放报名。 这看起来像是通过最大化出席人数来应对免费活动，而且是指南明确禁止的唯一做法。超过上限后，你不再是在吸收差额，而是在确保已报名的人会被拒之门外；这对信任的损害，比空一个座位造成的金钱损失更大。

此菜单背后三个各自有适用范围、有来源依据的数据见 references/show-up-rate-figures.md。引用任何数字前请先阅读，且绝不要将它们混在一起：其中两个都写作“50%”，但回答的是不同问题，因此对它们取平均值，得不出任何问题的答案。

候补名单设计

超过人数上限后到达的人会怎样处理？排序如下（默认方案，并非定论；请结合 Q3、Q6、Q8、Q10 重新评估）：

• 工作量（登记窗口期间所需的小时数，以及这项工作是有明确日期的，还是持续进行的）：按距离优先 > 固定日期 FIFO > 不设候补名单
• 价值（原本不会到场、但因而能来到现场的人数，以及对被拒绝者保有的信任）：按距离优先 > 固定日期 FIFO > 不设候补名单
• 合规成本（排序规则要求你公开哪些信息，以及人们据此登记后，这条规则有多难撤销）：按距离优先 > 固定日期 FIFO > 不设候补名单
• 效率：固定日期 FIFO > 按距离优先 > 不设候补名单

这个选项清单本身没有支配关系，并不代表经过了审慎考量：价值和工作量的排序相同，因此没有哪一项优于其他选项，任何效率排序都可以接受。这不代表通过了检验；而是说，支配关系检查无法在此发现错误，排序完全取决于每个选项自身的论据。请把它视为最值得质疑的选项清单。

• 固定日期 FIFO - 默认方案：超过人数上限后仍接受登记，并在候补名单开放时公布的某个日期一次性递补。做法机械、对被跳过的人也站得住脚，成本只是一个下午，而非一项持续工作。

• 按距离优先 - 最不受青睐的选项：按候补者距离场地的远近排序。这种做法假设离活动地点越近的人越有可能到场。它带来的好处是每个递补名额的实际到场率更高。代价是：

  • 除了批量 FIFO 本身的成本，还要花大约一小时按距离整理并核查名单。
  • 根据登记者的位置数据作出分配决定，因此你必须能够公开说明这一规则，而且不能在登记窗口期间悄悄更改。

  递补条件：工作量上限足以涵盖整理和核查名单的人力（Q10），并且登记人数超出上限足够多，使递补顺序确实能改变哪些人获得名额，而不只是改变谁先获得名额。

• 不设候补名单 - 达到人数上限后关闭登记，并在页面上明确说明。这样做坦诚，但仍有成本：请求照样会通过电子邮件发来，而收件箱里没有排序规则、也没有日期的未整理名单，本质上就是一份候补名单。

**如果人数保证在你现实中最晚可安排的递补日期（Q8）之前就已锁定，候补名单就不再是预算调节手段。**它仍能填满座位，这值得去做；但不再改变餐饮供应方据以安排的数量。请明确你要的是哪一种，因为只有第二种会影响 samber/dev-event-organizer-skills@event-budget 所做预算中的数字。

**已删除，而非降级：每次有人取消就逐个名额持续递补。**这会让候补名单在整个登记窗口期间变成一项持续工作，而收益已被人数上限吸收；同时，它会趋向于本技能下文指出未经测试的实时逐席替换做法。

每次递补都是一个需要单独发送事务性电子邮件的事件。请将触发条件、受众和截止时间作为简报交给 samber/dev-event-organizer-skills@event-attendee-email-sequences；它会撰写邮件。简报内容和候补名单本身的操作方式见 references/waitlist-and-walk-in-mechanics.md。

关于押金问题：有理有据地拒绝

出席后退还的可退款押金，是人们期望这项技能能够纳入排名的手段之一。**对它进行排名会造成虚假的精确感。**在开发者活动组织领域，没有成熟做法能证明它是一种现实中的出席管理机制。只有两个跨行业数据点，而且都来自单场活动，并非研究：

• Eventtia 的 2024 年托管会议数据：$3 的可退还押金，将一场原本免费的活动的未出席率从 38% 降至 14%。这是普通会议的结果，并非开发者活动的结果。
• 37signals（Basecamp）的案例更接近这项技能自身的受众：芝加哥的一场免费早餐活动要求缴纳 $100 押金，并在活动现场退还。55 人缴纳了押金，50 人到场；相比免费活动通常 40-60% 的未出席率，到场率达到了 90%。

关于 Basecamp 案例的报道也指出了《价格立场》中提到的相同局限：这种机制依赖报名者自身的损失厌恶心理；而由雇主报销费用的企业参会者，感受到的押金压力可能不如自掏腰包的人。

押金担保的_候补名单_确实存在，但用途是在不同情境下预售并衡量需求。这属于 samber/dev-event-organizer-skills@event-market-fit 的范畴，而不是有关出席率的证据。

应当坦率说明这一点，而不是凭空编造一个等级。如果组织者仍想尝试，就应将其设定为实验，并预先说明衡量指标，同时点明它带来的三项成本：

• 每位实际到场的参会者都需要办理退款。
• 资金流转会带来的会计和税务义务。
• 这道门槛对那些最需要按需申请的奖学金席位所面向的人，影响最大。

方向相同且已有成熟实践的手段是象征性收费；它属于 samber/dev-event-organizer-skills@event-ticket-pricing，而不属于这里。

当日缺口补位

弥补比例未能填满的座位。排序（默认建议，并非铁律；根据 Q6、Q10 重新排序）：

• 工作量（桌面值守、第二份表单，以及任何必须在前一晚完成的事项）：候补名单补位通道 > 现场报名通道 > 不采取措施
• 价值（由适合参加活动的人填满座位）：候补名单补位通道 == 现场报名通道 > 不采取措施
• 效率：现场报名通道 > 候补名单补位通道 > 不采取措施

这里不涉及合规成本这一维度。此方案中唯一真正的风险，存在于下方已删除的选项；而所有现行选项在某个维度上都持平的话，这个维度就没有参考价值。

两种通道的价值相同，因为它们填满的座位数相同，而且没有证据表明被提名的候补者比现场报名者更可能到场。若要说的话，理由恰恰相反：现场报名者已经站在你的场地里，这比任何承诺都更能表明其会出席。工作量因此打破平局，所以普通通道在效率上领先。

• 现场报名通道 - 默认选项，也是有资料依据的做法：设置单独的晚到报名表，只有在预先注册者的签到时段结束后才处理，并要求所有人填写完整的注册表（MLH 黑客松组织者指南）。它从下方弥补缺口，而不是把某个指定的人安排到某个指定的空座位上。samber/dev-event-organizer-skills@event-attendee-experience 已在签到台实现了这条通道；向其提供预期的现场报名人数及其背后的比例。

• 候补名单补位通道 - 资源较少的选项：采用相同的通道，但在前一晚告知候补名单成员，未认领的座位将在指定时间开放，这样就能由你已知的人来填补。该通道本身是成熟做法；利用候补名单为其补充人员，则是此技能自身的扩展，并非有资料依据的机制。

  晋升条件：场地实行出入管制、需要证件，或地点偏远到没有任何临时到场人群（Q6），并且你有渠道能在一天内联系到候补名单成员（Q6）。若不满足第一项，你就是在为发送通知付出成本，而门口排队的人原本可以免费填补这些座位。

• 不采取措施 - 活动按实际到场人数进行。当场地容量已发挥作用，且没有任何承诺以人数为依据时，这是合理的选择；若餐饮已作出保证，则代价高昂。

如果候补名单选项没有选择候补名单，就从此菜单和上方的维度列表中删除候补名单补位通道；没有名单可供补位。

已删除，而非降级：允许未注册者无需填写表单直接入场。 这看起来像是更慷慨的现场报名通道，却会让你失去人数统计、行为准则协议、饮食与无障碍需求数据，以及紧急联系人名单，而这些信息恰恰在最需要的时候缺失。

指南明确指出，所有签到者仍须填写完整的注册表。

工作流

1. 进行访谈。确定容量、形式、已承诺的成本及其锁定日期，以及投入精力的上限。

2. 根据你的资金模式查看到场率预期，不要取平均值：

   • 免费报名活动：按免费区间规划，将上限定在接近容量两倍的位置。
   • 付费活动：按付费区间规划，将上限定在接近容量的位置。

   从 references/show-up-rate-figures.md 中选取带适用范围的数值，并说明你采用了哪个数值。

3. 针对明确的上限设定超额报名比例。 将上限写成具体的报名人数，而非意向；并说明在必须关闭表单时由谁执行。列出计算过程：

   • 容量。
   • 预期到场率，以及该数值的来源。
   • 得出的报名上限。

4. 设计候补名单及其递补触发条件：

   • 什么情况会开启候补名单。
   • 按什么顺序递补。
   • 在什么日期递补。
   • 由谁决定。

   候补名单开启时就公布排序规则，不要等有人询问为什么自己被跳过后才公布。

5. 决定押金方案，或说明无法决定。 坦诚的结论是：不建议采用押金机制，并说明它会带来的三项成本。将相关顾虑转到定价方案上，这方面已有实践依据。

6. 安排现场候补名额通道：

   • 按比例预计有多少现场候补者。
   • 该通道是否从候补名单中递补。
   • 何时开放。
   • 仍需填写完整表单这一点。

   将人数交给 samber/dev-event-organizer-skills@event-attendee-experience；该工具负责现场候补通道的人员安排和排队管理。

7. 分发这些数字。 将预期到场人数（绝不能用报名人数）交给 samber/dev-event-organizer-skills@event-budget，用于餐饮和人均成本计算，并说明超额报名缓冲量，即两者之差。将采用的比例和每次候补递补事件交给 samber/dev-event-organizer-skills@event-attendee-email-sequences，以便其提醒邮件面向正确的受众。

8. 在活动当天统计实际情况：

   • 报名人数。
   • 到场人数。
   • 现场候补人数。
   • 候补递补人数，以及其中实际到场的人数。

   将实际到场率作为需求信号提供给 samber/dev-event-organizer-skills@event-market-fit，并将其保留为下一届活动的输入。

如果你的运行环境支持持久化记忆，请记录：

• 容量。
• 预期到场率及其来源。
• 上限及其计算过程。
• 已公布的候补名单排序规则。
• 最终的报名人数与到场人数。

最后这项数据，是下一届活动将借用的比例转化为自身比例的关键。

未经验证的领域

遇到相关问题时，请直接说出以下内容，不要编造答案。

• 不讨论以出席为条件的押金。 与其设计可退款押金流程，不如将背后的顾虑引向定价策略：名义费用才是有主办方实践支持的调节手段。参见上文有理有据的拒绝。
• 在有证据表明并非如此之前，免费赠票和奖学金席位都应视为免费席位。 经过申请审核的席位可能比普通免费票更能促使持票人履约，也可能没有差别，因为持票人仍然没有付费。不要预设任何一种情况；应将其单独统计并查明情况。目前只有一个具名数据点，无法据此得出结论。BlackPythonDevs 为 PyCon Uganda 2024 赞助了 47 张学生票，其中 22 人出席：出席率为 47%，处于普通免费票的区间内，并未明显高于或低于该区间。这只是一个活动的数据，且没有与同一活动中未获赞助的出席者进行对比。
• 活动期间实时将候补名单上的人选提升至空出的席位，未经验证。 开门前为现场报名者预留通道，是有实践支持的做法；而在活动进行期间，将候补名单上某位具名人员安排到某位未出席者的具名席位，则是一种实验，而非顺理成章的延伸。最接近的成熟做法是票务平台的候补名单自动化：释放席位并设置限时认领窗口。所有有记录的版本都在活动开始前运行，针对取消和过期预留，而非在活动期间运行。某个平台对该机制的自述是：“一种用于弥补售票后库存缺口的补救机制，而非活动期间的候补晋升策略。”本技能也遵循这一界限。

失败模式

• 免费活动超出双倍上限。 指示是“以双倍为目标”，并且“不要超过双倍”。只取前半句而忽略后半句，会把吸收缺席人数的策略变成一项保证：已报名者会在门口被拒之门外。
• 混淆三个不同来源的数据。 50% 的出席趋势线、30-50% 的流失区间，以及活动前两周达到 100%、前一周达到 200% 的报名曲线，虽然来自同一个组织，却出自不同文档，回答的问题也不同。把它们平均会得到一个无法回答任何问题的数字。应分别报告，并说明各自的适用范围。
• 因为用户要求押金机制，就凭空编造一个。 信誓旦旦地描述押金流程，会让人误以为这种做法确实存在；应拒绝，并说明其三个成本，然后将顾虑引向定价策略。
• 在这里解决提醒问题。 在本技能中重写提醒节奏或起草提醒文案，会重复负责此事的同级技能，并在同一活动中留下两套互相冲突的流程。应将问题转交给该技能。
• 将付费活动 90-97% 的出席率套用于免费活动，或反过来。 在本领域最大的差异范围内，两者处于两端：未出席率分别为 3-10% 和 40-60%。在免费活动中使用付费活动的数据，会导致所有后续人数估算都偏低；在付费活动中使用免费活动的数据，则会导致估算偏高，并把正常的活动误判为出了问题。
• 把报名人数报给餐饮供应商。 报名人数是你接受报名的人数，不是实际用餐人数。samber/dev-event-organizer-skills@event-budget 需要的是预计出席人数，并应单独列明缓冲人数。
• 将低出席率视为运营失败。 原因可能是需求、价格、受众或提醒流程。samber/dev-event-organizer-skills@event-market-fit 会对这些因素进行区分；只有在完成区分后，才应从容量方面采取行动。
• 在付费活动中使用超额报名策略菜单。 两个上限都应删除，而不是调低：多来一人的收益有限，代价却可能是退款，以及公开解释为何拒绝已付费的人入场。

衡量指标

这里的每个比例目标都是自行设定的。引用的区间描述的是群体情况：它们能告诉你活动情况是否正常，但不能判断你的比例设得是否恰当。两项通过或不通过的门槛和四项自行设定的信号：

• 预期出席人数低于场地方公布的容纳人数上限（门槛，通过或不通过；在开放报名之前，以及每次调整上限时重新检查）：写下计算过程及其到场假设，任何站立区或溢出空间的安排都必须获得场地方的书面批准。这项不是自行设定的，也不能协商变通；所有其他安排都必须服从这项义务。
• 已报名人数与实际出席人数均已统计并记录（门槛，通过或不通过）：你要么为本届活动记录这个数字，要么不记录。没有它，上述所有内容都只能退化为照搬他人的比例；而且这是本页上成本最低的一项。
• 比例准确度（自行设定）：实际出席人数与容量的对比。在活动开始前，确定差距达到什么程度时，会让你在下一届上调或下调人数上限。
• 候补名单递补到场率（自行设定）：获递补者中有多少人实际到场。这是唯一能在自己的受众中检验邻近性规则的方法，而不是直接相信指南中的推理。
• 现场报名人数与预测的对比（自行设定）：现场通道实际接待的人数。在实施出入管控的场地，若现场通道一个人都没接待，这就满足了取消该通道的条件。
• 餐饮人数与保证人数的偏差（自行设定）：订购份数与实际用餐份数的对比。高估或低估都会在这里转化为成本，而 samber/dev-event-organizer-skills@event-budget 下次会需要这个数字。

调用示例

• “我们有 400 人报名参加免费的黑客马拉松，但房间只能容纳 250 人。我们应该关闭报名表吗？”
• “我们有 180 人报名参加免费的聚会活动，应该订多少份午餐？”
• “我们应该收取可退款押金，以减少免费门票的报名者临时缺席吗？”
• “去年有一半 RSVP 的人没来。下一届活动前我们该做哪些调整？”

预期输出：一份涵盖所有数字的容量计划，并标注每项数字是引用值还是自行设定值：

• 场地的硬性容量。
• 预期到场率，以及其来源和适用范围。
• 报名人数上限，并展示计算过程。
• 候补名单的排序规则和递补日期。
• 现场通道的预期接待人数。
• 提供给餐饮方的预期到场人数，以及说明缓冲量。
• 对押金问题的回答，应说明它反映的差距，而不是把押金当作操作手段。

参考资料

• samber/dev-event-organizer-skills@event-ticket-pricing - 票务策略与名义费用
• samber/dev-event-organizer-skills@event-attendee-email-sequences - 提醒流程与事务性邮件
• samber/dev-event-organizer-skills@event-market-fit - 到场率说明的需求情况
• samber/dev-event-organizer-skills@event-attendee-experience - 签到台与现场通道的人员配置
• samber/dev-event-organizer-skills@event-budget - 人均成本项目
• samber/dev-event-organizer-skills@event-registration-forecast - 预计报名人数，以及达到本技能设定上限的日期