准备您的 Salesforce 知识库
学习目标
完成本单元后，您将能够：
- 采集加入到知识库的信息。
- 整理信息。
- 确定用户访问权限。
为 Knowledge 采集正确的信息
Maria 意识到了制定计划的重要性。Ursa Major 在使用 Service Cloud 提供一流的客户支持上已经取得了长足的进步。它的个案很有条理，这样客服人员知道下一步去哪里才能快速完结个案。但是她和 Ada 还需要敲定很多事情。
Maria 与 Ursa Major 的顶级支持客服人员 Ada 约好再见一面。他们一起商量把什么信息放到知识库里面。Ada 拥有他们可以用来创建文章的笔记。Ursa Major 网站也有很多常见问题，尽管已经过时了。此外，他们还有关于太阳能部件的制造商数据表。他们很快发现他们已经有很多信息可以添加到知识库里了。
Maria 和 Ada 对于如何编排 Knowledge 文章也有他们的目标。他们想做到这些：
- 帮助创建者抓取正确的内容。
- 创建通俗易懂的文章。
- 使文章容易更新。
- 与不同用户分享文章的不同部分。
下面是设计知识库时 Maria 提出的几个问题。
| 问题 | 示例 | 最佳实践 |
|---|---|---|
| 我们将发布哪种信息？ | 常见问题、程序、产品手册、指引。 Ursa Major 拥有这些类型信息以及其他信息。他们希望以不同的方式发布和呈现不同类型信息。 |
为每一类不同的信息创建一个记录类型。 记录类型决定如何编排每一类文章以及与不同用户简档分享哪些信息。其他重要特征，比如工作流和页面布局，也在记录类型上设置。 |
| 我们是否有现成的知识库或文档可以导入？ | Ursa Major 从 Lightning Knowledge 和 Ada 的笔记开始入手，这样他们不必导入任何东西。 | 使用 Knowledge 导入工具从其他知识库导入文章。 使用 Lightning Knowledge 迁移工具，把 Salesforce Classic Knowledge 的现有内容转入 Lightning Knowledge。 |
| 我们的个案上是否有一些我们希望用来筛选建议文章的字段？ | 产品系列、产品区域、问题类型。 Ursa Major 的重要字段包括太阳能部件以及称作组的部件集合。 |
为每一类搜索筛选器定义数据类别组或者确定哪种用户简档可以看到每个类别或类别组的文章。 |
| 我们是否需要工作流或审批流程来管理文章创建和发布？ | 有些文章要求法务审批，因为包含敏感信息。 Ursa Major 的太阳能电池板有安全要求，因此安装和维修程序必须经过仔细审核。 |
给某个记录类型添加审批流程，以确保指定的审批人批准那类文章，然后才能发布。 |
| 我们与哪一类受众分享我们的信息？ | 不同的受众称为渠道。在一篇文章上设定渠道，以确定哪一类用户可以查看这篇文章。定义这一项之后，用户可以在他们有权访问的任何自助站点看到相应内容。 Ursa Major 有不同类型的用户，因此 Maria 必须想清楚谁应该看到什么。 |
确定什么信息对每个受众可用。如有必要，限制个别字段，以保证敏感信息的安全性，或者用数据类别，限制与特定用户简档关联的特定类别的记录。 |
| 如何跟踪文章反馈？ | 让用户给文章好评或差评。 | 创建关于文章评价的自定义报表。定期回顾报表和文章，保持知识库准确、最新。 |
| 我们如何了解哪些文章是有效的？ | 监控文章被附加到个案的频率。 在 Ursa Major，被引用最多的文章介绍安装太阳能热水器可以为客户省多少钱。 |
看看一篇文章被附加到个案中解决客户问题的次数。 培训时可以与客户或客服人员分享经常被链接到个案中的文章。如果您要翻译文章，可以从这些文章开始。 |
这些足以让 Maria 开始了。既然她知道了她有哪些信息，就可以开始计划如何处理信息了。
为 Knowledge 组织信息
Maria 有大量信息，但是并非所有信息都与每个支持客服人员有关。她必须想出一种合乎逻辑的方法来组织信息。第一步是把信息整理成数据组。
但是她怎么决定使用哪些数据组呢？她仔细研究了 Ursa Major 支持组织的结构。Ursa Major 根据他们支持的产品类型划分支持团队。
- 住宅太阳能安装
- 商用太阳能安装
- 散装太阳能部件
Maria 决定也按团队将信息进行分组。所有团队都可以查看某些文章，比如如何提供客户服务。只有相关团队可以查看其他文章，比如关于商用太阳能电池板的管理规定。
在那些住宅、工业和散装部件组内部，Maria 进一步把信息分成数据类别。对于住宅组，包括的类别有太阳能热水器安装和全屋太阳能系统。将文章进行分类可以让客服人员和用户更快地找到他们需要的东西。
下面是对文章进行分类时要问的几个问题。
| 问题 | 示例 | 最佳实践 |
|---|---|---|
| 信息应该如何分类？ | Ursa Major 按团队对信息进行分组，然后按产品类型分类。 其他公司按地理区域对信息进行分组，然后按产品分类。 |
数据类别组包含数据类别。组越少越好。 定义数据类别组和数据类别时，务必要保证分类对于用户来说是清晰明了的。搜索现有文章或创建新文章时他们必须知道选择哪个组和哪个类别。 |
| 有没有什么信息需要受到限制？ | Ursa Major 在不同州有不同产品和支持客服人员。亚利桑那州独有的产品和销售信息不应该让新墨西哥州的客服人员看到。 | 在简档中设置数据类别可见性，控制哪种用户简档可以访问那个数据类别的文章。 |
| 是否需要增强可搜索性？ | 即使在一个庞大的知识库中，客服人员和客户也必须找到他们需要的文章。 Ursa Major 还没有发生那个问题，不过 Maria 想避免它。 |
识别搜索词的同义词，比如链接和附加。 在搜索结果中突出显示与搜索词匹配的文章片段。 |
确定谁为 Knowledge 做什么
Maria 决定做些什么以允许内部用户查看文章。好消息是所有内部用户默认都可以查看知识文章。所以，Maria 不需要做任何事情就可以实现。
但是查看并不是客服人员唯一会做的事情。最终，许多客服人员会撰写并管理文章。为了弄清楚谁需要对每篇文章做什么，Maria 和 Ada 思考了一篇文章的生命周期。
比如，Ada 想让新手客服人员在解决新问题时创建一篇文章。但是，客服人员把那篇文章发布给更广泛的受众之前，一位更资深的客服人员，如 Ada，必须进行复核。他们将采用与更新文章、文章归档或删除文章类似的流程。
下面是三类常见的用户以及他们所需的权限。
| 用户 | 描述 | 所需权限 |
|---|---|---|
| 仅读者 | 这些客服人员是公司新员工，还没有权限创建文章。 他们用现有文章回答问题，把文章附加到个案中。 与独立解决所有问题相比，这些文章可以帮助他们提高工作效率。 |
阅读 Knowledge 的权限 |
| 投稿人 | 高级 Knowledge 用户，如 Ada。他们有丰富的产品知识，并且了解文章的标准。 他们创建、编辑和发布文章。 |
管理文章权限以及阅读、创建、编辑和发布 Knowledge 的权限。 |
| Knowledge 管理员 | Knowledge 管理员知道何时撤下或删除文章。 | 管理文章权限以及阅读、创建、编辑、归档、发布和删除 Knowledge 的权限。 |
Maria 确定了她有哪些类型信息，并且明确了她将用来整理信息的组和类别。她甚至决定了谁需要访问什么信息。她已经准备好设置 Lightning Knowledge，开始创建 Ursa Major 的知识库。
