此微调介绍了建立工作流程时应考虑的事项，包括：
此外，请务必查看此微调讨论的第 1 部分。要查找更多微调文章，请参阅微调资源。
第 1 部分： 触发器和自行程序
我的上一期砖块微调介绍了构建理想 Zendesk 实例所需的基本部分，以及如何对其进行配置以满足您的特定需求。这一次，我将深入探讨剩余的部分，以帮助您拼凑出理想的工作流程。
触发器
触发器真是个好东西。它们是基于事件的系统操作，在工单创建或工单更新时运行。在 Zendesk 中使用触发器的方式有很多，但都可以归结为以下几个类别：
- 将工单分配给特定的专员或专员组。
- 更改工单字段值或添加/移除标签。
- 向用户（或目标）通知已创建或已更新的工单。
- 更改用户或组织字段值（仅限工单更新时）
潜在的缺陷：
Zendesk 有一些标准触发器，您可能需要取消激活或更改这些触发器。如果您在上线之前未检查触发器列表，最终可能会得到一个满是垃圾通知的收件箱。
将评论更新通知请求者默认触发器是您帐户中最重要的触发器。这是将您的工单评论发送给终端用户的触发器。请注意，如果您更改或删除它，这可能会影响您与客户沟通的能力。
尽量不要让每个触发器做得太多。触发器越复杂，就越难排除故障和维护。
如果您有一个开放的Zendesk Support实例，其中任何人都可以提交工单，并且无需注册，使用以下任意占位符的首次回复触发器（在创建工单时触发）就可能成为转发垃圾信息的目标。
- {{ticket.title}}
- {{ticket.requester.first_name}}
- {{ticket.requester.last_name}}
- {{ticket.requester.name}}
中继垃圾信息是指邮件通过第三方（本例中为 Zendesk）发送到目标，以隐藏电邮地址的来源以冒充第三方。这些占位符是中继垃圾信息的目标，因为它们使用匿名端点，允许任何人输入他们想要的任何文本或链接。
为了避免您的帐户成为转发垃圾信息的目标，请考虑将您的实例配置为关闭或受限，如配置终端用户访问中所述。否则，在开放的Zendesk Support实例中，请勿在您的首次回复触发器的标题或正文中使用上面列出的占位符；请改用静态文本。例如，这可确保在创建工单时发送的电邮通知不会将“尊敬的 Amanda Smith”替换为“尊敬的 www.spam.com”。在其他触发器中（首次回复之后）使用这些占位符是可以接受的，因为届时您就已确定互动是真实的。
最佳实践：
遵循并遵循命名约定。理想情况下，您可以根据触发器的名称来识别其函数。如果您不必单击进入每个触发器以了解其作用，这将为您节省大量时间。以下是一些例子：
设置优先级 - 正常
设置日程计划 - 北美
分配到组 - Tier 1
将评论更新通知请求者
如果您的触发器列表超过一页，则命名约定非常重要。您可以根据标题搜索触发器。
触发器的顺序很重要。每次创建或更新工单时，系统都会检查每个触发器。我的建议是按以下方式对触发器进行排序：
- 更改/更新工单值——用于更改工单值（例如优先级、状态、任何其他字段值）或添加工单的触发器应列在第一位。这是因为这些触发器会影响工单分配和通知。
- 工单分配——将工单分配给组或个人专员的触发器应列在更新工单上任何其他值的触发器之后。
- 通知 —— 向用户或目标发送通知的触发器应列在最后。这是因为您希望系统在发送通知电邮之前进行必要的更改。
在上面列出的每个类别中，触发器从特定到一般条件排序。这样可以防止杂项触发器覆盖更有针对性的触发器。
触发器应尽量简洁明了。触发器越简单，在您扩展或更改管理员时就越易于维护。
要问自己的问题：
- 您的专员是整天都在使用 Zendesk 还是在电邮中？
- 您的哪些专员需要电邮通知？
- 他们何时需要得到通知？
- 您何时需要通知终端用户？
- 你们工作流程中的哪些项目可以实现自动化？
- 您工作流程中的哪些项目需要自动化？
- 您的通知触发器应如何措辞？
在此处了解更多关于如何创建和管理触发器的信息。 
自行程序
自行程序是基于时间的系统操作。它们每小时运行一次，通常具有基于时间的条件。您可以使用自行程序进行以下操作：
- 将工单分配给特定的专员或专员组。
- 更改工单字段值或添加/移除标签。
- 向用户（或目标）通知已创建或已更新的工单。
- 更改用户或组织字段值。
您可能已注意到，自行程序可执行的操作与触发器可执行的操作相同。两者之间的区别不在于它们可以执行哪些操作，而在于哪些条件可以触发它们。自行程序允许您在事件发生后 x 小时后或距事件发生 x 小时后执行系统操作。
潜在的缺陷：
自行程序每小时最多仅运行一次。因此难以依靠它们进行高优先级更新。如果工单在您的自行程序运行甚至一分钟后才到达，一小时后再次运行时，仍可能会看到工单创建时间为 0 小时。
当您设置一个硬性基于时间的条件（例如“自创建后的小时数为 X ”），而不是基于软性的基于时间的条件（例如“自创建后的小时数大于 X ”），您的自行程序可能无法在您的自行程序设置的小时内运行。张工单符合资格。这样您将面临错过重要通知或工单更新的风险。
最佳实践：
在创建自行程序之前，问问自己，是使用触发器还是自行程序更适合获得预期结果。在许多情况下，触发器更有效，因为它们可以即时触发。
创建基于时间的自行程序时，请尽可能使用大于/小于条件，而不是is条件。这样就避免了工单在未触发自行程序的情况下被遗漏的可能性。请注意，这样做时，您需要添加一个无效条件和操作，以避免循环（系统会在必要时发出警告）。
要做到这一点，只需在自行程序运行之前条件检查工单不应该包含的内容（如标签或字段值），然后确保自行程序下次运行时进行更改，使工单不符合资格自行程序运行。这将确保自行程序不会运行多次。
您可以使用自行程序创建一个自动化的“Bug, Bump, Solve ”工作流程。这样可确保您的工单在请求者未回复时不会过时，也可避免这些工单不必要地堵塞您的视图。
要问自己的问题：
- 这应该是触发器还是自行程序？
- 当工单过时时，您是否需要系统通知您或进行操作？
- 工单在关闭前应处于已解决状态多长时间？
- 您的通知电邮应如何措辞？
在此处了解更多关于如何创建和管理自行程序的信息。
第 2 部分： 业务日程计划和 SLA
营业日程计划
业务日程计划可能不像触发器或自行程序那么华而不实，但仍然可以在您的工作流程中发挥重要作用。设置营业日程计划可以：
- 在营业时间内外，使用触发器和自行程序执行系统操作。
- 在自行程序和 SLA 中以营业时间（而不是日历时间）指定时间。
- 通过 SLA 提供准确的服务目标。
潜在的缺陷：
列表中的第一个日程计划是您的默认日程计划，它将应用于所有新工单。您无法重新排列日程计划，换言之，您无法将新的或现有的日程计划设置为您的默认日程计划。您将需要删除其上面的每个日程计划（或更改其名称和属性），以便将新的日程计划设置为默认日程计划。
您可以在日程计划中添加节假日，但它们无法逐年延续。这意味着您必须手动输入每年的值。
节假日是将从您的营业日程计划中删除的日期。这意味着如果您只工作半天，基于营业时间的 SLA 将暂停全天。（这也可能是一件好事，具体取决于您如何看待。）
您无法复制日程计划。这意味着您需要在每个日程计划中手动输入每年的节假日。
确保设置您的时区！只有时区正确的日程计划才会生效。在某些服务模式类型中，您可以设置每个日程计划的时区。对于其他服务模式类型，您可以在这里设置日程计划。
最佳实践：
在开始输入日程计划之前先制定计划。首先输入您的默认日程计划（如果您有的话）。此日程计划将默认应用于所有新建工单，也就是说，使用营业时间应用于工单的任何 SLA 都将遵循此日程计划。
如果您使用多个日程计划，请使用触发器将日程计划分配到工单。例如，您可以创建一个触发器，当工单分配给 x 组时，分配给计划 x。如果您对所有日程计划都这样做，则无论将哪个日程计划设置为默认日程计划，都没有关系。
您无法复制日程计划，但可以复制节假日！您仍需要手动输入，但至少可以复制并更改日期。这是输入重复节假日的最佳方式。
在创建节假日时，您无法设置缩短时间。这整天都将从日程计划中排除。将这些天用作补习班，因为它们的工作量可能会较低。
要问自己的问题：
- 您是否全天候为终端用户提供支持？
- 您是否有团队仅在特定的时间或日期有空？
- 有没有节假日减少工作时间？
- 您应创建多少个不同的日程计划？
业务日程计划在 Team 服务模式中不可用。详细了解如何创建和管理日程计划在这里。
SLA 政策
许多公司都会向客户做出承诺，决定特定活动的预计持续时间。
Zendesk 服务级别协议允许您通过添加服务目标来确定工单的优先级。可用的目标包括：
- 首次回复时间（从工单创建到专员首次公开评论之间的时间。）
- 请求者等待时间（工单处于“新建”、“已开启”和“暂停”状态的总时间。）
- 专员处理时间（工单在“新建”和“已开启”状态停留的总时间。）
- 下一次回复时间（终端用户评论与专员下一次公开评论之间的时间。）
- 定期更新（专员发表公开评论与专员下一次公开评论之间的时间。）
- 可暂停的更新（工单处于“新建”、“已开启”和“暂停”状态时专员每条公开评论之间的时间）。当工单进入“待回应”状态时，监测会暂停。）
潜在的缺陷：
Zendesk SLA 要求您使用系统优先级字段。如果工单未分配优先级，则您的SLA政策将不会应用。
如果您的 SLA 基于营业时间，并且您有多个日程计划，那么您需要确保每张工单都应用了正确的日程计划。除非另有说明，每张工单都将使用默认的营业日程计划。
当专员创建工单时，将立即满足首次回复时间目标（即使他们将请求者设置为终端用户）。这是因为工单描述将计为专员的首次公开评论。由于此目标将立即得到满足，因此这张工单看起来像是已处理过。
下一次回复时间目标不适用于内部工单。此目标衡量的是终端用户评论与专员下一条公开评论之间的时间，因此此目标将忽略专员请求的任何工单。
避免在一个政策中使用每个目标。您可以选择请求者处理时间和/或专员处理时间。没有必要在同一个政策中使用这两个目标，否则会使事情过于复杂。
违反SLA不能作为符合条件的事件在触发器中使用。这意味着无法创建即时违反通知触发器。
最佳实践：
您可以使用六种不同的目标。您不需要（也不应）在一项政策中使用所有这些功能。
首次回复时间目标有助于确保在合理的时间内处理每张新工单。出于同样的原因，下一次回复时间目标也同样重要。一般而言，我们建议将 NRT 目标构建为与同一政策中的 FRT 目标非常相似或完全镜像。
在专员处理时间和请求者等待时间之间选择一个或不选择一个，因为它们都是衡量解决工单所需的时间。AWT 是从专员的角度衡量这一点，因此当工单处于暂停和/或待回应状态时，它会暂停工作。RWT 是从请求者的角度衡量这一点，因此仅在工单处于待回应状态时才会暂停。
在“定期更新”和“可暂停更新”之间选择一个或不选择，因为它们都是衡量专员公开评论之间的时间。
要问自己的问题：
- 你们是否有合同规定的义务来实现特定的服务目标？
- 您有内部服务目标吗？
- 您需要多份保单还是一张一整套保单？
- 您如何确定工单的优先级？
- 对于解决工单所需的时间，您是否有服务目标？
如果是，应该从请求者的角度还是专员的角度来衡量？ - 您是否 24/7/365 为您的所有客户提供支持？
您想根据日历时间或营业日程计划检查目标吗？
SLA政策在 Team 服务模式中不可用。了解更多关于如何创建和管理 SLA 的信息在这里。
第 3 部分： 宏和视图
宏
宏是专员激活的脚本，可一次对工单执行多个操作。请务必注意，宏只能做专员能做的事，工单更改只有在专员更新工单后才会保存。
使用宏可以减少专员的点击次数，从而提高其工作效率。
宏可以：
- 添加评论文本
- 更新工单字段（仅限下拉菜单和复选框）
- 添加或移除工单标签
- 添加抄送
- 更改受托人
- 设置工单标题
- 为工单评论添加附件
潜在的缺陷：
宏本质上是专员的快捷方式。宏只能做当前用户能做的事。例如，如果专员没有权限编辑工单标签，则当该专员运行宏时，宏不会添加或移除标签。
宏不会更新文本、多行文本、日期、数字或正则表达式工单字段。
最佳实践：
就像下拉字段一样，您可以嵌套宏。嵌套宏是一种很好的组织并保持宏整洁的方法。
您可在一次工单更新中运行多个宏。这意味着您不必为每种可能的情况构建宏。尽量简洁明了。
使用占位符！评论的开头为{{requester.first_name}}会使您最通用的回复看起来像是个性化的。您也可以在设置工单标题时使用占位符。
您可以将宏分配给所有专员或特定的组。如果一个宏只对少数专员可见，请确保只有这些专员可以看到宏，以免造成混乱。
您可以搜索宏。当您在工单内的宏菜单中时，开始输入宏标题，它将筛选菜单中的宏。
要使宏易于搜索，请创建并严格遵循命名约定。
使用宏一次更新多张工单。为此，您可以在视图屏幕上勾选多张工单旁边的复选框，然后点击右上角的黑色编辑工单按钮。到达那里后，应用宏并提交。
您可以将触发器和自行程序与宏结合使用。例如，您可以创建一个宏，添加一个可立即激活触发器的工单标签。想想所有的可能性！
要问自己的问题：
- 您的终端用户最常提交工单的原因是什么？
- 您的评论文本应该说什么？
- 您的宏应该留下公开评论还是私密评论？
- 哪些专员应有权访问哪些宏？
宏在所有服务模式中可用。详细了解如何创建和管理宏在这里。
视图
我把最好的部分留到最后再说。视图可能是工作流程中最重要的部分。视图决定了哪些工单对您的专员可见，以及它们的处理顺序。
视图不是文件夹。它们是已保存的搜索或已筛选的数据库。可以将其视为 iTunes 中的智能播放列表。
潜在的缺陷：
不要创建过于复杂的视图。视图中的条件越多，结果的筛选程度就越深。这可能是一件好事，但也可能带来灾难。如果您的条件过多，您可能会失去工单。
如果视图过多，专员可能无法按照您希望的方式对工单进行优先级排序。请减少视图，仅显示必要内容，即可避免这种情况。
如果您使浏览器保持打开状态，视图将不会自动更新。每次您单击视图（或刷新页面）时，它都会刷新。
视图 每页最多只能显示 30 张工单。如果您的视图未正确排序，您可能会错过重要的工单。
最佳实践：
和宏一样，视图可以分配给所有专员或特定的组。在许多情况下，为每个组创建自定义视图是有意义的。这样可确保每个专员只看到相关信息。
如果您正在使用 SLA，最好按违反下一个SLA对视图进行排序。这将确保所有工单最终都将筛选到顶部。
使用播放按钮！“开始”按钮位于视图页面的右上角，可直接进入视图中的下一张可用工单。
要问自己的问题：
- 您的工单应如何排列优先级？
- 每个组应看到哪些工单？
- 你们如何对工单进行分类？
在此处了解更多关于如何创建和管理视图的信息。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。