工单中心系统设计方案

1. 业务理解

1.1 工单的本质

工单的本质：把「问题/需求」转化为有责任人、有时限、有闭环结果的任务。它是运营质量管理的抓手——每一条现场事件都有迹可循、有人跟进、有结果可查，沉淀为可统计、可考核的数据。

1.2 现状梳理

• 运营对象：景区合作的慢速四轮车，由现场运维人员负责日常维护。
• 建单来源（两条）：

1. 现场提交：车辆出现问题，现场直接提交工单；
2. 客服代建：后台客服听到游客反馈后，代为提交工单，并通知现场运维人员处理。

• 现有工单类型：维修工单、挪车工单、充电工单。
• 未来场景：车辆具备自动驾驶能力后，会出现「车遇困」情况（车辆陷入无法自主脱困的处境），同样需要工单承接。
• 演进需求：需要一个工单中心系统，把其他业务系统的工单也接入进来统一管理——例如车厂系统（与采购、售后相关的工单）。

1.3 系统定位

工单中心 = 统一接入、统一分派、统一跟踪、统一考核的中枢。

• 各业务系统是工单的生产方（建单来源）与消费方（查询/回传结果）；
• 中心是唯一的数据源（single source of truth）：统一流程、统一 SLA、统一考核口径、统一报表。

2. 系统定位与总体架构

2.1 总体架构

┌─────────────────────────────────────────────────────────────┐
│  接入层                                                      │
│  开放 API（外部系统接入） | 车辆平台事件 | 客服录入          │
├─────────────────────────────────────────────────────────────┤
│  核心层（工单引擎）                                          │
│  工单建模 | 状态机 | 分派引擎 | SLA 引擎 | 飞书通知引擎      │
├─────────────────────────────────────────────────────────────┤
│  应用层                                                      │
│  客服工作台（Web） | 现场运维端（飞书） | 管理后台           │
├─────────────────────────────────────────────────────────────┤
│  数据层                                                      │
│  MySQL（核心表见 §9）                                        │
└─────────────────────────────────────────────────────────────┘

2.2 技术栈

• PHP 8 + webman + Eloquent：与公司现有系统（如 oauth 认证中心）同栈，团队技术一致、维护成本低。
• 数据库：MySQL。
• 现场运维端：飞书集成（机器人推送 + 卡片交互），不单独开发移动 App，详见 §7。

2.3 接入方式

3. 统一工单模型与类型

3.1 工单号

格式：WO-YYYYMMDD-6位序号，全局唯一，如 WO-20261013-000123。

3.2 类型枚举

类型设计为可配置枚举 + JSON 扩展字段：未来新增类型（如车辆报废/下线、跨站点车辆调配）不改核心表结构，仅需新增类型定义、扩展 JSON 结构与 sla_config 行。

3.3 来源枚举

3.4 优先级

3.5 主字段清单

3.6 类型扩展字段（JSON）

不同工单类型的差异化信息存扩展字段（表 work_order_ext）：

• repair 维修：故障现象、故障等级、诊断结论、处理方式、备件使用；
• move 挪车：起始位置、目标位置、挪车方式（人力推 / 拖运）；
• charge 充电：电量、充电位置、充电前后电量；
• rescue 遇困：遇困事件 ID、触发原因、远程解除尝试记录、是否需人工到场；
• maintenance 保养/巡检：巡检项勾选结果、保养项目、本次里程/周期、下次保养日期；
• cleaning 清洁消毒：清洁项目、消毒记录、清洁前后照片；
• accident 事故：事故时间地点、对方信息、现场照片、责任认定、保险报案号、定损结果；
• infra 基础设施：设备类型（充电桩/站点设备）、故障现象、处理结果；
• ota 远程诊断/升级：车辆软件版本、目标版本、诊断结论、升级结果、是否转线下处理；
• procurement / after_sales 外部单：外部系统类型、供应商、金额、进度（由外部系统维护，中心只读同步）。

4. 状态机

4.1 主状态（各类型共用一套）

created 已创建 → assigned 已分派 → processing 处理中 → pending 挂起
                                                    ↘ completed 已完成 → closed 已关闭

stateDiagram-v2
    [*] --> created: 建单
    created --> assigned: 客服分派
    assigned --> processing: 运维接单/开始处理
    processing --> pending: 需等待（备件/外部反馈）
    pending --> processing: 恢复处理
    processing --> completed: 处理完成、回填结果
    completed --> closed: 客服确认关闭
    created --> cancelled: 录入错误取消
    assigned --> rejected: 处理人退回（附原因）
    processing --> rejected: 处理人退回（附原因）
    rejected --> assigned: 重新分派
    closed --> [*]

4.2 流转规则

• 取消：仅 created 状态下可由创建人取消（录入错误）；已分派后的取消需客服主管操作，并记录原因；
• 转派：assigned / processing 状态下，客服可不改状态直接更换 assignee_id（运维之间也可互相转派）；原处理人与新处理人均留痕于 work_order_status_log（from 原运维 / to 新运维，type=assignee_change），飞书通知新旧双方。计划性转派需客服主管确认。
• 关闭后问题复发：生成新工单并设置 parent_order_id 关联原单，不重开原单，保持数据纯净；
• 审计：每次状态流转写入 work_order_status_log（from/to/操作人/备注/时间），全链路可追溯。

5. 角色、权限与流程

5.1 角色与职责

游客不建账号：反馈经客服或现场运维转述录入系统。

5.2 通用流程

创建 → 客服分派（规则建议 + 人工确认）→ 运维飞书接单 → 处理
→ 回填结果 → 完成 → 客服确认关闭（可选）

5.3 内部工单流程要点

• 维修（repair）：到场诊断 → 现场处理或拖回站点 → 回填诊断结论 / 处理方式 / 备件使用。需车厂支持时：挂起（pending）并关联外部售后单。
• 挪车（move）：多为计划性 / 调度性任务，记录起始位置、目标位置、挪车方式，低优先级。
• 充电（charge）：可由低电量事件自动触发建单，运维到场接桩充电，回填充电前后电量。
• 保养/巡检（maintenance）：按周期/里程计划性生成，现场按巡检项逐项勾选结果，异常项自动转维修单。清洁消毒（cleaning）同属计划性，按排期执行并附清洁前后照片。
• 事故（accident）：现场保护与记录（时间/地点/对方/照片）→ 保险报案 → 定损 → 车辆转维修单处理，全程记录责任认定与报案号。
• 基础设施（infra）：充电桩/站点设备故障，分派运维到场处理；影响充电运营时按 P1/P2 升级，处理结果关联相关充电单。
• 远程诊断/升级（ota）：优先远程处理（远程诊断 / OTA 升级），远程不可解再转线下维修单。

5.4 遇困流程（rescue，自动驾驶场景）

车辆感知困境 → 平台事件上报 → 自动建单（source_type=auto_event，优先级 P1）
→ 客服分派 → 先远程尝试解除（记录尝试过程）→ 成功则完成
→ 失败则到场救援 → 完成；如需维修，关联生成后续维修单

车辆平台事件格式由 M2 阶段定义（见 §10）；事件接入与人工确认可配置：默认直接自动建单，必要时改为推送客服确认后建单。

5.5 外部工单流程（procurement / after_sales）

• 由外部系统经开放 API 创建（source_type=external_api）；
• 不进入现场运维分派池，中心仅登记、跟踪，随外部状态回调更新；
• 管理后台可查、可统计；
• 如需现场参与（如到货安装），客服手动关联内部工单处理。

6. 分派与 SLA

6.1 分派规则

客服手动选人，系统按以下维度给出建议（人工可改）：

1. 站点 → 该站点运维人员；
2. 技能匹配（维修 / 充电等）；
3. 当前在单负荷（在单量少的优先）。

6.2 SLA 配置

SLA 按 优先级 × 类型 配置（表 sla_config），示例默认值：

数值仅为示例，以 sla_config 可配置为准。

计划性类型（maintenance / cleaning / 计划充电）可配置为只设完成时限、不设响应时限，按排期执行，不计入响应考核。

6.3 计时口径

• 响应 = 分派（assigned）时刻；
• 完成 = completed 时刻；
• 挂起（pending）期间计时暂停。

6.4 超时升级

SLA 超时 → 飞书通知升级至客服主管，由主管人工介入：

1. 催办：飞书提醒当前处理人加速处理，不改变分派；
2. 改派：主管手动更换 assignee_id（走转派日志）；
3. 升级优先级：P3→P2 / P2→P1（可选，默认不自动升）。

超时升级动作按类型可配置：突发类（维修/事故/遇困）超时后允许自动改派（如分配给同站点空闲运维），计划类（保养/清洁）仅通知主管不自动改派。

7. 现场运维端（飞书集成）

现场运维人员通过飞书完成接单与处理闭环，不单独开发移动 App，能力边界受飞书平台约束。

降级预案：若运维人员无飞书账号，飞书端能力可降级为 H5 网页版，接口保持不变。

7.1 飞书用户映射

运维人员在 users 表中维护 feishu_user_id（飞书 open_id）；新单/通知/超时升级时，系统通过 feishu_user_id 推送机器人消息或卡片；无飞书账号的运维人员不纳入分派池，由管理员在 users 表中补全映射后生效。

8. 外部系统接入（开放接口规范）

8.1 认证

复用公司 OAuth2 认证中心（webman oauth 项目）：外部系统在认证中心注册客户端，使用 client credentials 流程获取令牌，调用时携带 Authorization: Bearer <token>。

8.2 接口清单（一期）

统一前缀 /open/v1，REST + JSON。

8.3 幂等与错误处理

• 幂等：external_order_no + source_system 唯一；重复推送返回已有工单，不重复建单；
• 错误码：参数校验 422、未授权 401、单号不存在 404。

8.4 外推（二期可选）

一期不做「中心 → 外部系统」webhook 外推；如外部系统需要主动感知状态变更，在 M3 阶段按需评估追加。

8.5 车辆平台事件接入（内部）

车辆平台（如自动驾驶调度系统）通过内部接口推送事件，由中心自动建单。

请求体示例：

{
  "event_type": "low_battery",
  "vehicle_id": "V10086",
  "timestamp": "2026-10-13T14:30:00+08:00",
  "location": {"lat": 31.2304, "lng": 121.4737, "text": "A区3号点"},
  "battery_level": 15,
  "event_id": "evt_20261013143000_V10086"
}

• event_type 枚举：low_battery（低电量建充电单）、vehicle_stuck（遇困建救援单）、fault_alarm（故障报警建维修单）；
• 幂等：event_id 全局唯一，重复推送返回已有事件记录；
• 响应：201 已建单、200 重复事件、422 参数无效；
• 事件与工单映射规则由运营后台配置（如 low_battery → type=charge / priority=P2 / SLA=4h），不同事件可映射到不同类型与优先级。

9. 数据模型（核心表）

9.1 work_orders（工单主表）

索引：(status, type)、(assignee_id, status)、(cs_id, status)、(vehicle_id)、(status, station_id)、(source_system, external_order_no)、(parent_order_id)、(created_at)。

9.2 work_order_status_log（状态流转日志）

id、order_id、from_status、to_status、operator_type、operator_id、remark、created_at。

9.3 work_order_ext（类型扩展）

order_id、type、payload（JSON，见 §3.6）。

9.4 work_order_attachments（附件）

id、order_id、url、kind（photo/audio）、created_by、created_at。

9.5 work_order_comments（工单评论）

id、order_id、author_type、author_id、content、created_at。

9.6 sla_config（SLA 配置）

id、type、priority、response_minutes、complete_minutes，(type, priority) 唯一。

9.7 users / stations

• users：在现有人员体系上扩展 role（station_manager / cs / cs_leader / ops / admin）与 station_id；
• stations：id、name、area（景区 / 站点）。

9.8 external_systems（外部系统注册）

id、code（唯一）、name、auth_mode（oauth_client_id）。

10. 实施里程碑

附录：方案覆盖自检