SA 访客预约一阶段 PRD (Plan B: 主方全流程录入制)

1. 问题定义 (Problem Statement)

1.1 背景与现状

目前访客管理依赖手工填写或复杂的外部 H5 流程。原始需求希望访客通过小程序主动发起预约，但经评估存在严重的 “隐私泄露” 风险（外部可探测内部组织架构）以及 “体验摩擦转嫁” 问题。

1.2 核心痛点

• 安全性：允许访客模糊搜索内部员工，违反企业安全红线。
• 稳定性：访客填报与行政审批属于异步流，与会议室预订的即时流存在生命周期冲突，易产生僵尸资源或预订失败。
• 基建依赖：当前系统缺乏成熟的访客端 H5 采集与状态同步能力。

2. 目标与衡量指标 (Goals & Metrics)

2.1 核心目标

实现极简、安全的访客预约闭环，确保项目在 M3 节点高质量交付。

2.2 成功指标

• 安全性：零内部人员信息外泄风险。
• 采纳率：> 80% 的商务访客邀约通过 Agent 完成。
• MTTR：访客录入到系统响应时间降至 2 分钟内。

3. 用户故事 (User Stories)

ID	角色	诉求	价值
US.1	员工(主方)	能够通过一句话（或卡片）快速录入访客信息并建单	无需登录复杂后台，随时随地办结
US.2	员工(主方)	访客申请成功后，系统能主动提醒并引导订房	逻辑连贯，避免遗忘必要的商务配套准备

4. 需求明细 (MoSCoW)

4.1 Must Have (必须实现)

• 主方录入闭环：支持识别“姓名、手机号、到访时间、报备信息”等槽位。
• 动态确认卡片：AI 识别意图后弹出信息确认卡片，支持主方在线微调。
• 原子化 API 调用：直接对接现有访客系统“代提交/内建”接口。

4.2 Should Have (应该实现)

• 意图链叠加 (Intent Chaining)：访客建单成功后，AI 主动追问：“是否需要预订附近的会议室/贵宾室？”。
• 相似度截断：槽位提取置信度低于 0.6 时触发反问。

4.3 Could Have (可能实现)

• OCR 证件识别：主方拍照访客名片自动提取信息。

4.4 Won't Have (本次不实现)

• 访客端自主录入 (Plan A)：由于安全与基建原因，一阶段暂不开放访客侧 H5 接口。

5. 业务流程逻辑 (Logic Flow)

5.1 交互时序图

6. 约束与限制

• 安全约束：严禁在未授权情况下向对话框输出内部员工通讯录模糊匹配结果。
• 系统约束：若访客系统接口返回延迟超过 5s，需触发流式等待话术。

7. 灰度与上线计划

• Phase 1 (M3)：主方录入制上线，支持内部核心业务员内测。
• Phase 2 (M4)：视基建情况考虑是否引入“邀约推送+H5 异步采集”模式。