过去几年，我们的所有支持工作都在 Discourse 上进行，除了通过电子邮件处理的计费问题。这对我们来说非常成功，客户经常在没有我们员工介入的情况下互相帮助，员工仅在需要深入故障排除，或需要隐藏敏感话题等情况下才会介入。
然而，随着公司的发展，我们正在考虑采取更广泛的 CRM 方法，主要是为了简化公司其他方面与外部世界的沟通方式。对于支持目的，我们正考虑采用一种模式：初步支持在 Discourse 上进行，但更复杂的技术问题和扩展故障排除可以升级到像 Zendesk 这样的工单系统。
Zendesk 插件似乎能帮助我们实现这一升级路径，但有时支持问题仍会通过错误的方式进入，例如电子邮件、网站联系表单、Facebook 消息等。
因此，我们真正需要的是将进入 Zendesk 的问题“降级”回 Discourse 的方法。
我的偏好是，这些问题会被转发到社区的工作人员收件箱，由工作人员向用户解释我们的支持处理方式，并在将问题公开之前予以确认。我不确定这是否能顺利实现，但我希望尽可能确保支持工作发生在正确的地方。我们的社区足够活跃，如果我能高效地将这些“如何使用”类问题转移过去，许多问题将获得其他用户的精彩反馈。
欢迎提供任何关于如何实现这一目标的建议！
4 个赞
你看过 Tickets Plugin 🎟 吗？我使用 Discourse 作为工单系统，它从根本上来说非常稳固，并且与 Discourse 的核心功能（如标签、分配、消息）无缝集成。不过，仍需要一个可行的仪表盘来监控工单解决情况，确保事项不被遗漏。
更多信息请见：
5 个赞