需求边界怎么定？
先把南宫体育场馆预约这件事拆成三类边界：谁在约、约什么、约完之后要留下什么记录。边界不清，后面比较任何方案都会失焦。建议先写一页纸的需求说明，只描述现状和约束，不写产品功能。
- 使用者范围：仅内部人员，还是含外部访客与团体预约。
- 资源范围：场地数量、时段颗粒度、是否涉及多馆区并行。
- 规则约束：取消、改期、超额预约、身份核验分别怎么处理。
- 记录要求：预约数据要留多久，谁可以查，导出给谁看。
这一页纸写完后，再回头看南宫体育场馆预约的日常流程，能发现很多所谓“系统问题”其实是规则没定清楚。
哪些是必备项，哪些只是加分项？
必备项的标准是：缺了它，日常预约就跑不通；加分项的标准是：有它更顺，没有也能靠人工流程补上。评估时把两者混在一起，最容易导致预算和复杂度失控。
- 必备组：时段冲突校验、取消与改期规则、身份与权限区分、预约记录可查询。
- 必备组：异常处理入口，例如临时闭馆、团体占用、设备故障时的批量调整。
- 加分组：消息提醒渠道多样化、可视化日历、统计看板。
- 加分组：与既有账号体系打通、移动端自助操作。
把加分项单独列一张表，标注“没有它时的人工替代办法”，这份替代办法本身就是谈判和验收的依据。
评估时要问哪几个问题？
评估阶段不要看演示效果，而是用自己场馆的真实规则去提问。下面这组问题可以直接拿去问候选方案，也可以拿去问内部使用方。 南宫体育资讯
- 同一时段被两个渠道同时预约时，冲突如何判定和提示？
- 临时闭馆时，已产生的预约如何批量通知与改期？
- 权限变更后，历史预约记录归谁管理、能否追溯？
- 数据导出格式是什么，能否按场馆、时段、人员维度拆分？
- 规则调整需要谁操作，调整后是否需要重新验证？
每个问题都要求对方给出具体操作路径，而不是笼统承诺“可以支持”。回答含糊的项，直接记为待验证。
主要取舍在哪里？
南宫体育场馆预约方案的取舍通常不在功能多少，而在规则灵活度与维护成本之间。规则越灵活，配置越复杂，日常维护就越依赖懂规则的人。
- 灵活度对维护成本：自定义规则多，初期贴合度高，但交接和排错更难。
- 自助程度对人工兜底：自助预约比例高，前台压力小，但异常处理要求更明确。
- 集成深度对上线节奏：与既有账号体系打通更顺，但联调周期更长。
- 记录粒度对查询效率：记录越细，追溯越清楚，查询和导出也越需要设计。
取舍的判断口径是：哪一项在无人值守时最容易出问题，就优先保证那一项的确定性，其余项接受人工兜底。
推荐框架怎么落地？
推荐框架不需要复杂评分表，按“先排除、再排序、后验证”三步走即可，避免被演示效果牵着走。
- 第一步排除：必备项中任何一项无法给出操作路径的方案，直接出局。
- 第二步排序：在剩余方案中，按维护成本、异常处理清晰度、集成周期排序。
- 第三步验证：用一两个真实场景走一遍，包括团体占用和临时闭馆。
下一步建议按顺序推进：
- 完成一页纸需求说明，并让使用方确认。
- 把必备项与加分项分成两张清单，标注人工替代办法。
- 用评估问题逐项记录回答，含糊项列为待验证。
- 选一到两个真实场景做走查，记录异常处理路径。
- 按排除、排序、验证的顺序形成内部推荐意见。