报告收到的电子邮件地址
完成了解哪些电子邮件地址的流量最大是很重要的。在发送到Explore的票属性中包含“接收地址”电子邮件地址将会很有帮助。
-
是的,请!这将是非常有帮助的，这样我们就可以看到哪些产品和客户更多地使用电子邮件门票。我们希望停止将入站电子邮件作为渠道，因为它需要花费最长的时间来获取我们需要帮助客户的数据。能够看到哪些产品和地区已经为这种转换做好了准备，这将是伟大的!
-
是的，如果能够根据收到询盘/票证的电子邮件地址直接运行报告，我们将非常感激。这比必须经过创建触发器创建标记的中间步骤，或者必须基于这些票证分配给的组/代理的步骤要干净/安全得多…在期望的报告范围内，任何这些都可能发生变化(或者您想到它们太晚了)…那么你就错过了获得所需数据的机会。
谢谢你考虑这个!
马克
-
是的，请建立这个属性。
-
我再加一分!今天我真的需要能够根据这些数据建立一份报告，但我很失望。
这已经是支持票证模型上的一个属性，可以将其添加到探索数据集吗?
谢谢!
-
你好,
快速更新一下我们正在做的事情:
我们使用一个名为“Received At”的自定义下拉字段(不要与业务规则中的“Received At”混淆)。我们将每个电子邮件地址添加到自定义的Received At字段。然后，为实例中的每个电子邮件地址创建一个新的触发器。如果接收值=xyz@abc.com，则接收点(自定义)值设置为xyz@abc.com．每封邮件都是如此。
自定义字段是可报告的，业务规则根据通过电子邮件创建票据时的Received at值对其进行设置。我希望这对其他团队也有帮助!
- z
-
这也是+1。在报告框架中无法获得这些信息似乎非常奇怪。我们有相当多的不同的电子邮件渠道，并希望通过不同的渠道创建的门票报告。
-
再次碰撞这个问题，希望一个探索项目经理会抓住它并做出回应。
这将对确定受欢迎的联系渠道有很大帮助。我们目前正在尝试合并和弃用一些地址，但我们不知道哪些地址接收到容量，这使得智能地处理这个项目非常困难。我们获取这些数据的唯一方法是通过API导出并遍历数十万个票据，这是对开发资源的浪费。亚博电脑端
这些数据已经是核心票务模型的一部分(它是“receiver:”属性)如果它能在Explore中出现，那就太有帮助了。我不知道在Explore中添加新属性会涉及到什么，但从终端用户的角度来看，这似乎是一件轻而易举的事情。
谢谢你的考虑!
-
大家好！
谢谢你的反馈。的在电子邮件地址收到机票属性确实是一个非常流行的特性请求。它之前没有被优先考虑，因为扎克在这里分享了一个简单的解决方案。然而，任何解决方法都意味着需要手动调整，这会导致人为错误，并且用户需要在实现上花费额外的时间，因此这不是一种很酷的体验。
我们将研究在2020年上半年可以将哪些属性添加到Support数据集中，并且通过电子邮件地址接收是最佳候选之一。 -
这是一个非常有用的回答。添加自定义标签作为每个Received At地址的传入票据的触发器的一部分，可以帮助我们暂时获得一次性报告所需的数据，但从历史上看没有帮助，所以希望这个功能可以很快添加。
-
+ 1
-
这里有什么更新吗?这感觉就像一个巨大的失误，无法根据收到的信息来进行报告。
-
这个加1。正如Eugene在“变通方法”中指出的那样，这是一种手动调整，需要维护Zendesk已经捕获的一些东西(例如a亚博搜索可以通过接收地址过滤)。
请在Explore中提供。
-
拜托，我们也需要它
-
收件人/收件人地址+1作为Explore的公共属性。
-
是的，我绝对需要这个功能。
-
+1，我们也需要这个，已经有消息了吗?
-
Zendesk的最后一次更新是7个亚博月前，表明这可能会在2020年上半年添加…现在是七月……这里有什么更新吗?我们也需要这个。
“变通方法”只有在一开始就设置好了才有效，所以它不能解释关闭的门票。
-
这个也是+1 !这将是非常有用的，我们分离我们的传入电子邮件渠道
-
请+ 1 !
-
我很震惊这些数据竟然没有包含在《探索》+1中
-
这件事还没有进展吗?
扎克的解决方案不是解决方案。
它没有考虑到之前所有的历史。
-
我们在历史数据报告中遇到了同样的问题
-
我们也希望有这个功能
-
你好尤金·奥这个属性有更新吗?它已经被提出3年了。
-
+ 1
-
@……过去一年零6个月没有更新，你建议我们可能会有这个。
考虑到这个问题已经有3年多的历史了，这个特性在被弃用之前就已经存在了，并且这些信息已经存在于Zendesk数据模型....中亚博这双冰球棍是怎么回事?
我无法想象这在技术上有什么挑战性。必须在我们使用的每个票务表单上创建一个新字段，并自动填充它，这并不是一个真正可接受的解决方案，因为它忽略了过去的全部历史。+……数据已经存在了，我相信你也知道。给我们一块骨头吧，伙计! -
Whaaat吗?你不能这么做吗?为什么?
-
我们最终实现了我们自己的自定义字段，该字段由触发器设置来获取接收点数据，但随着越来越多的电子邮件地址/团队进入Zendesk，这需要大量维护。亚博如果接收点是探索数据集中的一个字段，那将是非常有用的。
-
我们需要这个功能。
请登录留下评论。
64条评论