触发接收时间
完成我们可以得到一张未收到的票吗?我有一堆支持的电子邮件地址，不希望重复的电子邮件去请求，所以添加一个票未收到xxxx@亚博zendesk.com将允许我单独指定这些通道。
-
我支持这个请求。
-
是的,请!
-
亚马逊的想法，非常有用。
既然我们已经有了“Ticket channel = is not”，那么添加“Ticket received = is not”就没什么大不了的了。
-
+ 1
我们有一个用例，我们希望将人们转发到我们的帮助中心，并逐个阻止邮件……
对于超过100个邮件地址，很难设置98个，而不是2个。
-
+ 1
我们还有一个用例，我们希望通过触发器排除某些电子邮件地址。
“收到地点”选项在这里会很有帮助。
-
大家好!
您能否分享关于您的用例的其他细节，例如，需求出现的频率，对您的业务的影响，该问题的解决方案会产生什么影响，等等?
-
妮可,
我们有每个国家的电子邮件地址
．．
我们知道有经验的Zendesk指南和发展我们的自助中心。亚博
因此，从现在开始，我们希望客户改变心态，不要直接发送电子邮件，有时可以直接在知识库中找到“愚蠢的问题”。
所以方法应该是，我们强迫他们使用Web-Portal(帮助中心)检查知识库，然后提出一个问题，并将所有信息放在我们创建的公式中，我们想知道之前。
所以我们从触发器中逐个禁用(删除)邮件。
在如此多的电子邮件地址的情况下，我们配置了一个“优先备份触发器”。
此触发器仅将Prio设置为Low并发送“请求收到”。
如果我们可以用“not at”来加强这个触发点……“封了邮件”，那么我们只能触发“支持@…”并注明“以后请使用帮助中心”....
/托拜厄斯
-
谢谢你花时间补充这些细节，托拜厄斯。这是有帮助的。
-
你好,
这对我来说也很好。我的用例是:
我们有几个不同的传入地址，我们希望根据这些票据的传入方式应用不同的触发逻辑。这可能意味着不同的自动注释，添加不同的标签，不同的共享选项等。
我们有一组默认的触发器，它适用于所有的票证来源(网页表单，默认电子邮件地址等)，然后非默认的触发器，适用于票证的第二个电子邮件地址。
如果没有“不是”选项，我们就很难确保所有的默认规则都适用于所有的邮件源，除了一两个邮件源。如果我们尝试只使用'is'选项，我们将不得不在' If any these criteria match'部分应用这些选项，这意味着我们不能将其用于触发器的其他条件。添加标签或其他基于源代码的东西可能是一种选择，但与简单的“not”选项相比，这也变得更加混乱。
谢谢,- sp
-
+1，有些国家不喜欢垃圾邮件，不想收到其他国家想要的一些电子邮件
-
荒谬的是，这不是一个选择。我有一个支持团队，不需要对特定支持电子邮件地址的票采取行动，因为它会自动路由到另一个团队。没有这个功能只会产生噪音和混乱，因为我已经把这些信息过滤到Slack中了。为什么这不是一个选择!?
-
我们也需要这个!
我们的用例:我们的tam应该被分配给来自任何方法的票据除了指定的电子邮件地址。
-
+1这个请求，似乎是一个相对简单的要求!
-
+1，我试图设置收到的门票通知，而使用多个电子邮件地址，我发现它几乎不可能防止发送2个通知。
-
+ 1
在每个触发条件上拥有一致的逻辑运算符将是一个巨大的胜利。不一定只是收到。
-
有什么进展吗?它现在已经7岁了，有一个体面的讨论，很多投票，这是一个简单的请求。
我们经常被告知，这些论坛中的反馈将根据互动(在我看来这是一个糟糕的指标)进行挑选和审查，但我们确实做到了。
妮可•桑德斯如果你从Zendesk那里得到了最新的信息，我会给你留言亚博Adi Schnall谁知道我对这种方法的看法。
-
嗨，Nathan。
我们将就此请求与产品经理联系。它每年只收到1-2张选票/评论，并不是最受欢迎的功能之一，这可能是它在过去没有受到太多关注的原因。但我们将看看我们是否能找到总理的观点!
-
一个请求的受欢迎程度不应该否定它的有用性或价值。
仅仅因为其他一百个客户没有遇到同样的问题并不意味着它不存在。同样，因为大多数Zendesk用户已经意识到与内部CS的交互几乎没亚博有意义，这并不意味着我们的想法/请求不值得探索。
我经常反驳ZD代理“在社区论坛上发布反馈”的提示，因为我知道很少有人接受。这条线索似乎就是证据。 -
这也是那些很容易实现的事情之一，如果它只是有人在短时间内工作。即使感知到的好处很低(每年没有多少评论)，与其他庞大的功能请求相比，这样做的成本也很低，在相同的投票和评论规模上比较它们是没有意义的。当然，这种背景很重要，应该更容易让人从事这项工作?
-
感谢大家的反馈，听取客户的意见总是很有帮助的，我们确实阅读了所有的线程和用例。这一点似乎相对简单，但团队需要与工程团队一起解决这个问题，并将其与即将到来的其他计划进行平衡。再次感谢您的反馈，团队将再次张贴时，他们有一个更新。
-
克里斯·汤姆金斯我们说的是几天，几周，几个月还是几年?
-
另一个声音是不是操作员报到。一旦你变得足够大/复杂，并且可能有许多属性值，你可能需要过滤你的工作，它会更快，更容易阅读和维护工作流不包括一个特定的值，而不是包含所有其他可能的值。
例子:假设我经营Alphabet Inc.(不，不是那个Alphabet)。假设我有26封邮件，每封都以字母表中的一个字母命名。A@alphabet.comB@alphabet.com等。
现在,团队X@alphabet.com是特别的。他们致力于小众的、时间敏感的问题。他们是他们所做的最好的，我们不希望有任何干扰，或者他们的工作被其他团队偶然接手。事实上，如果非X特工接触到这些票，对我们的业务来说确实是一件坏事。
我希望Zendesk中其他团队的门票视图和规则不要处理X团队的东西。亚博
对于今天的运营商来说，一个需要排除的观点X@alphabet.com将有ANY部分的配置看起来像:
在机场收到机票A@alphabet.com
在机场收到机票B@alphabet.com
在机场收到机票C@alphabet.com
在机场收到机票D@alphabet.com
在机场收到机票E@alphabet.com
在机场收到机票F@alphabet.com
在机场收到机票G@alphabet.com
．．．．．．
在机场收到机票W@alphabet.com
在机场收到机票Y@alphabet.com
在机场收到机票Z@alphabet.com
如果我可以使用不是操作符
未收到机票X@alphabet.com
看看Ticket视图的解释要容易得多!
(是的，我知道我们还有其他方法可以解决这个问题，比如在X团队的案例中添加一个触发器，并让视图排除该标签，但这需要管理员来设置规则，这意味着管理人员不能再为他们的视图管理服务，并为我们的触发器添加噪音。只是，一个变通方法(大规模应用的变通方法会导致更多的变通方法不得不在稍后创建，直到整个实例建立在创可贴和祈祷的基础上)。
让我们更进一步。明年，我们将收购数字公司，一家优秀的数字产品供应商。现在我们需要向Zendesk添加更多的电子邮件，而数字比字母表中的字母要多得亚博多。(想想1 @company.com，2 @company.com)团队X的目标保持不变，然而，他们需要激光般的专注来处理与字母表中最神秘的字母有关的问题。
在今天的世界里没有不是操作员，我们要更新了每一个视图用附加条件来处理。上面那个怪物视图的例子?它只是变得更加难以阅读，并且需要经常更新我们需要支持的每个新号码@地址。这让管理员们很难过。一种深沉的，摧毁灵魂的悲伤。
在一个我们会有不是运营商，不需要维护的初始触发从数字公司的电子邮件不是X@alphabet.com
总而言之，如果Zendesk致力于让视图/触发器/自动化中的任何操作符都能够被选择性地应用，这对任何地方的管理员来说都意味着很亚博多和排他的礼仪。
谢谢你的阅读:) -
除了Dan的例子之外，需要注意的另一件重要的事情是，如果你使用触发器配置的ANY部分来添加所有这些“ticket received at”地址，这意味着你不能在该触发器中使用任何其他ANY条件。
如果你还需要有这种类型的触发器只适用于少数主题字符串，例如，你不能再让你的任何条件是主题包含字符串'a b c'或主题包含字符串'd e f'或主题包含字符串'x y z' -所以你锁定自己的选项，使你的触发器正常工作，而不需要复制触发器或通过其他触发器应用标签为你需要的每一种情况。有时候，由于复杂性的关系，这变得越来越不可行。
-
这个再加1。
我的用例是，我有几个单独的电子邮件地址，我们收到不同类别问题的票(例如一般与隐私)。对于一般排队的人，我不希望收到票privacy@domain.亚博zendesk.com排队:进入在收到票的一般队列support@domain.亚博zendesk.com，但在第三电子邮件地址收到的门票(例如，billing@domain.亚博zendesk.com)我将我想加入那个队列。有一个“收到”是不可能的privacy@domain.亚博zendesk.com就能做到这一点，我还没有找到一个替代的解决方案，可以做到这样干净。
-
+ 1
我们在实例中遇到过很多次，因为我们有数百个额外的电子邮件地址。
-
我梦想有一天，我们可以用逻辑运算符(如液体标记)来管理条件，而不是ALL/ANY部分。
条件1
条件2
条件3
(1 and 2)或(2 and 3)
-
我们从一些版主那里得到了一个解决办法，但是如果能够使用“收到的AT是NOT”来排除电子邮件，将会为我们节省很多时间。感谢您所做的一切，期待看到ZD的成长。
-
你好亚博Zendesk团队-请问你有关于这个的最新消息吗?我们可能有这种情况，因为它是非常有益的。
不知道为什么我们只收到了> is >
谢谢! -
克里斯·汤姆金斯这次有什么进展吗?当您在一个实例中管理多封电子邮件时，很难在多个条件下维护带有多个Meet ANY received的触发器。
文章已停止评论。
34个评论