Zendesk关闭工单后的新回复，为何不能直接沿用原单优先级

一位客户回复已经关闭的Zendesk工单，新出现的记录还关联着原来的对话，是否就应拥有原单的全部字段？外包客服交接时，这种“看起来接着聊”的印象容易让人把新工单当成旧工单原地继续，忽略其独立身份。

Zendesk的Understanding follow-up tickets说明，对已关闭工单的回复会自动创建跟进工单。新单引用已关闭工单，并带入原单的大部分数据。[1] “引用”和“大部分”需要同时保留：前者说明关联，后者明确数据并非全部照搬。

原文把Priority列入不从原单带入的字段，同列还有Comments、Type、Organization、Skills及External ID。[1] 因此，在交接材料中看到原单曾经优先级较高，并不能仅凭关联关系确认新跟进单也继承了该值。另一方面，“没有从原单复制”也不等于本文已确认新单当前为空或具有某一默认值，实际状态仍需真实记录。

组与负责人的说明另有条件。页面将Group or Assignee列在例外中，但同时注明管理员可启用设置，使跟进单包含原组及负责人。[1] 若把这条写成永远不继承，就删掉了配置条件；若据此把所有例外字段都说成可以统一继承，又超出了这一注释的对象。

标签则有相反的说明：跟进单继承原单的全部tags。原文也说，Skills会在创建跟进单时根据路由规则应用。[1] 这展示了几类不同来由——直接带入、没有复制，以及依据规则应用。资料表若只放一栏“沿用原单”，就很难解释每项值究竟来自哪里。

报表还可能对渠道使用不同名称。来源说明，在Explore中，Updates history数据集的Update channel使用Closed Ticket，而Support数据集的Ticket channel使用Web。[1] 两个报表都谈跟进单，也不能跳过属性与数据集名称，直接把渠道文字差异当成数据错误。

对外包服务交接而言，可把原工单身份、新跟进工单身份、各字段来源和负责确认的记录分开呈现。这里是资料阅读思路，没有修改路由或创建触发器。客户再次发言说明发生了新的沟通，不能凭系统生成跟进单就判断原问题已解决或SLA已经达标。

该帮助页未给出可确证的首次发布日期。本篇采用其字段继承及报表口径说明，不外推任何真实账户的配置。先确认这是哪一张新单，再说明哪些信息从哪里而来，比把整份旧单状态复制到交接说明中更准确。