Capability 01 · Work Order
一个入口，
一条调度链。
客诉、租户报修、厂务停机单进同一个入口，再谈派给谁。
报事没进系统，闭环就还没开始。
入口不统一，后面全是补账
同一件报事在电话、微信群、纸质签单、巡查记录里各留一份，是绝大多数「账对不上」的起点。不是记录不勤，而是入口太多，同一事实被记成不同的形状。
统一入口的价值不在于少几个人工，而在于：分类口径一致、时效从同一时刻起算、升级链只认一个状态机。后续的质控、对账、迎检导出，都只是这份数据的副产物。
报事入口的四个来源
| 来源 | 接入方式 | 进系统后的处理 |
|---|---|---|
| 客诉 / 报修 | 电话、企微、前台、二维码扫码 | 自动进分类树，按等级起算响应时限 |
| 巡查发现 | 巡场 / 巡检任务中的异常项 | 直接生成工单，关联点位与任务编号 |
| 设备告警 | BA / 厂务 / 医工系统对接 | 按设备重要性定级，避免与人工报事重复计数 |
| 计划触发 | 保养 / 检验 / 证照到期 | 转为计划工单，未接收自动升级 |
派工与优先级规则
| 规则 | 怎么定 | 解决什么 |
|---|---|---|
| 等级 | 按报事分类 + 影响范围定级，不由报事人主观决定 | 避免「会说的先办」 |
| 区域 | 按作业面与最近责任班组派单 | 减少跨区调度与到场时长 |
| 技能 | 按技能标签匹配，不匹配时给出兜底人 | 避免派给做不了的人后无人接手 |
| 负荷 | 当班在手工单量参与排序 | 避免个别班组被压垮而整体超时 |
| 时段 | 非工作时段走值班规则与夜间作业窗口 | 避免夜间无人认领 |
超时升级与协同转单
升级链要写清三件事：多久升、升给谁、升上去之后谁必须接手。
| 情形 | 触发 | 动作 |
|---|---|---|
| 一级超时 | 责任人未按时响应 | 升给班组长 / 专业主管 |
| 二级超时 | 一级仍未处理或需跨专业 | 升给项目值班负责人，同步甲方对接人 |
| 跨专业协同 | 一件事需要两个专业配合 | 以主工单 + 协同任务拆分，责任不因拆分而消失 |
| 无人认领 | 升级到顶仍无责任人 | 进入兜底池并计入流程缺陷，下轮复盘必查 |
「无人认领」是流程设计缺陷，不是人的问题；把它统计出来，才算真正有升级链。
错法 vs 作法
| 错法 | 电话报事后微信群喊人，系统只做个记录 |
|---|---|
| 作法 | 先入系统再派工，调度理由与结果可回看 |
| 错法 | 派工靠调度员经验，人一休假就乱 |
| 作法 | 规则显性可调，兜底人明确，班组长休假不影响派发 |
| 错法 | 超时靠甲方打电话催 |
| 作法 | 超时自动上浮，升级记录同时被甲乙双方看到 |
| 错法 | 跨专业任务在群里口头协调 |
| 作法 | 主工单 + 协同任务拆分，责任归属不变 |
自检清单
- 同一件报事是否可能在两个渠道各生成一张单
- 响应时限是从「报事人打电话」起算，还是从「录入系统」起算
- 超时升级的对象与时限是否在标准包里写明，而不是靠默认习惯
- 跨专业协同后，主责是否仍然唯一
- 无人认领的工单是否被统计，并进入复盘议题