工单协办分工的关键，是把一张工单的处理权拆清楚：谁负责推进、谁提供支持、什么条件下转给谁。本文给出一份可直接参照的填写示例，用一张跨团队工单演示主责人、协办人、转派条件和交接记录如何逐项填写，再解释每个字段的填写依据与可迁移规律。本文只讨论处理权分配，升级时限与优先级归SLA管理，状态流转设计归流程管理，均不展开。
要点总览（TL;DR）
- 工单协办分工的核心是把处理权拆成三部分：主责人唯一、协办人按需、转派条件可判断，交接时留下最小记录。
- 示例中主责人对最终答复和关闭负责，协办人只对指定环节的支持产出负责，转派后原主责人保留协办身份以保证客户沟通连续。
- 转派条件应写成接手人一看就能判断真假的句子，并写明接收角色和原主责人的新身份，避免责任真空。
- 迁移到其他团队时，按工单类型调整协办角色，按团队规模调整主责与受理是否分离，并把规则写进工单模板定期维护。
- 示例为演示情景，涉及升级时限与优先级应参照SLA管理，涉及状态流转设计应参照流程管理。
这份示例要解决的分工问题
跨团队工单最常见的卡点，是工单挂在一个“处理人”名下，但实际推进需要多个角色配合：有人做判断和决策，有人提供专业输入，有人在条件不满足时把工单交给更合适的团队。如果这些关系只靠口头约定，工单就会在几个部门之间来回询问，责任边界随沟通次数增加而变模糊。
本示例要回答三个分工问题：第一，谁对工单的最终结果负责并推动它往前走；第二，谁在特定环节提供支持，支持到什么程度算完成；第三，当出现哪些可判断的情况时，工单应转给哪个角色或团队。围绕这三个问题，示例覆盖以下字段范围：
- 主责人：对工单结果负责、做处理决定、推动状态前进的人。
- 协办人：在指定环节提供信息、判断或操作支持的人，各自的支持内容写清楚。
- 转派条件：触发转派的判断条件，以及转派后的接收角色。
- 交接记录：转派或协办交接时留下的最小信息，保证接手人不需要重新问一遍。
需要说明的是，本文不涉及升级时限设定、优先级判定和状态流转设计。这些内容分别属于SLA管理和流程管理的范畴，与处理权分配是两件不同的事：前者决定“多久必须处理完”，后者决定“由谁处理、谁来配合”。
完整示例：一张跨团队工单的分工填写
以下情景为演示用示例，人物、团队和工单内容均为虚构，不代表任何真实组织的实际做法或效果。
情景设定：某企业服务团队的客服人员受理了一张工单，客户反馈“批量导入成员时部分账号未生效，且提示信息不明确”。该问题涉及客服、产品支持和研发三个角色，需要分工处理。
工单基本信息与主责人
| 字段 | 填写内容 |
|---|---|
| 工单标题 | 批量导入成员部分账号未生效，提示信息不明确 |
| 工单来源 | 客户提交，客服受理 |
| 问题描述 | 客户导入200条成员数据，其中约30条未生效，页面仅提示“部分失败”，未说明失败原因 |
| 主责人 | 产品支持工程师 A |
| 主责职责说明 | 负责判断问题性质、组织协办人排查、对客户给出最终答复并关闭工单 |
协办人字段填写
| 协办人 | 支持内容 | 期望产出 |
|---|---|---|
| 客服专员 B | 补充客户环境信息与复现步骤 | 整理一份包含导入文件样例、操作时间和页面提示截图的说明 |
| 研发工程师 C | 排查导入失败的技术原因 | 给出失败原因判断，并说明属于数据问题还是产品缺陷 |
转派条件与转派记录
转派条件写成可判断的句子，避免“情况复杂时转研发”这类模糊描述。示例中填写为：
- 若研发工程师 C 判定为产品缺陷，则主责人将工单转派至研发团队，由研发指定修复负责人，原主责人转为协办，负责对客户沟通。
- 若判定为客户数据格式问题，则工单不转派，由主责人整理正确格式说明并回复客户。
- 若客户在两个工作日内未补充复现信息，主责人记录情况后与客户确认是否继续跟进。
转派记录填写为：“研发工程师 C 于排查后判定为导入校验逻辑缺陷，工单转派至研发团队，接收人研发工程师 D；原主责人产品支持工程师 A 保留协办身份，负责客户侧沟通。”
交接说明与关闭前确认
交接说明记录三件事：已确认的事实、未解决的问题、接手人需要做的下一步。示例中填写为：“已确认失败集中在含特殊字符的成员名称；已排除客户操作错误；待研发修复校验逻辑后由客户重新导入验证。接手人需在修复版本发布后通知主责人，由主责人联系客户验证。”
关闭前确认记录填写为：“客户确认重新导入成功，失败条目已全部生效；主责人核对协办人产出均已归档；工单关闭。”
逐项解释：每个字段为什么这样填
主责人与协办人的区分依据
区分标准是“谁做决定、谁对结果负责”。主责人只有一个，他对工单的最终答复和关闭负责，即使排查工作由研发完成，对客户的答复仍由主责人发出。协办人按环节提供支持，支持内容完成即视为履职，不承担工单整体推进责任。示例中研发工程师 C 负责技术判断，但“是否转派、如何回复客户”由主责人决定，这样避免工单在多人之间出现“都以为对方在跟”的情况。
协办人数量与角色的控制原则
协办人按实际需要的支持环节设置，每个协办人都要写明支持内容和期望产出。示例中只设两名协办人，是因为问题只涉及信息补充和技术判断两个环节。协办人过多会让责任分散，也容易让主责人难以判断哪个支持已经到位。一个实用的控制方法是：每增加一名协办人，就问一句“他提供的东西，主责人自己或现有协办人能否提供”，不能回答再增加。
转派条件写成可判断条件
转派条件应写成接手人一看就能判断真假的句子。示例中“判定为产品缺陷则转研发”是可判断的，因为研发工程师 C 的产出就是“属于数据问题还是产品缺陷”的结论。相比之下，“问题严重时转研发”“需要技术支持时转派”这类描述，判断权仍在个人经验里，不同人执行结果不同。转派条件还应写明转派后的接收角色和原主责人的新身份，否则转派后容易出现责任真空。
交接记录的最小信息
交接记录至少包含三项：已确认的事实、仍未解决的问题、接手人的下一步动作。这三项决定了接手人是否需要重新向客户或前一位处理人询问。示例中的交接说明正是按这三项组织的。缺少“未解决问题”这一项时，接手人容易重复已经排除的排查方向。
常见填错方式及其后果
| 填错方式 | 后果 |
|---|---|
| 主责人填成“客服团队”这类群体名称 | 无人对结果负责，工单停留在待处理状态 |
| 协办人只写名字，不写支持内容 | 协办人不知道自己该做什么，主责人无法判断支持是否完成 |
| 转派条件写成“视情况转派” | 转派依赖个人判断，同类工单处理路径不一致 |
| 转派后原主责人直接退出 | 客户侧沟通断档，客户需要向新接手人重复描述问题 |
| 交接记录只写“已转研发” | 接手人需要重新排查已确认的事实，处理时间被拉长 |
当这类分工需要在系统中长期执行时，工单的主责、协办和转派关系需要有稳定的承载位置。ONES Desk 面向企业服务与协作场景，支持集中管理工单状态、处理进度和责任分工；对于需要多个角色共同响应、分派和解决问题的场景，可以建立统一的协作入口和处理流程。工单还可关联到待办事项列表，或一键关联到 ONES Project 的需求、缺陷工作项，便于跨部门持续跟踪到处理完成。字段名称和配置方式可按团队实际需要设计。
可迁移规律：换一个团队怎么改这份示例
示例中的具体人名和团队不能直接套用，但分工结构可以复用：主责唯一、协办按需、转派有条件、交接留记录。迁移时主要调整以下四处。
按工单类型调整协办角色
不同类型的工单，协办环节差别很大。咨询类工单可能只需要一名协办人提供知识库条目；故障类工单往往需要技术排查和客户沟通两条线；涉及合同或权限的工单，协办人可能是法务或系统管理员。调整方法是先列出该类工单从受理到关闭必须经过的判断环节，每个需要他人输入的环节对应一名协办人，并写明期望产出。
团队规模变化时的调整方向
- 小团队（数人）：主责人可由受理人兼任，协办人控制在1至2名，转派条件以“是否超出本团队职责范围”为主。
- 中等团队：主责人与受理人分离，按工单类型预设协办角色，转派条件细化到具体判断结论。
- 多团队协作：明确每个团队的接收角色而非具体个人，转派记录中同时保留原主责人的协办身份，保证客户侧沟通连续。
分工规则与工单模板的维护方式
把主责、协办、转派条件写进工单模板，新工单创建时按模板带出字段，减少每次临时约定。模板维护建议固定一个责任人，按季度或在出现以下情况时更新：同类工单反复因同一条件转派、协办人长期无实际支持内容、交接记录频繁缺失关键信息。更新时保留旧版本记录，便于对照历史工单的分工方式。ONES Desk 支持自定义工单属性和灵活调整工作流，可作为承载这类模板与流转规则的选项之一，具体配置需结合团队实际流程设计。
适用边界：这份示例在什么情况下要改
示例假设的协作前提是：团队已有明确的工单受理入口，主责人与协办人分属可识别的角色，且工单处理以单个团队内部推进为主、跨团队情况有限。若团队尚未统一受理入口，或角色职责本身还在变动，示例中的字段填写会缺少稳定依据，应先理顺角色再套用。
以下情形需要另行处理，不能直接照搬本示例：
- 涉及跨团队升级时限、响应时限和优先级判定时，应参照工单优先级与SLA管理的规则，本文的转派条件不替代时限约定。
- 涉及工单状态如何设计、状态之间如何流转时，应参照工单流程与状态管理，本文只说明处理权归属，不规定状态节点。
- 涉及具体产品的字段配置、权限设置和自动化规则时，需按所选产品的实际能力设计，本文示例中的字段为通用方法层面的设计。
最后需要重申，本文情景为演示示例，其中的人物、团队和处理结果均为虚构，用于说明字段填写方法，不代表任何真实组织的实际做法或效果。读者在迁移时，应以本团队的角色设置、工单类型和历史处理记录为依据，调整字段内容和转派条件。
常见问题
协办人是否必须固定为某个人，能否填团队名称？
协办人建议填到具体角色或具体人，并写明支持内容和期望产出。填团队名称时，团队内部仍需再指定一次，支持是否完成缺少明确判断点。如果某类工单长期由同一团队支持，可以在模板中预设该团队内的默认协办角色，但工单创建后应落到具体人。
转派后原主责人直接退出可以吗？
不建议直接退出。转派通常只转移技术处理或修复责任，客户侧沟通往往仍需要原主责人衔接。示例中的做法是原主责人转为协办，负责对客户沟通，直到客户确认结果。如果转派后客户需要向新接手人重复描述问题，说明交接记录和协办身份没有设置好。
小团队没有专职客服，主责人怎么设？
小团队可以由受理人兼任主责人，协办人控制在1至2名，转派条件以“是否超出本团队职责范围”为主。关键是主责人仍然唯一，不能因为人少就填成“大家一起看”。当工单量增加或工单类型分化后，再把主责人与受理人分离，并按类型预设协办角色。
分工规则写进工单模板后，多久维护一次？
建议固定一个责任人，按季度检查，或在出现以下情况时更新：同类工单反复因同一条件转派、协办人长期没有实际支持内容、交接记录频繁缺失关键信息。更新时保留旧版本记录，便于对照历史工单的分工方式。模板维护属于流程管理的一部分，与SLA时限设定分开处理。
示例中的字段可以直接在ONES Desk里配置吗？
ONES Desk 支持自定义工单属性，并可灵活调整工作流，因此主责、协办、转派条件等字段可以按团队需要设计承载方式。具体字段名称、类型和流转规则需结合团队实际流程配置，本文示例提供的是通用方法层面的字段设计，不限定产品内的具体配置形态。
