为用户生成的后续票保留组和受让人
每当用户写回Closed票据时，将创建一个没有Group或Assignee的后续操作。
如果原始机票被分配了一个小组或受让人，我认为这些应该在后续中保留。
这将有助于更好地跟踪后续门票。(现在他们只是迷失在“其他一切”的观点中)
-
官方的评论
大家好！
我们正在努力从我们的产品团队那里得到一些长期存在的问题的答案，我们不怪你对缺乏回应感到沮丧。与此同时，这里讨论了一个解决方案(我很抱歉我们没有早点链接到这个，我意识到这个解决方案不容易扩展):
-
我们已经创建了一个特殊的视图来捕获所有没有组和没有受让人的门票，以便不会“丢失”这些门票。如果将最后一个小组/受让人转到后续订单中，将非常有帮助，这样这些订单就不会以任何方式延迟发送到适当的资源。
-
我们当然也需要这个——当案件管理系统的全部目的是收集足够的信息来正确地安排机票时，丢失这些信息似乎是一种损失。这里我们实际上有我们需要的所有信息-将是伟大的能够使用它。这似乎更像是一个缺陷，而不是功能，我们只能从这些类型的票中推断出更少而不是更多。
-
我们也是!我们使用多品牌功能，通过根据收到的电子邮件地址自动将门票分配给不同的组，从而在品牌之间分离门票。
然而，后续的订单没有分配给任何组，因此在品牌之间的空白空间中“丢失”了，通过web门户也没有收到订单(我怀疑当我们激活帮助中心时，它也会是一样的)。
请允许我们设置一个触发器来控制它。
-
我对这个也很感兴趣
-
我很想知道ZenDesk内部是如何处理这个问题的?亚博
-
这将是一个非常棒的功能，可以添加到系统中，并且可以节省大量的手动分配。
-
我同意到目前为止所做的所有评论。如果后续邮件已经与原始邮件有关联，为什么它不能继承原始邮件的数据呢?
-
同样的问题。因为只有两个代理可以看到一切，只有他们可以采取行动，这是不理想的。
-
我同意上面的说法，但我很惊讶的是，后续操作在默认情况下并没有继承之前的门票组和分配
-
同意。这是预期的行为，这是令人沮丧的，不得不解决这个问题。
-
我的工作流程可能与其他人不同。当客户回复已关闭的票据时(记住他们同意关闭)，通常是一个新问题。我想控制给哪个组分配那张票。
我想我们都会有所不同。
-
它可能是一个功能，可以像某些帐户设置一样打开或关闭。
我们使用我们的设计票来管理我们的设计票，并喜欢让每个客户与特定的设计师一起工作，以提高效率和建立客户关系。
-
我们也遇到了这个bug。在我们的情况下，这尤其令人恼火，因为我们有多个产品组，后续工作都在一个组中结束，并且必须重新分配门票才能看到。
这似乎是一个明显的错误……坦率地说，这甚至不符合后续记录的行为，即从原始机票中“复制所有机票数据”。
-
我很失望这还没有成为一项功能，特别是我们有多个品牌和团体，后续的门票不会自动分类，在人们注意到它们之前，它们只是在那里呆了很长时间。
-
我们当然也会喜欢这个功能。似乎只有当后续机票重新开放时，它才会保留最后一张机票的受让人属性。
-
嘿,伙计们,
我从一个客户那里遇到了同样的问题，并在我们的支持提示和注意事项部分找到了这篇文章:如何在已关闭的工单上分配跟进工单给受让人。
希望这对你有帮助!
致以最亲切的问候。
___
编辑以更正链接。
-
你好,
这似乎是一个无需动脑的默认设置，因为后续订单自然会由同一组处理，如果不是同一个受让人。因为现在很容易丢失票证，或者代理无法访问后续票证，不得不依赖管理员来查找票证。
添加此设置的主要投票!：)
谢谢,
劳伦
-
我不知道你们所有人。但是,如何在已关闭的工单上分配跟进工单给受让人。对我来说还不够清楚。有人能上传截图或视频吗?
___
编辑以更正链接。
-
我同意之前的观点，如果后续订单能自动重新分配给原来的受让人，那就太好了。
我们最近的报告显示，这些积压的文件和以前丢失的一样多。它将所有权留给我们的代理商，如果客户定期与同一名工作人员就现有问题的任何后续行动进行互动，也会建立更好的参与度。
这将是一个巨大的帮助，如果我们可以创建!
-
有什么进展吗?看来后续机票至少应该和之前一样分配给同一组，如果不是特定的代理的话。
-
谢谢你的文章，阿曼达。我确信这种方法很有效，但我不愿意为我们的Zendesk中的每个代理商创建或维护一个触发器，因为我们有近80个代理商，而且由于人员流动，列表并不总是静态的。亚博这个功能可以通过以下几个选项的设置来实现:
- 自动分配一个新的跟踪票给原来的受让人
- 自动为原组分配新的后续票证
- 不要自动分配新的后续票(这是今天的行为)
它也可以被整合到触发系统中以获得更大的灵活性，但我不确定这是否需要很大的灵活性。
-
根据我在这篇文章中所读到的，这似乎是一个简单的解决方案(或至少是一个变通方法)，即让系统自动分配后续行动给代理，如果该代理不再活跃，则将票分配给该代理的组，以便其他人可以捡起它。
在此期间，我想推荐像Round Robin这样的应用程序。我们在一年前开始使用它，所以我们可以设置它使用循环票务分配方法，这样你就不必担心代理挑选票务。但我突然意识到，它可能会被用于我们在这篇文章中讨论的情况。
可以将其设置为查看特定视图并将这些票分配给所需的代理。诚然，它不会分配给同一个代理，但至少他们会被分配出去，如果有必要，可以由代理重新分配。
我只是设置它，似乎它将作为一个解决方案，直到/除非ZD把它作为默认功能。
-
令人失望的是，Zendesk没有提供这种路由作为默认选项。亚博
类似于这个变通方法，使用触发器自动分配后续票据，我使用3个触发器构建了我自己的解决方案，这些触发器从原始票证中提取受助人ID和组ID，将它们保存到目标，然后在创建后续票证时从目标中提取它们，以便将后续票证路由到原始受助人和组。
这种解决Zendesk功能差距的方法比前面提到亚博的文章更具可扩展性，因为您不需要为每个代理创建自定义触发器和标记。相反，由于它使用受让人和组id，您只需要设置一次，并且随着团队的增长和合同的签订，它适用于所有代理。
我从一篇支持提示文章中构建了我的，它看起来像是Zendesk拉下来的。亚博游手好闲的人。
-
嘿，雅各布——
感谢分享你是如何解决这个问题的。我已经标记了这篇文章供产品审查。
我看看能不能找到那个支持提示是怎么回事。通常，当东西被归档时，是因为它们已经被弃用了。你还记得它叫什么吗?
-
嗨，妮可·雷利亚，
我不记得文章的名字了，但如果你用这些字符串搜索你的档案，你应该能找到它，因为它们是一字不差的:
使用的目标的名称:
“设置原始受让人ID”
“设置原组ID”
“从原始受让人ID中设置受让人”
“从原组ID中设置组”
触发器的名字:
"跟踪机票到原点的路线。受让人-触发器1"
"跟踪机票到原点的路线。受让人-触发器2”
"跟踪机票到原点的路线。受让人-触发3”
特定的标签名称:
“wait_for_assignee” -
嘿，雅各布——
我确实找到了那篇文章。它被归档是因为它不是一个推荐或支持的工作流，因为它使用URL目标来更新Zendesk中的资源，这可能会导致各种各样的问题，所以我们试图阻止它的使用。亚博电脑端亚博
-
你好,妮可,
这是一个遗憾，因为这是唯一可扩展的解决方案，将后续票路由到原始受让人和组，这是一个完全合理的功能要求。我们有超过200个代理，我不打算为每个代理创建和维护一个标签+触发器来实现这个功能。随着我们代理基数的增长，这样的摩擦累积起来，使Zendesk成为一个真正的亚博挑战。
-
令人沮丧的是，这个问题已经突出了这么多年。我必须创建**74*个不同的触发器来保留后续票据中的组分配和优先级。我需要再增加几百人来保留这个受让人。但另一种选择是对最高优先级的后续处理，即在默认队列末尾结束的专用票据。
请登录留下评论。
103条评论