客服替顾客开单，Requester、Submitter和Assignee各是谁

外包客服整理工单时，一句“这张单由甲提出”可能混合了求助者、录入者和接手者。Zendesk词汇表与入门课程将这几种关系分别命名：Requester是通过工单寻求支持的人；Submitter是实际创建工单的人；某位客服被分派处理该工单后，成为Assignee。它们描述同一张记录里的不同角色，姓名相同或不同，都需要结合字段的含义理解。

顾客自己提交请求时，默认情况下Requester与Submitter可以是同一个人。词汇表随后给出的反例是客服代顾客开单：顾客是Requester，客服是Submitter。因此，“实际创建了记录”与“这份支持请求意在帮助谁”可以分离。对外包服务交接，保留这两种身份有助于解释为何工单来自客服账号，却仍然表达一位顾客的求助。

官方《Creating a ticket on behalf of the requester》用电话支持说明这种代建情形，并特意限定为没有使用会自动创建工单的Zendesk电话方式。客服想将电话中的请求记录下来，可以替对方建立工单。这里的例子说明一个请求怎样对应另一位录入者，并不要求本文假定所有电话都会自动开单，或把每一位来电者都视作已有系统记录。

该文另有一项直接影响字段解释的默认条件：公开工单由客服代建时，需要将终端用户列为Requester；如果Requester没有填写，客服自己会成为Requester。因此，看见Requester里是某位客服，并不足以反推实际求助者一定就是该客服。本文没有修改字段，而是提醒资料阅读者，默认身份可能来自创建情形，不能在缺少记录时自行补写顾客姓名。

两种创建相关身份的可变性也不同。词汇表明确说Requester可以改变，Submitter不能改变。前者表达请求要帮助的人，后者保留实际创建者身份。把二者都简写成“提交人”，会让后续资料难以解释：为何请求对象可以调整，而创建记录的人仍保持原来那位。这是角色语义的差别，不是对某个服务过程是否规范作判断。

Assignee又回答谁接手处理的问题。入门课程的角色段说，一位客服被分派到工单后就是Assignee；客服替顾客开单时仍是Submitter，邀请其他内部用户查看工单时，那些人属于Followers。由此可见，参与一张工单不只有一种关系。本文将受理、创建、求助与跟进参与分别表达，不据某人的出现就推定他同时承担全部角色。

本篇采用三份Zendesk正式文字的上述定义及邻接，页面发布证据为2021年10月16日，后续更新不当作首次发布。它供客服资料交接辨认角色，不提供账号、通知或权限配置，也不评价服务时限与合同履行。清楚保留角色名称，才能说明记录中每个姓名所对应的具体关系。