摘要

  • 源工单的历史评论仍可查阅，但标签、类型、优先级和状态不会自动继承到合并目标。
  • 合并关闭标记、回复数计算和抄送规则各有边界；工单列表变整齐，不能直接证明支持工作减少或客户问题解决。

先确定报表在数什么

一张支持报表，在解释成绩之前，已经做了一个选择：它数的是所有进入系统的请求，还是合并之后留下的工作工单？在Zendesk，这不是抽象的统计争论。系统为因合并而关闭的工单添加标记，官方Explore指南提供了排除这类记录的做法。报表的变化，因此可能来自记录身份的重新组织，而不只是支持团队工作的变化。

合并本身并没有错。客户为同一问题提交两次请求，放在一个地方跟进可能更合理。需要审慎解释的是操作结果：系统选择一个目标，关闭一个来源，并形成新的工作记录。这个行政结果，不能独自回答客户是否得到了更好的帮助。

官方合并规则明确区分来源字段与目标字段。来源的标签、类型、优先级和状态不会被带入目标，保存的是目标工单已经填写的字段。因此，合并并不等于系统替团队完成了一次字段协调，也不等于所有重要分类都找到了正确位置。

可以用一个假设看清这条边界：两个相关请求被标成不同的严重程度。把它们合并，不足以证明较高的优先级自动成为目标的优先级。团队可能有充分理由选择某个目标，但保留下来的分类，仍需要与这个理由相互解释。本文没有检查实际客户账户，这不是某个客户配置失误的案例。

市场意义在于企业能否继续解释自己的支持证据，而不是一个未经证实的收费项目。工单记录会被用于判断重复问题、安排人员和评价服务。软件能把请求放在一起，与采购方能读懂合并后的记录，是两种能力。

这也使本篇区别于关于Zendesk席位价格或AI是否真正完成解决任务的讨论。当前研究的对象，是合并改变了哪些字段来源和报表记录范围。一个组织即使理解了“关闭不等于解决”的原则，也可能误读目标工单，以为它已经承接了来源的全部分类。

历史可查，不等于目标完整复制

Zendesk说明，之前的评论仍可在合并关闭的源工单中查阅。因此，把合并描述为抹掉全部历史是不准确的。反过来，留有历史访问路径，也不意味着目标工单已经直接展示了来源的全部评论和字段。

在普通合并界面中，来源最近一条公开评论会出现在合并窗口。操作人员可以修改或移除它；否则，它会进入目标的合并评论，并附上指向已关闭工单的链接。其他历史评论不直接出现在新工单里，而是保留在旧工单中供查阅。

这里改变的是阅读路径。只看当前工单的人，与沿链接检查源工单的人，可能接触到同一支持过程的不同部分。不能据此声称历史已经消失，也不能假定当前工作记录呈现了完整的历史上下文。

附件又是另一种转移。Zendesk开发者文档说明，源工单附件会复制到目标，并可能进入目标评论。复制的附件、通过链接查看的旧评论，以及只保留目标值的字段，属于不同的证据形态。不能用其中一种“保留”去证明其他两种也完成了同样的继承。

因此，合并需要一个理解上下文的责任人，而不只是一个有权限点击按钮的人。这个责任人要判断：目标记录的哪些内容，应当帮助后来者准确理解组合后的问题；哪些来源差异，需要明确保留说明，而不能被目标的现有值悄悄代替。

排除一批记录，不必然改善一个指标

源工单会获得合并关闭标签closed_by_merge。官方Explore示例提供了排除这类工单的报表方法，同时合并规则提示，不能基于合并关闭工单的字段生成相应报表。这是文档所述的报表限制，不应扩大成底层记录被物理删除，或者所有独立审计分析都不可能。

排除合并来源，可能适合“有多少个独立工作案例”这个问题，却未必适合“进入了多少次请求”这个问题。产品提供筛选能力，不替组织决定报表到底要回答哪一个问题。记录范围应当与结果一起被说明。

按回复次数计算的指标尤其需要这一层解释。Zendesk关于一次回复工单的FAQ，将其描述为回复少于两次的已解决或已关闭工单，并说明合并评论默认进入这个计算；文档也解释了如何排除合并工单。因此，合并处理不是与指标无关的整理工作。

但不能进一步声称，每一次合并都会把某个比率变得更好。历史回复、合并评论、筛选条件和计算方式会共同决定方向。本文没有观察任何客户的比率变化。可以成立的结论是：比较前后成绩，需要同样清楚的计入范围与评论处理规则。

报表并不会因为排除某类记录就自动失真。真正的问题，是解释结果时忘记了这个排除。列表中的条目减少，可能反映工单组织方式改变；它本身不证明工作负担减少，也不证明客户体验改善。那些结论还需要适合它们的证据。

内部备注只控制这条备注

收件人是另一条独立边界。根据普通合并规则，启用抄送时可以合并不同请求人的工单：被关闭来源的请求人会成为目标工单的抄送人，原工单已有抄送人也会被加入。没有启用抄送时，普通规则则要求相同请求人。

把合并评论设为内部备注，不等于通过这一个动作移除了加入对话的人。与此同时，新增抄送人也不等于所有旧的内部备注都会公开。当前工单有哪些参与者，与某一条评论是否对他们可见，需要分开检查。

普通界面允许选择公开回复或内部备注；关联工单建议的合并流程，则提供请求人与抄送人能否看到合并评论的选择。实际使用的是哪一种流程、最后保存了什么文本和可见性，比假设所有界面拥有相同默认值更重要。

甚至清空文本框，也不能被理解成“不会生成任何评论”。Zendesk说明，移除全部合并评论文本后，来源最近的评论可能成为更新后的评论。操作人员需要检查最终文本，而不能仅凭清空动作判断结果。

API还有自己的默认值与限制：合并评论默认私密，但可在规定条件下通过隐私参数改变；当来源或目标属于私密工单，或者涉及文档列明的社交渠道时，则存在特定的私密限制。这不是所有界面的统一默认值，更不是对某个客户设置的调查结论。

警告、权限与完成结果各有范围

界面会对不同组织、品牌或请求人的合并发出警告。但当前API文档还说明，启用品牌隔离时，合并限于同一品牌。警告不等于跨越所有边界的授权证明。人员角色与Enterprise账户的合并权限，也属于操作成立的条件。

API返回任务状态对象，并为合并安排后台工作；文档要求检查完成情况。不能把首次响应说成一定处于排队状态，因为当前示例可以展示已完成结果。更重要的区别，是请求被接受、记录合并完成，以及客户问题得到解决，并不属于同一个结果。

本篇没有调用客户Zendesk API，没有更改工单、标签、角色、抄送或附件，也没有测量节约时间、积压减少和隐私事件。官方资料支持的是产品机制；“采购方应当保有解释合并证据的能力”，是建立在这些机制上的编辑分析。

Zendesk将合并描述为永久且不可撤销，同时又保留了旧评论的查阅路径。这两件事可以同时成立。历史可查帮助团队解释决定，却不能恢复原来的工单安排，更不能事后证明目标、报表口径与对话收件人都选得正确。

来源