有人定制过 Discourse 作为 CRM（客户关系管理）系统吗？

[debryc (Deborah Chang)]

我所在的组织是去中心化的，每个部门都有全权与其他组织建立合作伙伴关系。不过，我们需要一种方式，让不同部门之间能够共享与合作伙伴的关系信息，以确保我们对任何单一合作伙伴的接触方式保持一致，即使该合作伙伴与多个部门都有往来。

通常，组织会使用客户关系管理系统（CRM），并培训员工始终记录与任何组织合作伙伴的通话和消息。然而，我希望尽可能减少所需系统的数量。有人曾定制 Discourse 作为面向组织合作伙伴的轻量级 CRM 吗？如果有的话，是如何实现的？

我目前的想法是创建一个“合作伙伴”分类，为每个合作伙伴设立一个主题帖。该分类将配备一个主题模板，要求填写每个合作伙伴的相关信息，包括其关联的部门。然后，员工在希望建立新关系之前，应首先在该分类中搜索潜在合作伙伴，并查阅我们与该合作伙伴的历史记录。

不过，我还在思考如何让这一流程更加无缝流畅，同时也想知道是否还有其他我尚未考虑到的解决方案。我们目前的解决方案是一个 Google 表格，用于跟踪每个合作伙伴在合作流程中的状态，并能快速浏览列表以确保没有遗漏任何合作伙伴。该表格还支持按部门筛选，而我不确定如果迁移到新系统后是否还能实现这一功能。

大家有什么建议吗？

[pfaffman (Jay Pfaffman)]

这和我想的大致一样。你可以让各个教学部门给他们的主题打上部门标签，这样就能按标签搜索了。Discourse 可以强制要求他们必须选择标签。

这有点笨拙，但我见过的（或者说稍微了解过的）CRM 系统似乎都更糟糕（说这话的人可是靠 Discourse 谋生的）。

[osioke (Osioke Itseuwa)]

@debryc

我目前的想法是创建一个合作伙伴分类，为每个合作伙伴分配一个主题。该分类将使用一个主题模板，要求填写每个合作伙伴的信息，包括他们与哪些部门有关联。这样，人们在寻求潜在合作伙伴时，会首先在该分类中搜索，并在建立新关系前了解我们与该合作伙伴的历史。

没错！这样可行。我们这里也采用类似的设置，而且正如 Jay 所说，标签也很有帮助。

[debryc (Deborah Chang)]

@osioke

没错！这个方法可行。我们这里也采用了类似的设置，而且正如 Jay 所说，打标签也很有帮助。

你们如何系统化地确保信息得到及时更新？大家是否有共同遵循的规范？此外，主题帖中应包含哪些信息，又有哪些内容不应包含？

[debryc (Deborah Chang)]

@pfaffman

你们可以让教学部门用部门标签来标记他们的话题。

我确实考虑过这个选项，但每个部门已经有了自己的分类，所以我很不情愿让标签也使用完全相同的名称。我在想，是否有一种方法可以在“合作伙伴”分类中搜索部门分类名称，并生成一个话题列表。我是不是想得太复杂了？

[JonathanShaw]

@debryc

每个部门已经有自己的分类了，所以我很不情愿让完全相同的名称同时作为标签。我在想，是否有一种方法可以在“合作伙伴”分类中搜索部门分类名称。

你能把“合作伙伴”设为标签而不是分类吗？在这种情况下，两者的主要区别可能在于：使用标签时，你对分类/标签页面的落地浏览体验以及分类/标签列表的控制力较弱，但在你的情况下，这应该无关紧要。

[osioke (Osioke Itseuwa)]

一直以来都是如此，因此每个人都清楚需要查找包含每位客户信息的主题，并在必要时更新该主题。此外，由于需要在多个地方搜索才能获取信息，这种不便也促使大家避免这种情况。

除此之外，部分团队成员负责客户关系管理，作为社区管理员，他们也有助于将社区中的帖子重新整理到正确的位置，他们也会进行同样的操作。

总之，这已经是一种既定的习惯，因此很容易继续保持下去。

[debryc (Deborah Chang)]

@JonathanShaw

能否将“合作伙伴”设为标签而非分类？

这对我们来说行不通，因为那样的话，合作伙伴主题就必须归属于某个部门分类下，而我们的初衷正是一个合作伙伴可以同时与多个部门合作。我认为，单独设立一个“合作伙伴”分类是最合理的做法。

[debryc (Deborah Chang)]

@osioke

我们这里也采用类似的设置，正如 Jay 所说，打标签也很有帮助。

你们使用哪些标签？我最纠结的是，既然已经有了部门分类，是否还需要部门标签。我还在考虑利用我们的项目状态标签来追踪合作伙伴从构思阶段到理解阶段等的进展。

@osioke

除了上述内容，部分团队成员负责客户关系，作为社区管理员，他们会协助将社区帖子重新整理到正确的位置，他们也进行同样的操作。

好主意。你们执行的具体准则有哪些？

[Mevo]

@debryc

阅读一下我们与该合作伙伴的历史

Deborah，读了你的想法（看起来不错），我建议你将首帖设为“Wiki 帖”。在我看来，将所有大家需要的信息保持最新并集中在首帖中，比让大家去阅读整个主题（时间一长主题可能会变得很长）更有意义。你可以保留该主题用于讨论和/或补充细节，并将所有重要内容汇总到首帖中。你“只需”实施相应的流程即可实现这一点。

注：Discourse 团队在 meta 上处理某些主题时正是采用这种方式。这似乎是一个很好的做法。

@debryc

一种以某种方式在合作伙伴分类中搜索部门分类名称并生成主题列表的方法。

嗯，我想基本上是的！那应该叫做……搜索，对吧？
（通过将该搜索限制在“合作伙伴”分类中，来搜索你想要的部门名称）

[JonathanShaw]

@debryc

每个部门已经有自己的分类了，所以我非常不愿意让完全相同的名称也作为标签出现。

也许这正是需要做出妥协的地方。如果你将这些内容放入一个标签组中，或许可以设置使其在“合作伙伴”分类之外不可访问。

[osioke (Osioke Itseuwa)]

@debryc

你们使用哪些标签？

我们使用一个通用标签来标记客户项目，所有内容都归属于一个更广泛的业务类别。

@debryc

你们执行的具体准则是什么？

在通常意义上，我们并不强制或执行任何规定。我们很幸运，团队成员都秉持相似的价值观，比如良好的沟通和有序的信息整理。因此，一切都能顺利运作。

我相信这是因为团队中的每个人都曾有过社区运营的经验，因此他们理解将一切妥善分类和结构化的必要性。

[pfaffman (Jay Pfaffman)]

或者，只需创建不易混淆的标签，例如 crm-<client-name>，并将其限制在 CRM 类别中且设为必填。

[debryc (Deborah Chang)]

@Mevo

将首帖设为“维基帖”

完全没问题！

@Mevo

（通过将搜索范围限制在“合作伙伴”分类来搜索您想要的部门名称）

是的，这确实可行，但感觉有点笨拙……

@JonathanShaw

如果你把这些放入一个标签组，或许可以设置成在“合作伙伴”分类之外无法访问。

我甚至都没考虑到这点！我很喜欢这个主意。

@pfaffman

或者，直接创建一些不易混淆的标签，例如 crm-<客户名称>，并将它们限制为仅在"CRM"分类中可用且必须使用。

这也是个好主意！

好的——我要去试试了，看看会发生什么。

[osioke (Osioke Itseuwa)]

@debryc

好的，我去试试，看看会发生什么。

太棒了！记得分享你最终的成果。

[Dr_Yasmine_van_Wilt (Dr. Yasmine van Wilt, FRSA)]

在数据、关系等方面，是否存在不同程度的敏感性？

[Dr_Yasmine_van_Wilt (Dr. Yasmine van Wilt, FRSA)]

我不确定这是否有帮助，但我们构建了一个本体，该本体针对一组特定需求或结果对概率进行了加权，使我们能够使用元数据标记系统，正如 @JonathanShaw 和 @pfaffman 所讨论的那样。