原来的做法为什么撑不住
会议预约最常见的原始形态是：运营在群里发通知，医生在群里回复「+1」，或者填一份在线表格。
人少的时候没问题。场次一多就开始失控：
- 名额超了没人知道，最后要靠运营手动清点
- 医生的医院、职称、照片等信息格式混乱，无法核对
- 会议地址在聊天记录里被刷掉，医生找不到进会链接
- 谁来了谁没来，事后没有数据
这不是流程问题，是缺一个「有状态」的系统。
为什么用 H5 而不是小程序
这是我们在项目早期就定下的方向，理由有三条：
- 审核成本 —— 医疗类小程序审核严格，改一次要重新提审，节奏不可控。
- 触达路径 —— 服务号推文里可以直接放链接，医生点开就用，不需要搜索或扫码跳转。
- 认证门槛 —— 服务号认证只需企业或个体户资质，且认证一次可用一年。
代价是失去了小程序的模板消息能力，但医疗会议的通知可以通过服务号和飞书侧解决，不构成阻塞。
需要提醒的是：微信服务号认证需要企业或个体户资质，且有审核周期。这是项目的前置门槛，建议在开发启动前就开始办，否则会卡上线排期。
飞书这一侧才是效率关键
这个系统真正的差异点不在客户端，在运营侧。
传统做法是：运营收到预约 → 去腾讯会议建会 → 复制会议地址 → 回到后台填 → 通知医生。五个步骤，全在不同工具里。
我们把这一步压缩成了：飞书收到卡片 → 卡片上填会议地址 → 完成。
运营不用登录第二个系统，不用切换窗口。飞书开放平台的交互式卡片支持表单回调，这是实现的关键。同时后台还保留一套完整的 H5 运营台，用于批量操作和复杂配置（主题管理、场次设置、字段配置）。
数据模型
系统的核心是三个实体：
- 场次（Session） —— 日期、时间段、主题、名额、状态
- 订单（Order） —— 关联场次、医生信息、openid、状态流转
- 配置（Config） —— 字段可见性、必填规则、主题列表
场次与字段都做成可配置，换会议形式不需要改代码。这一点在验收后很省事——甲方想加一个「科室」字段，后台点两下就行。
交付情况
本项目已上线交付，四端协同：微信服务号 H5、飞书机器人、飞书内嵌运营台、后端服务。
你可以通过下方链接体验客户端与运营台的交互流程（演示数据，非真实业务数据）。