从触发器设置请求者:组织的能力
当客户第一次发送电子邮件时，让触发器设置“请求者:组织”将非常有用……通过在ZD中配置多个电子邮件地址，这使我能够根据最终用户发送电子邮件的目的地自动将其与组织关联起来。
我可以创建一个自定义字段并进行设置，但是我不能设置请求者组织....使得内置的组织字段对我来说毫无用处。
-
官方的评论
大家好!
触发器和自动化的新PM在这里，赶上了社区的要求。看到你们的反馈真是太好了!
我想确保我完全理解用例，因为在这个线程上有相当多的反馈。这里的主要要求是把本组织列入候选名单吗?如果是，您是否尝试过创建一个自定义查找关系字段在指向组织的机票上?然后，您可以在触发条件中使用Received_at，并且可以使用触发器操作设置票证上的自定义查找字段。
-
通过宏、触发器或自动化设置客户标记或组织的能力是非常需要的。
-
你好,
我很想听听你的用例。在你们的zendesk中，组织代表了什么?亚博为什么您需要更改机票上的组织?我很想多听一些。
最好的
艾琳 -
1)客户试图购买我们的产品，但由于某种原因购买失败。也许他们没有输入CVC代码，或者增值税验证有问题，或者PayPal密钥，等等。所以我们生成一个电子邮件，触发到一个票。
如果我们可以将客户分配到一个“失败的订单”组织或标签，我们可以发送一个自动响应，然后避免为已经在那个/标签中的客户发送额外的自动响应(因为客户总是会继续尝试购买，我们不想反复使用自动响应器向他们发送垃圾邮件)。
通过标签或组织跟踪，了解谁在试用，谁已经购买了产品是很有帮助的，这样我们就可以把票送到合适的代理商那里。试用用户通常有更简单的问题，但他们需要更多的即时关注，而现有客户通常有更高级的设置问题，可以等待更长的时间。
此外，我们的自动应答器可以更准确地调整…试用用户将收到带有购买常见问题的自动回复，而现有客户将收到涵盖购买后问题的自动回复，例如丢失许可证密钥、向其帐户添加许可证等。3)我们采用“按事件付费”的模式，我们愿意提供包含3个支持事件的套餐，价格为30美元。我们希望使用宏/触发器/自动化来跟踪和修改剩余有效事件的数量，如果为零，则发送自动响应器，并提供有关如何购买更多事件的信息。
或者，我们可以提供一年的支持订阅，通过用户标签或组织进行跟踪，以便将票发送到适当的代理，或者提供购买支持合同。
此外，这个标签将用于设置优先级，因为为优先级支持付费的客户应该得到更直接的帮助。4)当退款给客户时，我们想要一个触发器将他们添加到“退款”组织或标签中，以便我们可以适当地路由未来的请求，并防止我们的系统发送垃圾邮件。
总之，我们需要知道客户在org或标签中的“状态”(试用、付费、退款、优先事件、VIP等)，这样我们就可以正确地路由他们的请求和/或使用宏、触发器和自动化进行自动响应。
-
我们通过不同的电子邮件地址提供许多不同的服务和支持请求。当通过电子邮件收到支持请求时，将其自动分配给相应的组织，可以更好地分配、跟踪和报告。
例如，我们做的一件事就是为物业管理公司提供维护支持……他们的房客需要修理东西时给我们打电话(或发邮件)。我们为每个物业管理公司提供不同的维修服务。他们的租户有一个特定的电子邮件发送他们的请求也(maint@companya, maint@companyb, maint@companyc等)....需要根据电子邮件的发送位置自动将入站票证分配给适当的组织。
感谢您查看此请求!
-
作为一个政府支持组织，我们有内部最终用户(员工)和外部最终用户(公众)。我们对每个组都有不同的SLA期望。
我们知道内部用户的电子邮件域，所以很容易为他们建立一个组织。
但我希望能够将所有外部用户(使用大量电子邮件地址的用户)默认为一个单独的组织。基本上，如果一个新的票是来自任何电子邮件地址，不是我们自己的域，我希望它默认为非员工组织。
也许这本来就是可能的，只是我不知道怎么做?
-
我们支持几十个网站，并且能够根据他们发送请求的支持电子邮件地址向组织添加电子邮件请求者，这将是非常有用的。
-
请添加此功能。我们团队使用ZD作为内部票务系统。亚博员工(过去的和现在的)和新员工将根据他们的问题寄来票。如果我们可以从触发器设置组织，这将有助于我们的数据收集变得更加清晰。
-
与上述非常相似，我们的主要兴趣是根据用户请求的电子邮件地址给用户一个组织。这将使我们能够以最好的方式指导和订购询盘。现在，我们必须根据电子邮件的来源手动选择一个组织。
作为第二个特性，我们还使用组织中的自定义字段来填充宏中的字段。
这给我们提供了一个可以基于组织填充字段的宏(以及我们在这些组织自定义字段中拥有的内容——不同的公司名称、网站和电话号码)的好处，其中一个这样的宏是代理签名。我们有一个签名宏，根据最终用户文件上的组织进行签名。
有任何问题，请让我知道，因为这将是伟大的有这个功能，节省我们重复什么是目前的手动任务。
-
更重要的是，为什么你不能这样做?Zendesk限制访问的原因是什么?亚博
我们必须编写、调用和托管脚本的地方多得不可思议，因为Zendesk没有内置基本选项，尤其是触发器和自动化中的其他基本选项。亚博
-
嘿,伙计们,
这个功能非常方便。没有某种“自动化的方式”将请求者添加到现有的组织或创建一个新的组织(如果一个组织不存在的话)，这是一个管理噩梦。
这在你的路线图上了吗?
感谢任何信息，
达伦;-)
-
我们公司也严重缺少这个功能。
-
大家好!
您能否分享一些关于您的用例的其他细节，以及为什么这是一个需要的特性?
据我们所知，它目前不在路线图上，但您详细的评论可以帮助我们的产品团队确定优先级。一如既往地感谢您的反馈!
-
嗨@Nicole !
我们的一些客户使用一个有几十个电子邮件渠道的设置。他们的每个客户都有一个特定的电子邮件地址，他们用它来沟通，因此任何使用该电子邮件渠道的人都应该被放入该客户组织中。这将允许拦截这些客户，无论他们是否使用他们的官方公司域名，或者他们是否在寻求帮助时使用他们的Gmail帐户。
另一个用例是事件。如果您为一月俱乐部会议设置了一个电子邮件通道(创建这个通道)，那么任何相关的人都可以根据使用该电子邮件地址发送请求而被放入组织中。
但是，更重要的是，为什么这不是一种选择?亚博Zendesk不应该限制我做事情的方式，除非那样做是有问题的。将用户分组到组织中与提供支持的能力无关，也不会使Zendesk中的其他选项无法按预期运行，所以为什么不提供它呢?亚博提供它的努力程度是最小的。
这扩展到其他功能，如能够检查电子邮件的主题为某些关键字。我们的许多客户使用了这个选项，他们的触发器无法操作，没有其他选项可以完成同样的事情。相反，他们必须在Zendesk之外构建昂贵且容易出错的脚本，使用API来完成本应简单且基于规则的界面。亚博
-
我们仍然非常需要这个功能，因为这对我们来说是一个始终如一的手动任务。
电子邮件渠道决定了客户在哪里找到我们，特别是我们决定了他们的地理区域。它们的地理位置决定了它们的定价。
我们将使用这个功能，根据他们发送邮件的地点，立即分配一个组织。
我们也运行基于组织的列表。我不会隐瞒这一点，因为目前这是一项手动任务，有时组织会被遗漏，这将人们排除在我们的邮件列表之外，并且由于他们使用的渠道，也可能导致围绕定价的误解。
-
我们支持几十个网站，并且能够根据他们发送请求的支持电子邮件地址向组织添加电子邮件请求者，这将是非常有用的。
许多这样的网站是面向消费者的，而不是面向客户的，所以通过他们自己的电子邮件域添加请求者的能力不是一个选项，但是，如果他们给我们的特定网站的支持地址发送电子邮件，我们需要能够将他们添加到特定的组织。
-
我们还非常希望能够基于触发器设置请求者:组织。目前，请求者只能根据他们的电子邮件域绑定到组织。然而，我们的许多组织都有品牌帮助中心。通过品牌帮助中心提交请求的请求者并不总是拥有该组织域的电子邮件地址，但是这些请求者的请求仍然应该是该组织的一部分。
我们希望能够设置一个触发器，添加一个请求到一个组织，如果他们通过一个特定的品牌提交门票。目前这是不可能的，似乎没有一种方法来自动化此功能。
-
对于我的用例，我有一个工具来监视所有客户的资源。亚博电脑端当它发送警报时，它总是来自相同的电子邮件地址，无论客户是什么，这使得通过电子邮件设置组织变得不可能。
因此，为了在适当的组织下列出票证，我们需要能够设置一个触发器，将票证与组织关联起来，方法是让请求者是最终用户(我为通用用户设置的带有电子邮件地址的用户)，然后使用主题行中的客户名称为特定客户设置组织。
目前这是不可能的，因为1)请求者可以是最终用户(什么?!)，2)没有办法用当前的触发器规则设置组织。
-
您可以使用HTTP目标来完成此任务，前提是您可以正确地设置触发触发器的条件。我假设基于品牌/表单或其他请求者级别的属性等，你可以设置一个标签，用于正确的条件来触发触发器。
/api/v2/users/{{ticket.request .id}}然后你可以简单地调用它，否则你会想要通过扩展/添加目标/ HTTP目标创建一个新的
名称:随便你怎么称呼它，比如。“更新请求者”
Url: https://your-亚博zendesk-domain.com/api/v2/users/ {{ticket.requester.id}} . json
方法=放
内容类型= JSON
为API调用选择身份验证类型并创建
接下来，查找组织id。只需去人/组织，点击你想要的一个-得到的ID是在url，即https://your-亚博zendesk-domain.com/agent/organizations/123456789/票
接下来，创建一个用于更新组织字段的新触发器—设置正确的条件，即创建的票据和标签必须包含xyz等。添加Notify Target操作-并选择您刚刚创建的适当目标(即Update Requester)。使用下面的JSON主体—只需将值更新为您在上面步骤中找到的组织id，而不是我在下面列出的值。
｛
"用户":{
“organization_id”:123456789
｝
｝注意:你必须确保你的条件只会被满足一次。例如，ALL条件之一可能是Tags | Contains None of the Following | org_updated(作为示例)。然后只需添加一个动作，以便触发器在执行JSON后添加该标记。随着标签现在添加到该票据，触发器将不会再次触发。
-
詹姆斯，谢谢你的回复。这似乎是合理的，但有一个例外:我没有看到在触发器下可以设置组织的任何操作。你那边也看到了吗?
最好的问候,
温斯顿的价格
-
温斯顿-你是对的-但这就是HTTP目标发挥作用的地方。只要您能够为触发器在您希望为该请求者设置组织的票据上运行建立正确的条件，那么我上面粘贴的HTTP Target和JSON代码将设置组织。在我们的ZenDesk实例中，下面的触亚博发器是我昨天成功测试的东西——条件对我的测试来说非常简单——只需要包含一个特定的标签，所以您会想要在用例中确定正确的条件集。但是…一旦满足条件，JSON代码将更新该票据请求者的组织。
-
大家好！
我们希望组织字段也能成为触发器上的可用目标。我们有属于多个组织的最终用户，主要是电子邮件用户。我想设置一个触发器，根据它们描述字段中的标准，将票证路由到正确的组织。
Ie。如果注释文本中包含“NVCOM”，则->执行操作:将“组织”设置为“Nevada Committee”。
这是一个问题，因为我的大多数客户都在政府工作，他们喜欢有可以参考的电子邮件文档。他们不喜欢使用这个网站。所以每次他们送来罚单我们都要手动修改。
谢谢你！布莱恩
-
感谢Brian分享您的反馈和用例!
我们一定会将此信息传递给相应的团队进行考虑。
如果我们的产品经理有任何其他问题，他们会联系我们:)
干杯!
-
是的，我同意，这是非常必要的。
在我们的案例中就不需要人工了。
情境:
- 我们有一个客户在……上使用我们的应用。
- 由第三方操作的系统，该第三方也为其他客户操作系统。
第三方的员工正在为我们的几个客户服务。
他们将自己的公司作为主要组织，并将所有客户的组织作为附加组织。
他们把票寄给customer1.support@ourdomain.com。所以，我们完全知道该把票归到哪个组织名下。然而，Zendes亚博k通过坚持不提供旁路，门票必须与第三方组织相关联来防止这种情况的发生。Hmppf。
在这里，触发器、自动化和宏都无法提供帮助。真遗憾。
谢谢收听!
-
哇，我们也很想要这个。我们有一个独特的支持号码，为不同的客户，每个地图到一个独特的品牌。我们还有一个组织，每个客户的所有用户都属于该组织。目前没有办法确保所有呼入票证都放在正确的组织下，它们只与品牌相关联。
我们确实需要以品牌为基础建立本组织的能力。我们可以通过触发器来设置基于组织的品牌，为什么不能反过来呢?
-
谢谢你的评论，Peter和Swaraj。
-
这似乎是一个基本的功能，但不是可用的。请添加此功能!
-
我执行了James概述的方案(非常感谢James)，它完美地发挥了作用。
所以，我们有了一个解。
我会推荐这种解决方案作为一种标准的做事方式吗?
对于有经验的系统管理员和开发人员来说，完全没有问题。然而，看看Zendesk通常的客户(以及亚博Zendesk目前在支持部门做事情的方式)，这并不是一个很好的修复——事实上，这是一个API漏洞，需要更多关于Zendesk支持(应用程序)的知识，而不是Zendesk的目标受众所能期望的。
进一步思考，我发现当前支持的触发器功能存在某种不平衡:虽然我可以查询组织的值，但我不能设置它。
-
这也是我们急需的功能(根据收到的电子邮件地址设置组织)。我们向客户报告的机票每个月都会丢失很多机票，除非我们每个月手工检查、审核和更新机票，这非常耗时。
对于我们的票务中涉及的所有第三方和系统来说，集成的选择是不可行的。我们一个集成的报价超过9万美元，而其他集成没有可用的api。
我们是电信和IT领域的托管服务提供商。
我们要求能够根据收到请求的电子邮件地址设置本组织的情况如下。
1)基于云的系统——我们代表客户登录系统。系统访问(在某些情况下是多个系统)由客户提供，以代表他们管理平台。代表许多客户管理相同的几个系统，我们必须为同一系统创建这些帐户的唯一方法是为每个客户提供唯一的电子邮件地址(因此登录)。我们通常代表客户管理1到3个系统。
电子邮件地址，如customer1@ourdomain.comcustomer2@ourdomain.com
来自这些系统的任何通知都被发送到帐户上的电子邮件地址。
2)第三方供应商-我们有许多第三方供应商代表客户与我们联系，有时是多个客户。例如，客户可能与我们签订合同来管理他们的商业移动电话和MDM平台，但他们的IT(活动目录，电子邮件服务器等)有另一个供应商。IT提供商将代表多个客户向我们提出请求，并从IT提供商域接收请求。
我们目前所做的工作是，每个系统的电子邮件地址都是我们帐户上的轻代理。用户有超过20个组织反对他们。我想这是有限制的。所以最终我们需要找到一个新的工作。
当这些通知/请求到达Zendesk时，我们的团队需要手动选择票证上的客户。亚博这将确保票证根据特定客户的业务规则被正确地操作。反过来，这也允许我们正确地报告我们为特定客户所做的工作。
由于所有的手工流程都留下了人为错误的空间，Zendesk应该可以相对简单地实现这一点，以节省我们(和其他人)大量的手工工作(每月手动更新200多张票)。亚博
-
谢谢James，您针对HTTP目标的解决方案工作得非常完美。
请登录留下评论。
42岁的评论