体检预约系统避免时段超售，关键是让网站、前台和团体预约使用同一份可用名额，并在提交时同时完成“核对容量、占用名额、生成预约”。页面显示有空位，只代表查询当时的情况；只有提交成功并得到确认，才算真正约到了这个时段。
对体检机构经营者来说，采购验收应围绕三个问题：名额按什么计算，哪些状态占位，两个渠道同时抢最后一个名额时谁能成功。下面用演示数据拆解这些规则，不把系统功能清单当作已经验证的能力。
先定义一个名额代表什么
“上午可接待30人”不等于每个套餐、每个到店时段都能接待30人。套餐可能占用不同人员、房间或设备；如果只限制总订单数，局部资源仍会冲突。
请先让运营人员为每种套餐写清四项内容：
预约承诺：选的是到店登记时间，还是某项服务的准确开始时间？不要把到店窗口宣传成所有检查立即开始。
容量单位：按人、按套餐还是按某项资源计算？团体的一笔订单包含5个人时，不能只扣一个名额。
占用范围：服务预计占用哪些时间段，是否需要准备或周转时间？时长由机构确认，不采用软件默认值充当医学依据。
共享资源：不同套餐是否使用同一设备或人员？共享资源只能维护一份可用时间，不能在两个套餐里分别当作空闲。
可以先用“到店时段人数上限＋关键资源约束”的方式定义首期范围。只有实际需要时，才细化到每个检查环节。HL7 的 FHIR R4 Slot 文档区分空闲、占用等时段状态，也允许一个时段按容量容纳多项预约；这有助于理解模型，但不代表采用该格式就自动解决了超售。
把已确认、暂时占位和可用名额算清楚
假设演示中心09:00–10:00的套餐名额为6，已确认4个，另有1个有效的临时占位，那么当前可用名额为1：
可用名额＝总名额6－已确认4－有效占位1＝1。
这个简化计算只适用于已满足套餐和资源条件的同一容量池。若某个必需资源已经没有可用时间，即使人数还有余额，也不能自动确认需要它的套餐。
网站与前台使用同一容量池；两个新请求竞争最后一席时，最多确认一笔。
网站预约与前台代订应争取同一个剩余名额。图中数字均为演示数据，展示的是两个新请求竞争最后一席时最多确认一笔，并非某个产品的实际运行结果。
接下来明确哪些状态占位：
浏览或选中时段：默认不等于预留成功；若系统支持预留，必须返回明确的占位记录。
临时保留：需要到期时间、归属预约和释放规则。期限由业务决定，不在本文设定统一分钟数。
已确认：占用约定的人数及资源，即使采用到店付款，也不能因为“未支付”而自动释放。
候补：不承诺已经取得名额。出现空位后，还要重新校验、通知并完成确认。
付款状态和预约状态应分别展示。占位已经失效后才收到成功付款通知，不能直接把过期预约改成已确认；需要重新核对容量，或进入人工处理流程。具体退款及改期规则另行制定，本篇只关注不能因此多占或重复释放名额。
最后一个名额，要在提交时决定归属
让供应商现场演示：两个浏览器都看到“剩余1个”，一个来自网站，另一个由前台代订，同时提交后应只有一笔获得确认；另一笔收到名额已用完的提示，能重新选择或加入候补。
这里的验收重点不是按钮是否变灰，而是服务器如何处理同时到达的请求。应将容量判断与名额分配作为不可被其他请求插入的完整操作；具体采用什么技术，由开发团队解释并提供验证结果。
同时检查三种容易遗漏的情况：
重复点击或网络重试：同一次预约请求不能创建两笔订单或扣两次名额。第一次响应丢失后，应能找回原结果。
保存中途失败：不能出现名额扣了但没有预约记录，或预约已确认但名额没扣的状态；异常应能查询和恢复。
付款通知重复到达：同一笔付款不能触发多次确认或再次扣减容量。
NHS App 的官方预约帮助也提示，用户完成预约前，所选时段可能已经被其他人订走。这说明前端展示并不等于最终占位，不是要求体检系统照搬 NHS 的流程。
前台、团体预约和停用时段都要受同一规则约束
电话、聊天和现场预约如果只记在纸上或另一个表格里，线上系统无法知道真实占用。前台代订应进入同一容量池，并保留来源和经办人；如果确实需要给某个渠道保留配额，必须从总容量中明确划出，不能把同一批名额重复开放。
团体预约要明确是“整组有足够名额才成功”，还是允许部分确认。界面显示的人数、实际扣减数量和确认通知必须一致，不能默默把余下人员也标成已预约。
设备停用、人员请假或临时缩短营业时间时，建议要求系统：
先关闭受影响的新增预约入口。
列出已经确认、暂时占位和候补的相关记录。
保留原预约及联系处理记录，不自动删除已有承诺。
重新开放时检查容量与资源，而不是简单把旧名额全部加回。
若排班调整后容量小于已确认人数，应清楚提示冲突，由指定人员处理。不要只把可用数字显示为零，就掩盖已经超出新容量的事实。需要人工加号时，也应单独授权、记录原因，并对受影响安排给出提示。
把这些场景写进采购验收清单
使用模拟资料，让供应商在网站端与前台端同时操作，并保存结果：
最后一席竞争：两个新请求同时提交，最多一个确认；总占用不超过演示上限。
重复请求：连续点击或重试同一次提交，只产生一笔有效预约、一次名额占用。
占位过期：过期后可以重新分配名额；旧请求后来付款，不越过当前容量直接确认。
共享资源冲突：两个不同套餐需要同一资源的重叠时间，系统拒绝冲突或转人工确认，不能两个都承诺成功。
团体人数：一笔3人预约按3人计算；剩余2席时，按事先约定整组拒绝或明确部分确认。
临时停用：关闭时段后不再接收新确认，已有预约仍可查询并显示处理责任。
重复释放：同一预约的取消或占位失效事件重复处理，不会把可用名额多加一次。
将机构实际预计的同时预约量也交给供应商，约定测试条件和结果记录。两个人同时操作只能验证一个冲突场景，不能证明系统在任意负载下都不会超售。
先准备规则，再比较系统报价
采购前准备一份去除个人信息的一周排班样例，列出套餐、人数上限、关键资源、前台代订方式、临时占位规则和人工加号权限。把上面的验收场景作为附件，要求供应商区分现成功能、可配置项、需开发项和暂不支持项。
你可以通过 HUACODE 预约系统需求咨询提交这份规则清单，讨论现成软件是否能覆盖，或哪些部分需要适配。先确认同一份名额如何被所有入口共同使用，再比较日历界面和开发报价。
资料核查日期：2026年10月22日。本文提供预约系统采购与验收建议，不提供医学排班标准；示例规则和概念图不代表 HUACODE 已有产品功能或实测结果。