重点关注扩展内容小小书 XXshu

大约六个月前，我的团队面临着组织公司知识库的挑战。那时，摆在我们面前的是五百篇文章，每篇都用三种不同的语言（英语，葡萄牙语和西班牙语）撰写。我们的目标是对此类知识进行分类，以便以结构化方式对其进行维护和扩展。

我已经专注于所有内容几个月了，但是-从我从不同角度解决问题的过程中-仍然存在一些基本的疑问。

我很愿意单独改进文章或判断整体文档的质量。但是很快就清楚了，如果没有整理一切，也就是没有回答那些根本性的疑问，那么最大的编辑努力和最佳的编辑判断都不会产生重大的变化。

这些疑问很简单，但是答案是构建我们需要的动态，详细信息的关键：

1.版本控制

组织知识库的工作始于最明显的方式：一个电子表格，其中包含我们在Contentful中拥有的文章列表，这是我们已经使用一段时间的CMS。

随之而来的是最初的挑战：如何控制这些文章的翻译阶段？

由于公司中的任何人都可以编辑或创建文章（我们认为这对于保持知识库的可扩展性和价值至关重要），因此文章可以用葡萄牙语和英语出生，但可以保留几个月而不被翻译成西班牙语。或以三种语言诞生，但只能以葡萄牙语翻译进行编辑，而仅保留英语和西班牙语版本。

为了通过电子表格控制数百篇文章中的这些变化而又不会发疯，我们需要一个尽可能平稳的过程。

那时我们借用了学习对象和知识对象的教学设计概念（具有大量诗意）。

我们开始将每个学习对象称为文章。我们将这些学习对象中的每一个视为由不同知识对象组成的实体。

即，学习对象是学习材料，可以交付给用户。它是由知识的不同原子（知识对象）组成的分子。

当平台上的某些内容发生更改时，我们会更新相应知识对象的日期，从而触发其翻译的必要更改。

令人困惑？是的，一点点。但是事实证明，保持这种结构更加令人困惑，因为我们最终建立的电子表格清楚地表明：

我们建立此概念结构的主要原因是我们的翻译问题。我们需要清楚地区分翻译的变化（例如拼写错误）和知识本身的变化（平台或公司中的某些新变化）。

但这意味着每次更改我们仅花费几分钟就更新了我们的控制系统，因为单个更改涉及太多不同性质的概念和实体。

因此，我们意识到我们需要简化整个过程。

我们没有将知识对象视为一个单独的实体，而是将最新的翻译视为正确的知识本身，应将其作为参考。

另外，我们不再使用日期作为参考，而转向版本的概念。因此，对于一篇文章，例如，英语连续遭受五次更改，这些更改的日期并不重要。这篇文章是在葡萄牙语和西班牙语翻译之前的版本，仅此而已。

总结来自公式，该公式明确了我们对每篇文章都需要采取的行动：

2.支持指标

第二阶段与指标有关，尤其是来自客户支持的指标。这是因为文档效率低下导致的最大痛苦是在该团队中。

缺少或难以找到文档=更多票证=支持团队需要更多工作=公司花了更多钱

因此，我们需要了解支持团队对文章用法的演变，以便回答来自客户的问题：

在第一个月，数字并没有说太多，但是随着这一指标的发展，我们开始对我们要去的方向有了更清晰的认识。文档变得更高效，更不高效还是稳定？

为了进一步阐明这种“效率”的含义，我们决定尝试使用Zendesk使用的一种指标： 自助服务分数 。它使用知识库中的唯一身份用户数，然后将其除以同期打开票证的唯一身份用户数，以准确衡量我们想要的内容：文档的“转换”率。

换句话说，利用这个数字，我们想准确地知道要打开一张票需要多少知识库的用户。显然，数字越小越糟。

3.答案在票证中（字面上）

好的，现在我们对文章的健康程度和文档的效率有了更好的了解。但这是我们手中已经拥有的照片。为了使指标移动，我们需要确定文档尚需填补的差距的大小，以及我们团队要解决的问题。

这些问题的答案更难获得，而我们实际上仍在努力使之更清楚。

部分原因在于文档本身的使用：通过观察和衡量用户搜索内容的方式，我们有机会识别搜索最多的术语，效率低下的文章，浏览不善的类别等等。

另一部分-目前在我们日常工作中所占的比例更高-在支持小组答复的票中。毕竟，如果没有记录，我们的一位代理商给出的每一个答复都是错过的机会，可以为我们的基地增加知识。

在使用Zendesk与客户进行交互时，我们的代理商必须将票证标记为“有文档”，“无文档”或“不完整文档”。然后，使用Zapier，我们将关闭每张新故障单，而无论文档有无或文档不完整，都要输入Google表格队列。

那个队列就是我们的金矿：每行代表一个客户提出的文档无法回答的问题-也就是说，它代表了一个机会，可以改进文档并避免涉及同一问题的新问题。

阅读更多关于 Tech plus Com的信息 。