主题
06 校友预约系统 vs 会议预定系统 — 差异分析与建设方式
对应需求：
IBMS功能模块-V1.md三.2「空间资源移动预约服务」备注「校友预约系统 @? 校友返校预约 不支持，需要单独业务系统」。 项目背景：上海交通大学新院区，以 MBA 教学为主；校友返校、招生面试、企业参访、讲座是常态业务。
1. 核心判断
两者不是同一类系统，建议分开设计。
它们只在最底层共享「时间—资源—冲突—审批」这套引擎；上层业务对象、用户身份、审批方、联动场景都不同。校友预约更接近**「访客管理 + 活动报名 + 场地预约 + 接待编排」**的组合，而不是「订会议室」。
建议路径：
- 校友预约作为独立业务模块/系统建设，或集成学校已有的校友平台；
- 我方承接 IBMS 侧的联动与编排：通行授权、参观路线、欢迎信息、环境准备——对应「设备集中管控模块」第 8 条里的「校友返校智能服务」；
- 如果客户要求我方承担校友预约本体，按「访客 + 活动报名 + 场地预约」单独设计，与会议预定分开。
2. 两者到底差在哪
| 维度 | 会议预定 | 校友返校预约 |
|---|---|---|
| 用户 | 内部教职工/学生 | 外部校友（可能没有校内账号），常带家属/同伴 |
| 身份 | 统一身份 SSO、工号/学号 | 校友身份核验（学号、证件、手机号、校友库），可能需要人工审核 |
| 预约对象 | 会议室/讨论室（房间+时段） | 活动场次 + 参观路线 + 接待资源（讲解、用餐、停车、纪念品） |
| 业务形态 | 房间占用 + 冲突检测 + 审批 | 活动报名/批次管理 + 接待方案 + 通行授权 |
| 审批方 | 院办/资产/空间管理 | 校友会/学院/保卫处，可能多级 |
| 频率 | 高频、短时、日常 | 低频、事件驱动、集中在校庆/返校日 |
| 规模 | 单间、几人到几十人 | 单人/家庭/班级/年级，批量团体 |
| 核心联动 | BA/照明/设备/门禁 | 门禁通行、访客登记、停车、信息发布屏、讲解路线、餐饮 |
| 数据归属 | 校内空间资源 | 校友库、活动库、访客库 |
结论：会议预定是「资源调度」问题；校友预约是「接待服务流程」问题。后者比前者多了身份核验、团体批次、通行授权、接待编排四层。
3. 校友返校预约的真实业务链条
校友身份核验（校友库/学号/证件）
↓
选择返校活动/日期/人数（个人/家庭/班级/团体）
↓
提交预约 → 校友会/学院审核
↓
生成接待方案：参观路线 + 讲解 + 用餐 + 停车 + 纪念品
↓
通行授权：门禁（临时凭证）+ 访客登记 + 车辆放行
↓
环境准备：活动空间空调/照明/投影/欢迎屏
↓
到访：签到 + 引导 + 活动
↓
结束：反馈 + 数据归档这条链里，只有「场地时段」和会议预定重叠，其余都是会议预定没有的。
4. 我方现有能力与复用方式
| 能力 | 现状 | 复用方式 |
|---|---|---|
| 会议室资源/可用时段/预定/取消 | 已有，120 间会议室，已接飞书，roomDeviceIds 可联动设备 | 复用底层「时间—资源」模型 |
| 预约审批 | 预约本身不走审批；审批是独立能力 | 为校友预约补审批流 |
| 访客管理 | 待补 | 新建/集成访客模块 |
| 门禁临时授权 | 有门禁记录查询 | 补临时授权能力 |
| 停车/车位 | 有车位状态与占用率 | 复用 |
| 信息发布屏 | 属集成范围 | 对接 |
| 活动报名/批次 | 待补 | 新建活动报名模型 |
| 校友身份库 | 依赖学校/学院 | 集成 |
会议预定的「场地时段占用」可以直接复用；身份核验、团体批次、访客通行、接待编排需要单独设计。
5. 建设方式建议
| 方式 | 做法 | 适用 |
|---|---|---|
| A. 集成学校已有校友系统 | 通过 API 拿预约数据，我方做通行/环境/欢迎屏联动 | 学校已有平台 |
| B. 第三方产品 + 我方集成 | 采购成熟的校友/访客预约产品，我方做 IBMS 联动 | 没有现成平台 |
| C. 我方共建 | 按「访客管理 + 活动报名 + 场地预约」设计 | 客户明确要求我方承担 |
无论哪种方式，我方的价值点都在 IBMS 侧：
- 通行联动：预约审核通过 → 自动下发临时门禁权限/访客凭证/车辆放行。
- 环境准备：活动前自动开空调、灯光、投影、欢迎屏。
- 路线与引导：参观路线同步到信息发布屏/移动端；结合人流密度做分流。
- 服务闭环：活动结束后自动关闭设备、回收权限、生成接待记录。
- 智能体入口：校友/接待人员用自然语言查询「我的预约/怎么走/需要什么」。
6. 新院区/MBA 场景下的典型用法
| 场景 | 校友预约要做什么 | IBMS 要联动什么 |
|---|---|---|
| 校庆/返校日 | 批次报名、团体接待、路线 | 门禁、停车、报告厅环境、欢迎屏、人流分流 |
| 校友讲座 | 活动报名、席位管理 | 报告厅设备、录播、空调照明、签到 |
| 企业参访 | 访客登记、通行授权 | 门禁、停车、参观路线、会议室环境 |
| 招生面试 | 考生预约、批次管理 | 面试间环境、门禁、引导屏、叫号 |
| 校友捐赠/座谈 | 小范围预约、接待 | 接待室环境、停车、欢迎信息 |
这些场景和「订会议室」的区别一目了然：核心是接待流程，不是房间占用。
7. 需要澄清
- 学院/学校是否已有校友管理系统或返校预约平台？谁在维护？
- 校友身份如何核验？校友库由谁提供？是否支持微信/小程序登录？
- 返校预约是个人为主还是团体为主？是否需要活动报名、缴费、名额管理？
- 审批流由谁发起、几级审批？是否要走 OA？
- 是否需要访客通行、车辆放行、用餐、讲解、纪念品等接待资源？
- 校友预约系统是否在本次建设范围内？如果是我方承担，交付边界是什么？
8. 一句话总结
校友预约 ≠ 会议预定。会议预定是订房间，校友预约是接待一车人回母校。 建议校友系统独立建设/集成，我方聚焦 IBMS 侧的通行、环境、引导、服务联动；如果客户要求我方承担预约本体，按「访客 + 活动报名」单独设计。