客户工单该转需求还是关联缺陷，判断依据是两条：客户期望的行为在产品中是否已有既定依据，以及问题能否在现有版本上复现。有既定依据却未达到、可复现，按缺陷处理；现有能力覆盖不到的新行为、新规则，按需求进入规划评估。一张工单同时包含两类内容时，拆成两条工作项分别流转，原工单保留为客户侧统一入口。下面给出判定规则、操作步骤、角色分工、拆分示例和完成检查清单。
要点总览（TL;DR）
- 判定看两点：客户期望的行为在产品文档、合同或已发布版本中是否有既定依据，以及问题能否在现有版本稳定复现；有依据且可复现走缺陷，无依据的新行为走需求。
- 配置或使用问题、客户侧数据问题留在工单侧闭环；客户定制诉求即使实现量小也按需求受理，避免以缺陷名义绕过规划评估。
- 一张工单同时含缺陷和新诉求时拆成两条工作项分别流转，原工单保留为客户侧统一入口，两条工作项都回链原工单。
- 一线支持负责信息采集与初判，二线或技术支持负责复现与技术定性，产品负责人给出需求受理结论，研发与测试负责确认和验证，交接以交付物为准。
- 转出后按双向关联、状态同步时限、客户回复节点、重复合并规则逐项检查，按月抽样复盘分流准确率并回写判定规则。
先判断性质：一张工单该走缺陷还是需求
分流动作发生在受理阶段，目标是让工单在进入研发之前就有明确去向。判定时不要从客户语气或诉求紧急程度出发，而要看两件事：这条工单指向的行为，在产品文档、合同约定或已发布版本中是否有既定依据；以及按现有版本操作，问题能否稳定复现。两个问题都得到肯定回答，走缺陷；期望行为没有既定依据，走需求。
判定规则可以整理成下面这张表，支持人员在受理时逐行对照，得到结论后直接进入对应去向。
| 判定问题 | 结论 | 对应去向 |
|---|---|---|
| 产品文档、合同或已发布版本中是否写明了该行为？ | 有依据，实际表现与依据不符 | 关联缺陷，进入研发修复 |
| 按工单提供的环境与步骤，能否在现有版本复现？ | 可复现，且行为与既定依据不符 | 关联缺陷，附复现步骤 |
| 客户期望的行为是否超出当前产品能力范围？ | 无既定依据，属于新行为或新规则 | 转为需求，进入规划评估 |
| 客户要求针对其业务做专属配置或定制开发？ | 标准能力不覆盖，需评估投入 | 转为需求，标注定制属性 |
| 操作方式与文档不一致，但按文档操作可正常使用？ | 使用或配置问题 | 留在工单侧答复，不建研发工作项 |
| 数据异常由客户侧导入或历史数据造成？ | 数据问题，产品逻辑正常 | 留在工单侧处理，必要时提供修复指引 |
三类边界情形需要单独说明。配置或使用问题常被误报为缺陷，判定时先核对客户操作路径与文档说明，能通过调整配置恢复的，按使用问题在工单侧闭环。数据问题要看异常是否由产品逻辑产生，若同一操作在干净数据上无法复现，优先排查客户数据来源。客户定制诉求即使实现量很小，也按需求受理，避免以缺陷名义绕过规划评估，导致研发排期被临时插入。
判定所需的输入包括：产品版本与环境信息、可执行的复现步骤、客户期望结果与实际结果的对照、影响范围（单客户还是多客户、是否影响核心业务）。判定由一线支持完成初判，二线或技术支持负责复现与技术定性；涉及能力边界或定制投入的，交由产品负责人确认。初判结论要记录在工单上，便于后续复盘时区分判定错误与信息不足。
分流操作步骤：从受理到建立研发工作项
判定完成后，分流要落到具体动作。每一步都应有明确的输入、动作、输出和完成标志，避免工单在“已转研发”的状态里失去跟踪。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 受理登记 | 客户提交的原始描述、联系方式、合同或服务等级信息 | 建立工单，记录客户、产品模块、发生时间 | 工单编号与基础信息 | 工单已登记并可被检索 |
| 2. 信息补全 | 工单基础信息 | 向客户或现场人员收集版本号、环境、复现步骤、截图或日志、影响范围 | 结构化的工单描述 | 复现步骤可被他人按序执行 |
| 3. 判定与打标 | 补全后的工单 | 按判定规则表得出结论，打上缺陷、需求或使用问题标记 | 带分类标记的工单 | 标记与判定结论一致，并记录判定人 |
| 4. 建立关联工作项 | 判定结论与工单信息 | 缺陷类建立缺陷工作项并附复现步骤；需求类建立需求条目并写清业务场景与期望行为 | 研发工作项及与工单的关联关系 | 工单上可见关联工作项编号，双向可跳转 |
| 5. 回写工单状态 | 关联工作项 | 将工单状态更新为“已转缺陷”或“已转需求”，并给客户可见的阶段性回复 | 状态更新记录与客户回复 | 客户收到回复，工单状态与关联工作项一致 |
| 6. 无法判定时升级 | 信息不全或性质存疑的工单 | 升级至二线或产品负责人，约定回复时限 | 升级记录与判定结论 | 在约定时限内给出定性结论并回到步骤3 |
第4步是分流的关键动作。缺陷工作项应包含版本、环境、复现步骤、期望结果与实际结果；需求条目应包含客户业务场景、当前做法、期望行为、影响客户数量与商业价值。两类工作项都要回链原工单，工单也要记录工作项编号，形成双向关联。分流后需要在同一平台内维护工单与需求、缺陷的关联和状态同步时，ONES 可以把工单、需求、缺陷放在同一工作项体系里，通过关联关系与状态流转保持客户侧与研发侧信息一致；具体配置按团队现有流程设定。
无法判定时不要强行归类。常见情形是复现条件缺失、客户描述与产品能力边界不清、或涉及多产品组合。此时升级到二线或产品负责人，明确谁在什么时限内给出结论，结论回来后仍按第3步打标，保持流程一致。
角色分工与各环节交付物
分流准确率取决于每个角色是否清楚自己交付什么。支持侧负责把客户语言转成可验证的技术描述，产品侧负责判断能力边界与优先级，研发与测试负责确认与验证。职责按下表划分，交接以交付物为准，不以口头同步为准。
| 角色 | 主要职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 一线支持 | 受理登记、信息采集、初步分类 | 完整工单记录、客户期望与实际结果对照 | 二线或技术支持 |
| 二线或技术支持 | 复现问题、技术定性、判断是否可复现 | 复现记录、日志或截图、缺陷或需求的初步结论 | 产品负责人、研发 |
| 产品负责人 | 需求受理、能力边界确认、优先级判断 | 需求条目、优先级结论、是否纳入规划的答复 | 研发、支持 |
| 研发 | 缺陷确认、修复方案与排期 | 缺陷确认结论、修复版本、根因说明 | 测试、支持 |
| 测试 | 修复验证、回归范围确认 | 验证记录、回归结论 | 支持、产品 |
一线支持容易把“客户很着急”当作升级理由，实际应交付的是可复现的信息。二线完成复现后，若确认是缺陷，交付物中要写明影响版本与影响范围，供研发判断修复优先级；若确认是需求，交付物中要写清现有能力为何覆盖不到，供产品评估。产品负责人的交付物是明确的受理结论，包括纳入规划、暂缓或不予受理及理由，这个结论要回写到工单，支持人员据此回复客户。
研发与测试的交付物决定工单能否闭环。缺陷修复后，测试的验证记录要覆盖原复现步骤，并说明回归范围；支持据此回复客户并关闭工单。需求类工作项在规划评审后同样要回写结论，即使结论是暂不排期，也要让客户侧知道当前状态，避免工单长期悬空。
示例：一张混合工单如何拆成缺陷与需求
以下为演示情景。某客户提交工单，描述为：“批量导入订单时，系统提示成功但部分订单没有生成；另外希望能按客户等级自动设置审批流，现在每次都要手工选。”
这张工单包含两个不同性质的问题。前半段“提示成功但订单未生成”指向产品已有行为：导入功能应完整生成订单，提示成功与实际结果不符，且按客户提供的文件可在测试环境复现，属于缺陷。后半段“按客户等级自动设置审批流”是客户期望的新规则，现有产品只支持手工选择审批人，属于能力未覆盖的新诉求，应转为需求。两部分混在一张工单里，直接整体转研发会导致缺陷修复被需求评估拖慢，需求也可能被当作缺陷临时排期。
拆分后两条工作项的关键字段如下。
| 字段 | 缺陷工作项 | 需求条目 |
|---|---|---|
| 标题 | 批量导入订单提示成功但部分订单未生成 | 支持按客户等级自动匹配审批流 |
| 来源 | 原工单编号，关联客户与合同信息 | 同一工单编号，标注客户与提出时间 |
| 环境与版本 | 客户生产环境版本号、导入文件样例 | 客户当前使用版本、业务场景说明 |
| 复现步骤或业务场景 | 按序列出导入操作、文件规模、失败订单特征 | 描述客户等级划分规则、期望的审批匹配逻辑 |
| 期望与实际 | 期望全部生成，实际缺失部分订单且无报错 | 期望自动匹配，当前需手工选择 |
| 影响范围 | 该客户批量导入场景，需确认是否影响其他客户 | 该客户及其下游客户，评估同类客户数量 |
| 处理结论 | 研发确认后给出修复版本 | 产品评审后给出是否纳入规划 |
关联方式上，两条工作项都回链原工单，原工单状态改为“已拆分”，并在工单内注明两条工作项编号。对客户的回复分两段：缺陷部分说明已复现并进入修复，给出预计反馈节点；需求部分说明已受理并进入评估，评估结论出来后再同步。后续跟踪以两条工作项各自的状态为准，客户侧仍通过原工单获取统一答复，不需要分别对接研发和产品。
流转后的跟踪与完成检查
分流完成不等于流程结束。工单转出后最常见的失效情形是关联断裂、状态不同步、重复建单和判定偏差无人复盘。下面这份检查清单可用于日常抽查和周期性复盘。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 双向关联完整性 | 工单可见关联工作项编号，工作项可见来源工单，两侧均可跳转 | 一线支持 |
| 状态同步 | 工作项状态变化后，工单状态在约定时限内更新 | 二线或技术支持 |
| 客户回复节点 | 转出时、结论确定时、修复或规划结论发布时各有一次客户可见回复 | 一线支持 |
| 重复工单合并 | 同一客户同一问题的多张工单合并到一条主工单，其余标注关联 | 一线支持 |
| 重复缺陷合并 | 同一根因的缺陷工作项合并，保留最早一条并关联其余来源工单 | 研发 |
| 分流准确率复盘 | 按月抽样已分流工单，统计误判为缺陷的需求、误判为需求的使用问题比例，并分析原因 | 产品负责人与支持主管 |
状态同步要明确时限，例如工作项进入修复或评审后一个工作日内更新工单，避免客户长时间得不到反馈。重复工单的合并规则要区分“同一客户重复提交”和“不同客户反映同一问题”：前者合并工单，后者保留各自工单但关联同一缺陷或需求，以便统计受影响客户数量。
分流准确率复盘的重点不是追责，而是找出规则盲区。若某类需求反复被误判为缺陷，说明判定规则表需要补充该场景的判定问题；若使用问题大量进入研发，说明一线支持的信息采集或文档指引需要加强。复盘结论应回写到判定规则和操作步骤中，让下一轮分流更稳定。完成检查以清单逐项打勾为准，抽查记录留存，作为流程是否有效的依据。
常见问题
客户坚持认为这是缺陷，但按文档属于新需求，怎么处理？
先把事实摆清楚：调出产品文档、合同约定或已发布版本中的对应说明，向客户说明当前产品的既定行为是什么，以及客户期望的行为属于新增规则。同时确认问题在现有版本上的实际表现，避免把真实缺陷误判为需求。若客户仍不接受，按需求受理并标注客户异议，由产品负责人在评估结论中给出明确答复，支持人员据此回复客户。判定结论和依据要记录在工单上，便于后续复盘。
问题无法复现时，应该先转缺陷还是先留在工单侧？
无法复现时先不建立缺陷工作项，把工单留在支持侧继续收集信息：确认客户环境与版本、补充操作步骤、索取日志或截图、尝试在相同数据条件下复现。信息补齐后仍无法复现的，升级到二线或产品负责人定性，约定回复时限。若后续在其他客户环境复现，再按缺陷建立工作项并关联原工单。这样处理可以避免研发收到无法验证的缺陷单，也保留问题再次出现的入口。
同一客户就同一问题重复提交多张工单，拆分和合并怎么把握？
先判断是否同一问题：同一客户、同一产品模块、同一现象，合并到一条主工单，其余工单标注关联并告知客户统一在主工单跟踪。不同客户反映同一问题时，各自保留工单，但关联到同一条缺陷或需求工作项，便于统计受影响客户数量。拆分只针对一张工单内性质不同的内容，例如缺陷加新诉求；同一性质的问题不因客户催问而重复建单。
需求转出后长期没有规划结论，工单该如何跟踪？
需求条目的受理结论本身就是交付物，产品负责人应给出纳入规划、暂缓或不予受理及理由，并回写到工单。若评估周期较长，支持人员按约定节点向客户同步当前状态，说明仍在评估中，避免工单长期悬空。跟踪以需求条目的状态为准，客户侧仍通过原工单获取统一答复。复盘时可统计需求从受理到结论的平均时长，作为流程改进依据。
分流准确率复盘应该看哪些数据？
按月抽样已分流工单，重点统计三类偏差：被误判为缺陷的需求、被误判为需求的使用或配置问题、以及拆分不完整的混合工单。结合判定人记录分析原因，区分信息不足与规则盲区。若某类场景反复误判，补充判定规则表中的判定问题；若使用问题大量进入研发，加强一线支持的信息采集和文档指引。复盘结论回写到判定规则和操作步骤，形成闭环。
