活动报名小程序如何设计活动、名额与签到

用户点击报名，实际取得的是参加一场已发布活动的资格。城市沙龙、企业开放日或分会场论坛，都要先确定主题、时间、地点、票种和参与规则。活动信息、名额、审核、订单和签到若分散在表单、表格和支付记录中，改期或取消时就无法判断谁仍然可以入场。

活动报名、到店预约和课程购买都会出现名额与订单，资格对象并不相同。到店预约锁定的是某日某时段的场地或人员；课程购买产生的是一段有效期内的内容访问权；活动报名确认的是用户能否参加指定场次。一条报名记录对应一名参加者、一个场次和一个票种，并连着审核结果、订单、退款和签到。三种资格分开记录，取消、退款和核验才有明确对象。

活动、场次和票种分开维护

一场活动可以包含多个场次，一个场次可以提供多种票种。活动记录主题、主办方、地点、介绍、报名起止时间和发布状态；场次记录开始与结束时间、会场、容量，以及是否单独签到；票种记录价格、适用人群、数量上限、是否需要审核和购买须知。介绍和规则在后台编辑，改时间和补充说明不必重新发布小程序。

免费票、早鸟票和团体票沿用同一报名流程，差别写在票种规则里。团体票写明人数范围，以及减少一人时名额和费用如何变化。草稿、定时发布和下架分开处理。已有报名成功的活动被取消或改期时，先找出受影响的报名，再通知并处理退款，原记录保留供核对。

名额由服务端按场次和票种校验

页面上的剩余名额只用于提示。用户提交时，服务端按场次容量和票种上限重新计算。同一用户对同一场次、同一票种的重复点击，应返回已有报名，避免连续点击生成多条记录。待支付订单若占用名额，需设置过期时间，超时后释放，并以支付平台的结果更新最终状态。

候补需要单独标记。候补表示愿意等待，此时尚未取得参与资格；名额释放后的确认方式和确认有效时间，在报名前写清楚。人工增加名额、预留席位和后台补录，走同一套容量校验，并留下操作记录，便于现场核对实际人数。

报名状态说明当前能否参加

每条报名至少区分为待审核、待支付、报名成功、已取消、退款中、已签到。状态由确定的动作推进：用户提交、审核结论、支付回调、主办方调整、签到和到时关闭。支付回调、后台修改和定时任务需要约定优先级，避免后到的通知把已取消或已退款的记录改回成功。

参加者打开小程序时，能看到报名编号、当前状态、场次、地点和票种。审核尚未完成时，页面保持“待审核”。活动改期或更换地点后，状态页展示最新安排，并保留变更时间和原因，方便参加者和客服核对。

收集的信息、审核和订单属于同一条报名

报名前说明要收集哪些字段、用于什么、保存多久。字段按活动配置，只保留本次审核、签到、通知或开票需要的内容。代他人报名时，区分提交账号和实际参加者。多人同行时，每人对应可签到的名额，导出名单时逐人列出，现场可以按人核验。

需要审核的活动，事先公布审核发生在支付前还是支付后。拒绝后释放名额。已经支付的，另行创建退款记录，等支付平台返回结果，再更新报名状态。参加者反馈已付款却无法签到，或审核通过后看不到资格时，客服按报名、订单、支付和审核记录逐项查找。

取消、改期和退款按报名前的规则执行

提交前展示取消截止时间、退款比例、缺席处理和改期办法。用户在规则允许时取消，系统释放对应名额。主办方取消整场活动时，批量定位仍有效的报名，逐一通知，并按已公布的规则退款或改到其他场次。退款是否完成，以支付平台结果为准。

改期后原报名是否继续有效，写在活动规则里。允许换场次时，先检查目标场次是否还有名额，再转移资格，使一人不同时占用两个场次。系列活动要定义取消一次影响单场还是全部场次。后台能看到这组报名的关系，通知里写明影响范围。

签到核对报名成功的场次，通知只同步状态

入场可以使用报名凭证二维码、报名编号或工作人员确认。凭证对应特定场次、票种和“报名成功”状态。重复签到会被拒绝，并记下尝试时间。一天多场的活动按场次分别签到，上午的签到对应上午场次的入场资格。

签到记录包含场次、操作人、时间和结果。误操作通过授权撤销，并保留原记录。现场网络不稳定时，工作人员按最近一次同步的名单核验，恢复网络后再补传，并与后台人数核对。

报名成功、审核结果、活动变更、开始前提醒和取消，可以通过微信订阅消息或短信发送。发送前取得相应授权，失败要有记录。消息没送到时，参加者仍以小程序里的报名状态为准。文案和状态使用同一套名称，变更通知写明改变的是时间、地点还是活动本身，以及参加者要等待退款、确认新场次，还是重新选择。

后台按主办、审核、现场和财务划分权限

主办人员负责发布活动、配置场次和票种、查看名单。审核人员处理通过、拒绝和补充材料。现场人员只核对本场签到。财务人员查看订单和退款。权限具体到动作，志愿者或临时工作人员只接触本场核验所需的信息。

日常操作还包括复制往期活动、关闭报名、按场次导出名单、登记人工调整和查看通知结果。导出说明是否包含已取消和候补。内部备注只对必要岗位可见，不出现在参加者端。

上线前用一场活动把变更跑通

选择一场信息已经确定、名额可控的活动，录入场次、票种、容量、审核和退款规则。用未报名、待支付、报名成功、已取消和已签到等身份分别打开页面，核对列表、详情和签到结果是否一致。同时测试最后一个名额被多人同时提交、重复点击、支付超时、审核拒绝、临时改期和退款失败。

试运行时核对订阅消息或短信能否送达，签到设备和网络是否可用，导出名单与实际入场人数是否一致。暂时无法自动处理的情况保留人工入口和操作记录。主体类目、隐私说明、收集字段和退款规则与这场活动一致后，再开放更多场次。

报名统计用于准备现场

后台可以统计报名量、取消量、各票种占用和签到情况，用来准备物料、席位和提醒时间。统计口径写明是否计入取消、候补和重复提交。这些数字帮助调整下一场的容量。录取、评选或抽签若属于活动规则的一部分，需要另行写明负责人，以及报名成功之后还要经过哪一步。系统记录参与资格和现场结果，主办方依据已公布的规则做后续决定。

封面是活动现场的签到台：手机上是场次色块、票券和入场凭证，旁边是空白名牌，背景墙上是容量格。画面没有文字，避免生成错字。

这篇按 GEO 做了四处处理。标题就是用户会问的那句话；摘要可以单独被引用；开篇写清报名记录和预约、课程购买的差别；每一节的第一句都是可抽取的结论，状态、角色和校验规则用固定说法重复，方便前后对照。