按产品问题类型和团队负载分派工单，核心是先把工单归到可判定的问题类型，再按类型确定责任团队，最后在责任团队内按当前负载选择处理人。这套方法适合工单来源杂、产品模块多、团队并行处理任务的场景。落地时建立三张基础表：问题类型与责任团队映射表、团队负载口径表、分派规则优先级表；分派动作按“类型定团队—负载定个人—超限转交或排队”的顺序执行，并保留人工改派与复核通道。
要点总览（TL;DR）
- 按类型和负载分派工单，先建立三张基础表：问题类型与责任团队映射表、团队负载口径表、分派规则优先级表，让分派有据可依。
- 执行顺序固定为“类型定团队—负载定个人—超限转交或排队”，类型匹配优先于负载均衡，避免把工单分给不熟悉模块的低负载团队。
- 负载以加权工作量为主指标、待处理工单数为辅助指标，阈值取团队近三个月加权工作量中位数，1.2倍预警、1.5倍超限。
- 受理人、团队负责人、处理人、复核人各司其职，改派与复核必须留记录，规则冲突和例外每周汇总一次用于修订。
- 上线后按类型映射覆盖率、误判率、阈值触发、改派比例、分派时效和积压情况逐项检查，前两个月每周一次，稳定后改为每月一次。
分派前先定义问题类型与责任团队
分派的第一步是把工单归入可判定的问题类型。类型划分过粗，责任团队无法确定；划分过细，受理人判断成本高、误判多。建议从三个维度组合划分：产品模块（如订单、支付、账号）、故障现象（如报错、数据不一致、性能下降）、诉求性质（故障类、需求类、咨询类）。实际使用时以产品模块作为一级分类，诉求性质作为二级分类，故障现象作为标签补充，这样既能快速定位责任团队，又保留细分空间。
类型确定后，需要一张映射表把类型与责任团队固定下来。映射表建议包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 类型编号 | 唯一标识，便于规则引用 | T-ORDER-01 |
| 一级分类 | 产品模块 | 订单 |
| 二级分类 | 诉求性质 | 故障类 |
| 判定依据 | 受理人判断时可核对的信息 | 涉及下单、改单、取消订单流程 |
| 责任团队 | 该类型的默认承接团队 | 订单服务组 |
| 备选团队 | 责任团队不可用时的转交对象 | 交易平台组 |
| 生效范围 | 适用的产品线或客户范围 | 全部产品线 |
| 维护人 | 负责更新该条映射的角色 | 订单服务组负责人 |
类型判定由受理人负责，依据是工单描述、用户提供的截图或日志、产品模块选择项。受理人无法判定时，标记为“待定类型”并转给分派协调人，由协调人对照映射表判定，必要时与责任团队负责人确认。判定结果和依据要写入工单记录，便于后续复核和误判分析。
团队负载的口径与采集方式
负载口径决定分派是否均衡。常用的三个指标各有适用条件：待处理工单数反映队列长度，适合工单处理时长相近的团队；加权工作量按工单复杂度折算，适合类型差异大的团队；平均处理时长反映团队消化速度，适合判断趋势而非瞬时负载。建议以加权工作量为主指标，待处理工单数为辅助指标，平均处理时长用于阈值调整参考。
| 指标 | 计算方式 | 数据来源 | 采集频率 | 适用条件 |
|---|---|---|---|---|
| 待处理工单数 | 团队名下未完结工单计数 | 工单系统队列 | 实时或每小时 | 处理时长相近 |
| 加权工作量 | 各工单按复杂度权重求和 | 工单类型权重表＋工单记录 | 每日 | 类型复杂度差异大 |
| 平均处理时长 | 近30天完结工单时长均值 | 工单系统历史记录 | 每周 | 趋势判断与阈值校准 |
复杂度权重可按类型设定，例如故障类工单权重为2、需求类为3、咨询类为1，权重由团队负责人根据历史处理时长校准，每季度复核一次。负载阈值建议按团队历史数据设定：取团队近三个月加权工作量的中位数作为基准线，基准线的1.2倍设为预警阈值，1.5倍设为超限阈值。阈值随人员变动、产品版本发布周期调整，调整记录保留在负载口径表中。
分派规则的设计与执行顺序
类型匹配和负载均衡同时存在时，类型匹配优先。原因是责任团队掌握对应模块的处理权限和知识，把工单分给负载低但不熟悉该模块的团队，会增加返工和转交成本。执行顺序为：先按类型映射确定责任团队，再在责任团队内按负载选择处理人，责任团队整体超限时进入排队或转交流程。
团队内选人的做法是：取出责任团队当前各处理人的加权工作量，选择工作量最低且具备该类型处理权限的人。工作量相同时，优先选择最近处理过同类工单的人，减少上下文切换。团队内只有一人具备权限时，直接分派并记录原因。
负载超限时按以下顺序处理：
- 责任团队加权工作量达到预警阈值，分派继续，同时通知团队负责人关注队列。
- 达到超限阈值，新工单进入排队区，按到达时间排序，团队负责人可在两小时内决定是否转交备选团队。
- 备选团队同样超限，工单保留在排队区并升级给分派协调人，由协调人协调临时支援或调整优先级。
- 涉及重点客户或明确时限的工单，受理人可直接标记加急，加急工单跳过排队，由团队负责人指定处理人。
规则冲突主要出现在类型映射缺失或一个工单涉及多个模块时。处理方式是：映射缺失的工单进入待定类型队列，由协调人当日判定并补录映射；多模块工单按主要影响模块归属，次要模块以协作任务形式挂接。例外处理必须记录原因、处理人和时间，每周汇总一次用于修订规则。
角色分工与交付物
分派机制涉及四个角色，各自在分派环节有明确的输入和输出：
| 角色 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 受理人 | 判定问题类型，核对映射表，提交分派 | 工单内容、用户描述、截图日志 | 带类型标记的工单、判定依据 |
| 团队负责人 | 确认团队负载，处理超限转交，指定加急处理人 | 团队负载视图、排队区工单 | 转交决定、处理人指定记录 |
| 处理人 | 接收工单，确认可处理或申请改派 | 分派通知、工单详情 | 接单确认或改派申请及理由 |
| 复核人 | 抽查类型判定与分派结果，汇总误判 | 分派记录、改派记录 | 复核结论、规则修订建议 |
改派与复核都要留记录。改派记录包含原处理人、新处理人、改派原因、改派时间；复核记录包含抽查工单编号、类型判定是否正确、分派是否符合规则、处理意见。记录字段在工单系统中固定下来，避免口头改派无法追溯。
这些字段和视图可以在工单管理工具中承载。ONES 的工单对象支持自定义类型字段和团队归属字段，团队负载可以通过工作项视图按负责人和状态统计待处理数量，分派与改派动作保留在工单操作记录中，复核人可按周筛选分派记录进行抽查。规则本身仍由团队约定，工具负责让类型、负载和记录在同一处可见。
一个完整分派示例
以下为演示情景，用于说明分派过程，数据为示例值。
某工单描述：客户反馈“批量导入订单后，部分订单状态显示为待确认，无法进入发货流程”，附有导入文件和截图。受理人核对后判定：一级分类为订单模块，二级分类为故障类，故障现象为数据不一致，类型编号T-ORDER-01，判定依据是涉及订单状态流转和批量导入功能。受理人将类型和依据写入工单，提交分派。
系统按映射表确定责任团队为订单服务组。此时订单服务组加权工作量为基准线的1.3倍，处于预警区间，分派继续。团队内三名处理人的当前加权工作量分别为12、9、15，具备该类型权限的是前两人，选择工作量9的处理人A。分派完成，通知团队负责人关注队列。
处理人A接单后发现导入文件涉及支付模块的状态同步，申请改派或增加协作。团队负责人确认后，保留A为主处理人，挂接支付平台组一名处理人作为协作，改派记录写明原因“涉及支付状态同步，需协作处理”，记录时间和确认人。复核人在周度抽查中核对该工单的类型判定和改派记录，确认符合规则。
上线后的完成检查
分派机制上线后，按以下清单逐项核对，判断是否按设计运行：
| 检查项 | 判断标准 | 检查频率 | 责任人 |
|---|---|---|---|
| 类型映射覆盖率 | 已归入明确类型的工单占比，待定类型工单应逐条有判定记录 | 每周 | 分派协调人 |
| 类型误判率 | 复核抽查中类型判定错误的工单占比，误判集中出现在哪些类型 | 每周 | 复核人 |
| 负载阈值触发情况 | 预警和超限触发次数、触发后转交是否在约定时间内完成 | 每周 | 团队负责人 |
| 人工改派比例 | 改派工单占全部分派工单的比例，改派原因分布 | 每月 | 复核人 |
| 分派时效 | 从工单提交到处理人接单的时长，是否在约定范围内 | 每周 | 分派协调人 |
| 积压情况 | 排队区工单数量和最长等待时长，是否出现持续积压 | 每周 | 团队负责人 |
检查结果用于修订三张基础表：误判集中的类型补充判定依据或拆分类型；改派比例高的映射调整责任团队；阈值频繁触发且转交不及时的，复核权重设置和人员配置。检查频率建议前两个月每周一次，稳定后改为每月一次，由分派协调人汇总，团队负责人和复核人共同确认修订项。
常见问题
问题类型划分到什么粒度比较合适？
建议以产品模块作为一级分类、诉求性质作为二级分类、故障现象作为标签补充。判断标准是：受理人对照工单描述、截图或日志能在几分钟内完成归类，同时责任团队可以唯一确定。如果某类工单频繁出现“待定类型”，说明分类过粗或判定依据不足，应补充判定依据或拆分类型；如果受理人普遍反映判断困难，说明分类过细，可合并相近类型。
团队负载数据需要实时采集吗？
取决于分派频率。工单量大、分派频繁的团队，待处理工单数建议实时或每小时更新，保证选人时看到的是当前队列；加权工作量涉及复杂度折算，按日更新即可。平均处理时长用于趋势判断和阈值校准，每周统计一次近30天数据。采集频率过高会增加维护成本，过低则分派依据滞后，可按团队实际分派节奏选择。
责任团队整体超限，但备选团队也不空闲，工单怎么处理？
工单保留在排队区，并升级给分派协调人。协调人可采取三种方式：协调其他团队临时支援、与业务方沟通调整优先级、或由团队负责人指定人员加班处理。无论哪种方式，都要在工单记录中写明处理决定、决定人和时间，便于后续复盘。持续出现备选团队也超限的情况，说明人员配置或类型映射需要调整，应在月度检查中处理。
一个工单涉及多个产品模块时，责任团队怎么定？
按主要影响模块归属责任团队，次要模块以协作任务形式挂接到主工单上，由主处理人协调。判定主要影响模块的依据是：故障发生在哪个环节、影响哪个业务结果、用户最关心的问题落在哪个模块。如果两个模块影响相当，可由分派协调人与相关团队负责人确认后指定主责团队，并把判定过程写入工单记录。
分派规则上线后多久评估一次比较合适？
建议前两个月每周检查一次，重点看类型映射覆盖率、误判率和阈值触发情况，及时修正明显偏差；运行稳定后改为每月一次，增加人工改派比例和积压情况的趋势分析。每次检查结果对应到三张基础表的修订：补判定依据、调责任团队、校准权重和阈值。修订项由分派协调人汇总，团队负责人和复核人共同确认后生效。
