亚博Zendesk on Zendesk:我们如何使用About字段
亚博Zendesk on Zendesk是一个关于特定主题以及Zendesk Support如何使用Zendesk的为期一天的讨论。每次会议由我们的支持团队的一名成员主持。
本次会议是关于我们如何使用自定义about字段来驱动我们的支持工作流，由我们都柏林办公室的系统专家Robin Frerichs主持。
看到所有的亚博Zendesk Zendesk系列讨论。
这到底是怎么回事?
的关于field是我们在Zendesk使用的自定义票证字段。亚博我们的支持团队以及其他一些团队依赖About字段来实现各种不同的目的，包括报告、路由、升级和通知。我们从2010年开始使用About字段，从那时起它就一直存在，最终成为今天拥有321个选项的庞然大物。在Zendesk的Zendesk版中，亚博我们将看看以下内容:
设置About字段
当前的分类代理在分类过程中设置About字段。(见亚博Zendesk谈Zendesk:我们是如何分类的更多关于我们的分诊过程!)有321个字段值可供选择，因此很难选择正确的选项。我们将错误机会最小化的一种方法是组织字段以允许基于产品类别的浏览。
About字段是嵌套的，允许基于产品类别进行浏览，因此一个选择可能类似于:product > Business Rules > Triggers。
此外，每个接触票证的代理都会再次检查About字段，并在必要时更新该值。
管理About字段
About字段由Support Operations管理，该团队负责维护和管理Zendesk实例。亚博我们需要定期更新字段值，以考虑新的内部流程和支持团队的更改，以及实际的产品更新。偶尔，我们也会删除About字段选项，主要是由于缺乏使用或因为该特性已被弃用。我们几乎每周都会对About字段进行这样的更新，并在这样做时向所有相关方发送通知。
要启动About字段值的更新，产品倡导者(专门研究特定产品领域的经验丰富的倡导者)或产品经理会向Support Ops发送请求更改并解释原因的票据。然后，支持Ops将评估请求，并在必要时更新字段值。
下拉菜单中的每个选项都添加了一个标签，以“about_”开头，然后是所选选项的名称。例如，如果About字段设置为Facebook，则会添加“about_facebook”标记。为了使标记保持简短，我们没有在标记中包含嵌套字段的全名。
关于About字段的报道
我们有About字段的一个最重要的原因是我们可以在Explore中报道它。作为支持运营和项目管理团队的一部分，我们的数据分析师负责维护Insights报告。通过这种方式，我们可以得到关于产品区域的结果，该结果可能应用于多个About字段值。基于这些桶，我们基于About字段构建其他指标，例如一键式解决方案。
我们使用这些报告来确定哪种类型的问题需要花费最多的时间来解决，或者最频繁地升级到更高的支持级别。我们还可以使用报告来查看代理人是否擅长或倾向于任何特定领域。反过来，这有助于我们的管理团队在培训和升级方面做出决策。
它还可以帮助我们查找文档中的漏洞。通过查看不同About字段值的频率，我们可以看到什么类型的问题经常被问到，以及我们是否可以编写文档来主动支持我们的客户。
通过使用About字段报告，我们在Tier 2中的团队领导也能够研究优化About字段的方法。当一个律师有一个分类转换，他们通常希望尽快通过门票，以保持在入境队列的前列。这意味着About字段必须尽快设置，字段选项的措辞可能会产生很大的不同。当措辞不准确或违反直觉时，即使是相关的选项也可能不会被选中。
业务规则和About字段
About字段还用于某些业务规则。例如，当我们发布一个新功能时，Zendesk中的开发团队可能希望通过票证收到反馈通知。亚博在某些情况下，我们的Support Ops团队将设置一个触发器，在提交带有About字段的票证时通知特定的代理。这样，开发人员就可以随时了解有关新功能的任何反馈或问题，并可以选择加入或查找我们文档中的空白。
About字段在我们的宏中也很重要。对于用于回答特定问题的宏，我们可以设置About字段，以节省代理在解决问题时的时间。例如，与Chat相关的宏通常会自动将About字段设置为Chat，从而为代理节省一些时间。
第2层的About字段
我们的Tier 2支持团队对About字段有自己的用途:他们将其用于专门化。团队被分成小组，专门负责不同的产品领域。发送到Tier 2的票据保存在Tier 2组中，并根据About字段设置视图。例如，负责集成票证的小组使用一个视图，该视图只显示票证，并且About字段设置为与集成相关的内容。类似地，处理报告的小组将获得关于Explore的门票，等等所有四个小组。这允许我们的Tier 2拥护者选择专业领域，并成为某些类型门票的专家。
-------
这就是我们在Zendesk使用About字段的方式!亚博在Zendesk实例中是否有About字段或类似的自定义字段?亚博你有其他的方法来实现上述的目标吗?还有其他问题或想法吗?请在下面的评论中告诉我们!
-
如果门票包含多种功能，你会选择什么?我们的应用中有很多不同的功能，每次我考虑这样做时，我都认为基于概念而不是功能的“about”可能会更好，因为在我们的应用中执行一项任务可能涉及三到四个功能。
-
嘿,里根,
在这种情况下，我们通常做的是选择最有可能花最多时间来解决的选项。如果在产品的不同部分确实有不同的问题，我们的倡导者可以分开票，以确保我们的统计是匹配的。
你总是可以从概念开始你的About字段，然后在你开始收集更多的数据和反馈时对其进行细化。这实际上取决于你想要获得的粒度，有了嵌套字段，你可以从概念开始，然后从那里开始工作!
-
听起来不错。如何创建About字段?
我想我已经找到了我自己问题的答案https://www.亚博zendesk.com/blog/tip-of-the-week-nesting-fields/
-
嗨,马修,
差不多就是这样了!我们使用下拉字段，这在报告方面是最简单的，嵌套技巧将帮助你的其余方式:)
-
我们使用宏作为预先准备好的答案。
我们想做的是看看我们是否可以测量我们用每个宏解决票据所花费的时间，并将其与不使用宏的其他票据进行比较。我们已经设置了平均花费的时间指标，我们尝试为每个宏分配标签，但它不起作用!
我们是否可以使用about自定义字段根据该自定义字段在每张票中分配的值来报告每张票所花费的平均时间?
-
嘿,穆斯塔法,
如果你已经在使用时间跟踪和报告，那么在洞察报告的“如何”部分使用“关于”字段会让你从设置的“关于”字段和花费的时间中得到一个很好的解读。
对于我们的实例，我们有一个完全类似的报告，它使用平均处理时间和About字段。这让我们大致了解了倡导者处理某些事情的罚单需要多长时间!
-
前几个选项的设置截图将是文章的一个很棒的补充。
-
有人考虑过使用票务表单字段而不是About字段吗?由于我们已经使用Form字段来显示与票务相关的自定义票务字段，因此似乎我们应该能够为我们可能放入About字段的每个类别设置一个Form，从而节省代理选择About下拉字段的时间。有人试过吗?我主要想知道表单字段是否具有与About字段相同的报告选项。这可能是我们分手的原因。
另一种选择是两者都做——创建About字段和Forms，然后为每个表单设置一个触发器来设置About字段。然后用field Marshall之类的东西隐藏About字段。http://www.lovestockleaf.com/亚博zendesk/zendesk-apps/field-marshal.html
想法吗?
-
嘿,贾斯汀!
这绝对是一种选择，当涉及到我们的实例时，为每个嵌套选项创建单独的表单将导致50多个表单，但取决于您计划如何使用它，这可能是获得您想要的效果的好方法。在Insights中有一个指标，可以让你根据Ticket Form进行排序，所以即使是在报告方面，你也可以得到粒度。
我在尝试使用票务表单设置时遇到的唯一问题是票务表单字段不像票务字段那样是可搜索的字段。这意味着随着类别列表的增长，你将不可避免地在一长串选项中滚动。
在Ze亚博ndesk，我们实际上在更大的意义上使用Ticket Form, Ticket Form可以表明Ticket的目的是什么。我们有一个票证表格，用于我们的开发团队的票证，其中有与他们相关的票证字段，而留在支持的票证不需要显示这些字段。
@allen问，你会收到这样的About字段:
-
太棒了,谢谢!我猜你是这个意思，但正式的“关于”标题让我怀疑这是不是一个我还没有发现的隐藏功能。
我们如何使用About字段
vs
我们如何使用名为“About”的票务字段
我认为这张图片对这篇文章的主体是一个很好的补充，以免它在评论历史中丢失;-)
-
@Robin -谢谢你的反馈。我想我要使用一个“About”字段毕竟，因为表单是不可搜索的。我很高兴你提出这个问题，因为它肯定会变得很麻烦。
我决定做的是为每个知识领域创建表单，比如IT、医疗记录、应收账款等。然后我设置了一个触发器来更改Group以匹配，并更改About字段以导航该区域。
例如，如果选择了IT表单，然后提交了票据(我们的分流人员执行此操作)，则触发器将将其分配给IT组，并将About字段设置为:
IT:: IT(选择下面的选项)<——注意第二个“IT”之前的空格。它会把这个排序到About选项列表的最上面只要你按字母顺序排序。
下面的选项是这样的:
::密码重置
IT:新用户帐户
::故障排除::硬件
::故障排除::软件
在将来的某个时候，如果我们看到太多这样的票，我们可能也不允许我们的代理将票集解决为通用的About选项，如“IT:: IT(选择下面的选项)”。
-
我们目前有这样一个字段，我们称之为“密钥描述”。这对我们的报道有很大帮助。
目前我没有使用多级菜单。例如，我有"安装后有缺陷"和"安装时有缺陷"
如果我将此字段更改为多级，并且有“defect::After install”和“defect::At install”，我的报告仍然会报告两个关键描述还是只有一个，“defect”?
-
@Kim -很抱歉这么晚才回复你!在Insights中，将有两个不同的属性值。一个是“缺陷:安装后”，另一个是“缺陷:安装时”。
-
嘿!
你能告诉我是否有什么方法可以让我定期分析“关于”字段，这样我就可以每周看到最热门的问题了?
我试图建立一个报告，但我选择了“票务事件更新”，我觉得这不是正确的属性。
我也有兴趣了解更多关于一触式解决方案票证的信息，并找出哪些“about”字段与这些相关。
谢谢!
Lettie
-
嘿,莱蒂!给你
在构建报表时，重要的是要记住用于分割或过滤报表的日期维度如何与要报告的数据保持一致。由于“About”字段可能会在票证的整个过程中更新，直到最终确定最适合查询性质的选择，您通常希望在票证解决后报告该字段的值。
回顾数据维度对于与已解决的票对齐的属性，一周间隔表示从日期(已解决的票)文件夹中选择“周(日-日)”或“周(日-日)”最符合您要报告的数据。作为一般建议，我通常会建议使用“周(星期一至星期日)/年(票已解决)”或“周(星期日至星期六)/年(票已解决)”来确保您的报告仅显示您想要报告的数据。
洞察:一键式门票是一个很好的指南，让你开始一触票报告。如果需要将About字段作为切片包含在此数据集上，则只需在构建报告时从How下的属性中选择About字段的名称。你可以参考在Insights中报告自定义字段(专业和企业)有关在报告中包含自定义“关于”票证字段的其他信息。
-
嘿,詹姆斯,
太好了，谢谢你!这份报告看起来已经好多了!
谢谢,
Lettie
-
你好,罗宾,
似乎我不能在about自定义字段的“字段选项”部分添加多个标签，对吧?这就是我想做的:
我已经在about字段中设置了几个带有子类别的类别，我想根据分配给每个类别的标签创建报告，但是您只能报告类别分支的“终点”。例如:
系统::协议::通知::电子邮件::未发送通知
是否分配了“email_not_sent”标签，我可以制作一个报告，该报告将显示此分支中分类的所有票据，但如果我想制作一个报告，显示以下所有票据部分branch: System: Agreement: Notifications，我该怎么做呢?什么好主意吗?
我正在考虑添加不同的标签，代表您选择的分支的每个类别/子类别，但我认为我不能添加多个标签。
谢谢,
朱利安
-
嗨,朱利安
我完全理解你的意思，实际上我们在About字段和相关报道中也遇到过类似的问题。我们的数据分析团队在内部完成的工作是在洞察力中创建一个自定义指标，将值组合在一起。或者(如果你想尝试一些全新的东西，真的很酷)，你可以考虑使用我们的新设置关卡条件票证字段EAP。
使用它，您可以设置一个顶级选择器，然后根据需要显示子部分。您的构建时间可能会更长一些，但最终的解决方案可能更具可伸缩性。
欢呼,
罗宾
请登录留下评论。
18岁的评论