给墨客井畅建议

总体建议

1. 聚焦：资源和人员聚焦在自己的核心事情上。能够在外面找到的工具就用外面的工具，不要自己开发。
2. 敏捷精益，善用市场和社区反馈，持续改善。
3. 用规章流程代替人治。
4. 避免重复劳动，提高效率。所有已经回答的问题就直接给用户文档链接和具体信息位置，这样不要重复解释，既回答了用户问题，还让用户养成看文档习惯。没有回答的问题补充到文档中。这个具体不解释了。
5. 员工社区管理：价值观、利益、流程都得要，一起驱动人。这个具体不解释了。

聚焦

1. 问自己几个问题。

一般都会这么问：我们的核心业务是什么？我们的核心优势是什么？
我会这么问自己：

• 我们对自己的市场定位是什么？
• 商业模式是什么？
• 我们期望比对手优秀100倍的东西是什么？
• 什么是我们在任何情况下都不会放弃、拼了老命要打赢获得的东西？
  我的这几个问题的答案就是自己的焦点。其他的都是次要的。

2. 做减法

贪多嚼不烂，要单点突破。焦点绝对不放弃，打死不放弃。不是焦点的都放弃，或者暂时放弃。
有些能用市场工具就用现成工具，免费的最好，不免费就买。能合作开发就合作开发，这个都能省钱省时间。
有些东西，能够只搞一个的坚决不搞2个。能够不搞的，坚决不搞。要上一个东西的时候，问自己：这个有价值吗？现有的工具里有能够实现的吗？因为上这个我最好砍掉或者撤掉其他哪些东西？例如只搞一个公众号来发布新闻，坚决不搞2个公众号。然后把公众号的链接发布到微博等其他地方，这样微博不需要自己开发新内容。

3. 全力以赴

创业公司就那么点钱、那么点人，创业公司可能赢大公司不是你比别人聪明能干，而是比别人聚焦，比别人灵活，船小好调头。别人同样事情就10个人还层层审批，你是20个人全力以赴。
然后上到CEO董事长，下到一线，都要全力以赴。CEO亲自处理问题，亲自回答社区问题。问题要快速耐心处理。

敏捷精益，善用市场和社区反馈，持续改善

概述

1. 产品也好、文档也好，不要希望一次性做好才发布出去，而是可以分批做，做好一部分就发布一部分，不要把等到最后才一起发布。这样的好处是先出去优先级高重要性高的部分，然后让用户先用起来，他们能马上获得这部分的使用效果。另外，他们能给公司提供建议改善。当然有些安全性高的部分一定要做好才能出去。
2. 用户反馈收集和发布方案。用户反馈按紧急程度和重要性来分有4类，这4类也要告诉给所有用户。让他们知道你们是这么处理的。
   • 非常紧急的：马上解决，马上反馈给用户
   • 比较紧急的：24小时内解决
   • 不是那么紧急的：1-2个星期内解决
   • 一点不紧急的，甚至可做可不做的：要么不做，做的话可以在1-2个月内解决
3. 产品发布周期管理。一般产品按星期来管理，最好2个星期发布一个新版本。重要的新功能提前告诉市场什么时候出来，然后尽量做到。并且提前3-7天就要发布消息确认这个周期要发布的功能。如果不能做到就要在这次发布里说，并且说明推迟的原因和下次推迟的发布时间。每次发布的产品不但有代码出来，还有发布内容的概要，和每个功能的详细的文档。
4. 服务授权。要给一线人员应有的权利随机应变处理。
5. 服务态度。规定详细：
   • 哪些情况下可以踢人、禁言、或者删除留言。
   • 其他情况一概不能踢人，用户的问题要做到100%回答。用户反馈的问题及时反馈，尽量解决。

服务组织架构设计

从客户服务角度来看，公司这样几层人员：

• 一线社区服务人员：他们不分组具体业务（例如运营、开发、营销等）。用户的问题如果属于已解决问题，直接把文档链接给他们。属于没有解决的问题反馈他们马上收集。自己判断：非常紧急的，马上转业务人员分析。不紧急的半天汇总一次，给业务部门。可以用Excel来记录问题，也可以用石墨文档。
• 业务部门人员：对于一线反馈的问题进行分析：
  • 紧急的：必须尽快解决。能马上解决的告诉一线马上解决给用户。不能马上解决的给时间表给一线人员反馈给用户。
  • 不紧急（那种每半天汇总一次的）：进行分门别类
    • 属于文档不清楚的问题：24小时内更新文档，然后告诉一线已解决和链接地址
    • 属于业务中的问题（如营销方案不对、交易有误、产品有错）：给出调整修改时间，然后告诉一线反馈给用户
      业务人员要尊重一线人员，一线人员可以和业务人员问题一起讨论问题处理。

用户反馈的渠道：

鼓励大家有意见去论坛。

• 论坛：每半天收集一次，论坛按照板块主题精心安排。
• 社区QQ、微信群：每天随时收集。群里官方人员不能用昵称，全部改为“一线服务人员-昵称”、“一线服务人员-昵称”，“开发支持-昵称”、“运营人员-昵称”等。让大家可以直接找到人。
• 微博、公众号：每半天收集一次，鼓励大家有意见去论坛。
• 电子邮箱：每半天收集一次，鼓励大家有意见去论坛。
• 其他反馈网站：尽量不搞多了，最好有一个。每天收集一次，鼓励大家有意见去论坛。

文档

1. 文档分为以下几类：

• 用户使用文档：使用攻略、科普文章、用户常问问题（FAQ）
• 开发人员文档：开发攻略、开发者常问问题（FAQ）
• 系统管理人员文档（例如给交易所管理人员、第三方系统管理人员）：系统管理攻略、系统管理常问问题（FAQ）

2. 文档发布原则

文档按照主题编排。
敏捷精益原则：一个小的主题部分文档齐全了，这部分文档就可以发布了。这部分文档不够完美也没关系，后面可以修改。不要等所有文档做完了完美了才发布。

3. 文档更新原则

文档要定期更新，主要是以下2种情形：

• 解决了一个问题，就要马上更新。
• 一个发布周期前，要把发布产品内容的文档更新出去。文档也是发布内容的一部分。
  文档可以用维基、石墨文档、GitHub、简书。

4. 用什么文档工具的原则是：

• 可以直接给出链接到具体信息。那种不能给链接的系统
• 不能持续改善的系统不能用作文档管理。例如微信、微博发布后不能修改，不能用作文档系统。
• 在手机上阅读体验好，也就是能够屏幕自适应。

新闻：

这个用微信公众号为主，微博为辅。