您的产品帮助中心和知识库

帮助中心只有在回答人们实际提出的问题时才能发挥作用，因此我从支持收件箱开始，而不是从页面树开始。我阅读了几个月的对话，将其按用户尝试完成的工作进行分组，并计算每个组的回访频率。这提供了一个诚实的地图：哪些主题值得详细讲解，哪些只需两句话回答，哪些根本不是文档问题，而是产品中的粗糙边缘，任何文章都无法掩盖。

结构遵循这些工作，而不是您的内部组织结构——访客寻找的是他们正在做的事情，而不是拥有该功能的团队。搜索位于其上方：在您输入时提供建议，对拼写错误和错误键盘布局的容忍，以及客户使用的同义词。每篇文章遵循一个模板——简短说明读者将获得的内容、编号步骤、在一句话不足以说明的地方的截图、相关链接，以及一个结束的“这没有帮助”块，将读者引导到支持，并附上文章上下文。

大多数帮助中心跳过的部分是测量。我建立了一个报告，记录返回无用结果的搜索和人们在几秒钟内打开并离开的文章；该列表成为下一个季度的写作队列，而不是猜测。员工获得与其领域相关的编辑权限，并有一个简单的审核步骤，埋藏在旧通信中的答案被移入适当的文章中，并安排每季度进行一次修订，以便中心不会悄然偏离其描述的产品。

工作内容包括：
— 阅读和分组支持请求，以找到真正的优先事项；
— 围绕用户任务构建的部分结构，采用客户的语言命名；
— 带有建议、拼写容错和同义词词典的搜索；
— 单一文章模板：步骤、截图、相关链接、一个“没有帮助”的块引导到支持；
— 关于未回答查询和薄弱文章的报告，以及重写队列；
— 员工的编辑权限和轻量级审核流程；
— 将旧答案从通信迁移到文章中；
— 每季度修订，附带检查清单和指定负责人。

我始终遵循的基本规则：文章在逐步检查与实际产品一致之前不会上线；示例从不包含真实密钥、合同号码或客户数据——所有内容都被替换为明显虚构的值；访客查询匿名收集，搜索内容从不与特定个人关联。