考虑一个或多个 Zendesk 实例

您的公司可能有多个组织，包括各种具有不同流程、安全需求和工作流程的部门。考虑是否有一个 Zendesk 实例对于您的情况很好，或者如果多个实例更好，这非常有用。这篇文章说明了使用多个 Zendesk 实例而不是仅使用一个实例的优势、考虑和后果。它涵盖以下主题：

• 功能考虑因素
• 对问题进行限制
• 概要

功能考虑因素

此主题涵盖了针对多个团队使用一个 Zendesk 实例的影响，以获得以下功能： 

• 全局设置
• 业务规则
• 整合
• 身份验证和访问
• 终端用户管理
• 专员权限和工单访问
• 报告
• Web Widget（经典）和 Chat 小组件
• Guide

全局设置

这个组别说明了全局设置的考虑因素。 

• 订阅
  如果您有一个 Zendesk 实例，所有专员都必须在 Support、Guide、Talk和 Chat 相同的服务模式类型中。对于 Guide，所有 Support 专员必须是 Guide 专员。只有一个团队利用 Guide，这是一个节省成本的考虑。

• 专员签名
  每个 Zendesk 有一个原生全局专员签名。作为解决方法，您可以为每个团队自定义触发器，在触发器或液体标记条件中签名。

• 电邮模板
  每个 Zendesk 只有一个原生电邮模板。解决方法是自定义所有支持HTML、CSS或液体标记的业务规则。请查阅了解液体标价和Zendesk Support。
  

• 欢迎/验证电邮
  只有一个原生终端用户欢迎电邮/验证，在设置>帐户中添加了帐户名称。

• 子域名
  您只能有一个子域名供所有专员使用和记住。无法自定义专员子域名到团队名称。
  
  
• 任何人都可以提交请求？
  一个 Zendesk 帐户必须为所有用户打开，或已关闭给所有用户。如果打开的话，任何人都可以提交请求、登录 Guide，或用小组件提交工单。如果关闭，终端用户必须是 Support 中的现有用户才能提交请求，或访问 Guide。请查阅 配置终端用户如何访问并登录Zendesk Support。
  
  
• 帐户名称
  • 只有一个帐户名称。请查阅 如何在Zendesk Support中更改帐户名称。
  • 如果使用格式的 占位符，帐户名称将在电邮中可见。帐户名称是发送的电邮和对终端用户可见的一部分。要忽略此项，您需要停止使用格式的占位符，并使用丰富内容占位符，而不是支持格式文本。然而，这消除了格式占位符的美化体验。
  • 最后，帐户名称在登录页面/提示中可见，不可编辑。

• 允许用户属于多个组织
  如果您决定跨不同的团队使用一个 Zendesk 实例，那么整个实例都已启用或禁用一个全局设置。
  
  
• 满意度调查
  尽管整个 Support 实例已启用或禁用满意度调查，但您可以编辑某些组无法触发业务规则。您可以使用占位符为任意工单生成满意度链接。请查阅使用客户满意度占位符。
  
  
• 数据导出
  工单、用户和组织的数据导出为整个帐户的全球。然而，您可以使用 Zendesk Core API 抓取更多特定的数据。
  
  
• Tags
  在有多个团队的实例中，对于多个工作流程或资源，标签不应该循环。

业务规则

这个组别说明了业务规则的考虑因素。

• 触发器、自行程序、视图和 SLA
  • 在所有工单上运行的业务规则，但是他们易于限制在查找工单组或品牌的条件中。请查阅 在业务规则中使用组。 管理员为全局版，可在其管理范围以外的组创建规则。这将为一个团队编辑规则创建一个团队编辑规则，影响其他团队的工单和工作流程的风险。 
  • 如果您在同一个 Zendesk 实例中使用不同的团队，那么要管理的规则越来越大量。 更高的复杂度需要更改管理策略和持续进行的跨团队协作。 也有增加工单被误设置为错误的组的风险，这可能对 SLA 产生影响。
  • 您还需要考虑保密信息或安全信息，其不可访问的专员。没有原生方法可按组组织业务规则。
  • 为了协助业务规则组织/分组，占位符触发器或自行程序可创建，其功能除名称之外，有助于创建团队分类的体验。
    
    
• 宏
  宏访问可配置给组中的所有专员或专员。请查阅为工单创建个人宏 了解更多信息。
  
  
• 工单字段和工单表格
  • 工单字段和工单表格是整个实例的全局性。所有团队都可以看到所有的表格和字段。自定义工单表格需要有不同的团队和终端用户体验的唯一表格。
  • 在专员界面中，一个自定义应用可根据当前正在查看工单的专员隐藏或显示某些字段。您也可以考虑在 限制工单表格的文章中实施概述的食谱。
  • 帮助中心代码自定义可隐藏请求表格中的非必填终端用户可编辑字段。

整合

这个组别说明了整合的考虑因素。

• JIRA
  Zendesk JIRA整合的 v3 是一对一。您无法将多个JIRA整合链接到一个Zendesk Support帐户。
  
  
• 自定义整合
  多个 Support 实例需要设置和配置每个自定义整合。 例如，为每个 Support 实例运行数据导出或连接到用户数据库需要双方的开发和配置。
  
  
• 应用（ZAF）
  应用需要在每个 Support 实例中安装和配置。 如果原生选项不够颗粒状，您可以代码自定义应用来检查用户组并隐藏或显示应用。 可以指定每个组或自定义用户角色对应用的访问。请查阅按组限制应用可见度。

身份验证和访问

这个组别说明了身份验证和访问的考虑因素。

• 基本身份验证
  使用多个 Zendesk 实例，登录（用户名和密码）对每个实例都是唯一的。专员和终端用户将需要管理并记住两组凭证，用于使用原生 Zendesk 身份验证的多个实例。
  
  
• API 访问
  API密钥是全局的，这意味着任何带有API密钥的用户都可以访问帐户中的所有资源和数据。
  
  
• OAuth
  OAuth密钥可以范围仅访问某些资源。 然而，密钥不能限定为专员组。
  
  
• 单点登录 (SSO)
  • 原生SSO应用于专员和终端用户配置的完整实例。所有团队的专员和终端用户将需要在SSO身份提供者中进行配置。
  • 用户可以使用不同的身份验证方法（Zendesk 身份验证和SSO），但这必须在客户侧建立。请查阅 有电话：我准备好了更高级的身份验证选项吗？。

终端用户管理

这个组别说明了用户管理的考虑因素。

• 组织和用户字段
  组织和用户字段是整个实例的全局字段，这意味着所有专员都可以查看并编辑它们。与工单字段一样，一个自定义应用可根据查看的专员隐藏或显示某些组织/用户字段。
  
  
• 组织管理
  • 组织为整个实例全局。专员组无法细分组织或组织查看权限。
  • 对于 组织工单共用功能，访问权限将对所有组织中的工单全局。 如果此选项已启用，它将影响所有使用 Support 和 Guide 的团队的工单。
  • 组织名称必须是唯一的。虽然用户可以属于多个组织，但不能有两个具有相同名称的组织来容纳多个团队。
    
    
• 终端用户权限和访问权限
  • 所有终端用户都是整个实例的全局性。不允许一个终端用户在实例中向一个团队提交请求，但不允许向另一个团队提交请求。
  • 终端用户身份验证的主要方法仅支持原生。终端用户可以登录所有帮助中心实例。有一些工作流程忽略了这一行为，但他们是高度自定义的，需要客户侧的一些开发。 

专员权限和工单访问

• 编辑终端用户的专员权限
  根据服务模式类型，有几个考虑：
  • 自定义专员用户角色：如果您的服务模式类型包括自定义用户角色， 您可以允许一组专员编辑终端用户个人资料，但不是另一个。专员可以查看所有终端用户的用户个人资料。有一个边缘配置，一名专员没有权限访问另一个组中的工单，但可以访问编辑终端用户。包括专员可以看到终端用户请求的所有工单。
  • 专员用户角色： 在没有自定义专员用户角色的服务模式类型中，只有可访问 所有工单 的专员才能添加、编辑或使用终端用户。
  • 一个团队的专员被视为另一个团队的终端用户的特殊用例：专员无法使用帮助中心提交工单，因此，任何终端用户表格都将无法供专员使用。无论组权限如何，专员都可以访问其请求者所在的工单，这意味着他们可以访问其请求者的任何内部通讯。
    
    
• 组管理和工单访问
  • 组为整个实例全局。可以创建组以管理多个团队，并按组限制工单访问。
  • 在Enterprise服务模式中，您可以创建私密工 单组。私有工单组可根据组分配提供更颗粒状的控制，从而对工单的可见度和访问进行更颗粒状的控制，从而完全隐藏那些没有权限查看的专员。
  • 在Enterprise服务模式中，您可以使用自定义专员用户角色控制专员对私密工单组的访问，包括将其工单分配给私密组的能力。

报告

这个组别说明了报告的考虑因素。

• 报告
  
  • 如果使用一个实例，报告将集中。 所有工单、用户和组织数据都可供所有用户访问报告。
  • 在不同的服务模式中，访问工单控制对报告的访问。专员需要访问所有工单以查看报告。
  • 默认报告面板对所有 Support 数据具有全局性，也就是说，报告根据组或某些其它工单级别属性（自定义工单字段、工单品牌等）进行自定义构建。
    
    
• 原生报告
  原生报告（不是Explore）概览、知识、社区、搜索和Talk是整个实例的全局分析。

Web Widget（经典）和 Chat 小组件

这个组别说明了Web Widget（经典）和 Chat 小组件的考虑因素。它们可能无法应用到消息传送Web Widget。

• 原生自定义和外观（颜色、位置、按钮文本）是全局性的。可以使用 Widget API 自定义每个团队的小组件，但需要自定义开发。
• 工单表格需要每个团队提供量身定制的表格/字段体验。
• 小组件中的帮助中心搜索将搜索整个知识库，仅搜索一个知识库。然而，有了一些自定义开发， 您可以自定义搜索结果。
• 小组件可以开或关在线交谈，如果只有一个团队使用 Chat，就可以有影响。您可以使用小组件API和 Chat API自定义覆盖此设置。

Guide

这个组别说明了指南的考虑因素。

• 专员的权限
  • 如果多个团队使用一个 Guide，需要协作策略。例如，一个团队中的专员将可以管理内容并编辑其他团队的主题，即使您正在使用多品牌。
  • 文章编辑和创建权限是 Support 设置和 Guide 组别级别设置的混合。Zendesk Support管理员默认是 Guide 管理者。
  • 如果您在带有自定义用户角色的服务模式类型中，您可以创建自定义用户角色，并设置 Guide 管理者权限。如果您属于另一个服务模式，您可以在专员的个人资料页面上控制谁是 Guide 管理者或查看者。请查阅 理解 Guide 用户角色和设置权限。
  • 专员可在 Support 中设置为查看者，但仍可以在所有部分设置为管理者和专员的组别权限中创建和编辑文章。

• 终端用户体验
  • 如果您使用一个 Zendesk，所有终端用户都可以登录所有帮助中心。如果当多个团队使用一个Zendesk Support工单实例时，终端用户将有一组登录凭证，而如果团队使用单独的 Support 实例，那么终端用户将有一组登录凭证而不是多个登录凭证。
  • 如果使用一个 Support 实例，终端用户可以在一个地方查看所有工单。然而，如果工单处于不同的品牌，则不适用。
  • 用户区段 和权限策略需要管理谁可以查看所有与一个 Support 实例关联的帮助中心内容。
  • 最后，如果一个团队中的专员是另一个团队的终端用户，他们将有一个缩小的帮助中心体验。他们将重定向到 Support 提交和查看请求。

对问题进行限制

在您做出最终决定之前，请考虑这些范围范围的问题：

所有专员是否可访问所有工单？

如果您使用多个团队的一个 Support 实例，以下是允许访问所有工单，或不允许访问所有工单的考虑。

允许访问所有工单：

• 如果专员可以访问所有工单，使用业务规则（视图、触发器、自行程序、电邮模板）为每个团队设置和单独的工单路由，因为业务规则对于整个实例是全局的？ 
• 例如，如果两个团队（Support 和 Sales）使用一个 Zendesk，每个团队的路由触发器（以及每个自动回复/评论更新的触发器）需要自定义每个团队的终端用户体验。 
• 在 SLA 方面，工单被误解的风险增加。

不允许访问所有工单：

• 组或自定义用户角色的配置需要限制访问。
• 需要谨慎的工单路由管理，因此工单不会意外转接到不应该访问工单的组。
• 限制专员对其他历史或当前请求的可见度。工单访问限制也可以限制专员访问报告。
• 取决于您的配置，如果受限专员可以使用终端用户使用权限，他们将可能在帮助中心里从 我的活动 中访问工单以外的工单。

有一个集中或现有的用户管理策略吗？

专员和终端用户需要考虑的项目包括：

• 对于 Zendesk 身份验证，两个实例中的专员将有两组凭证。
• 如果您使用SSO，Zendesk 需要配置为两个实例的服务提供商。如果您在传递自定义用户数据，您需要在两个实例中创建用户或组织字段。所有自定义用户字段、组织和用户角色都有独特的 ID，需要配置独特的SAML/JWT断言。

终端用户的其他考虑因素包括：

• 终端用户是否可访问这两个团队的帮助中心内容（例如，HR 和 Support 都使用一个实例？
• 终端用户是否可访问所有 HR 和所有 Support 内容？  

概要

以下是使用一个实例与多个实例的优势和考虑的快速概览：

如果您使用一个 Zendesk 支持实例，那么好处包括：

• 统一的客户体验。
• 统一的报告。
• 专员成本：两个团队的专员仅需要一个许可证。
• 跨部门升级或跟踪问题在一个 Support 实例中更容易。
• 统一的用户管理和身份验证：
• 为用户提供单一事实来源。
• 360 视图的客户。

要考虑的项目是：

• 在某些服务模式类型中，限制对工单的访问是复杂的。
• 其他团队的终端用户的经验正在缩小。
• 需要一个定义的更改管理流程和策略。
• 已提高工单路由和业务规则的复杂性。
• Support 的许多可自定义功能都已全局配置（例如身份验证、电邮模板、帐户名称或欢迎电邮）。

如果您使用多个 Zendesk 实例，那么好处包括： 

• 隔间化更容易。
• 灵活更改，不会影响其他团队。
• 独立且可完全自定义的第 0 层/自助服务和知识工作流程（KCS、Answer Bot、团队发布）。
• 每个团队完全可自定义和量身定制的终端用户体验（p绳子终端用户体验为其他团队的终端用户）。
• 通过团队控制工单访问和安全。

要考虑的项目是：

• 多个实例的配置和分析费用。

• 所有实例所需的SSO、应用和整合配置。

• 终端用户需要前往不同的地方提交请求或自助服务。

• 由于在 Support 实例之间使用工单共用，专员协作复杂度增加。

• 专员冲突功能在两个 Support 实例之间不起作用。

• 虽然工单共用允许两个团队使用 Zendesk 进行协作，但工单更新将从一个 Support 实例的工单到另一个支持实例的工单更新进行扰。

• 对于某些服务模式类型，可以通过创建私密工单组来控制工单访问和安全。

翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性

如对翻译准确性有任何疑问，请以文章的英语版本为准。