第十四章 支持

第一节 感同身受

拆掉开发与支持之间的墙
在餐饮业，厨房和前台是两个完全不同的世界。两边能够互相理解和同情是至关重要的。这就是为什么烹饪学校和餐馆经常会让主厨在前堂当服务员，这样他们就能与顾客交流，了解到前线是什么样的。

许多软件开发者的情况与之相似。设计师和程序员在“厨房”工作，而支持人员负责客户。不幸的是，这意味着软件大厨们永远无法听见客户的声音。这是有问题的，因为倾听客户的声音是调整产品优劣的最佳途径。

解决方案？避免在客户和开发/设计团队之间架起高墙。不要将客服团队外包给呼叫中心或第三方。靠你自己来完成。你和你的整个团队应该知道你的客户在说什么。当客户恼火的时候，你需要知道。你要听到他们的抱怨。你也要因此而恼火。

在 37signals ，我们的所有支持邮件都是由产品的开发者人工回复的。为什么？首先，这能给客户提供更好的支持。他们从产品的开发者那里获得直接的回复。其次，这能让我们与客户保持联系，并及时了解他们遇到的问题。当他们感到沮丧，我们也是。我们可以说，“我了解你的痛苦”，我们感同身受。

前线是行为发生的地方。去到那里。让你的厨师成为服务员。阅读客户邮件，聆听他们的挫折，听取他们的建议，向他们学习。

砍掉中间人

在 Campaign Monitor ，几乎所有的开发、支持、营销工作都是由两个人完成的。即使我们不得不扩张团队，我们也绝不会将技术支持从开发团队中剥离。通过人工回复每条请求，我们逼迫自己站在客户的角度考虑问题。

了解你的用户为什么需要，而不仅仅是需要什么，这很重要。这对我们的产品设计有直接的影响。砍掉中间人。当你的耳朵贴近地面，你就更容易给予客户真正需要的东西。

我和许多人讨论过这个问题，第一反应常常是“你不是应该招聘一个初级人员来应付技术支持吗？”设身处地为客户着想。想让牛排按照你喜欢的方式烹饪，你应该和餐厅的杂工交谈还是和真正动手的主厨呢？

—— David Greiner, Campaign Monitor 创始人

第二节 零培训

利用应用内的帮助和FAQ文档，这样你的产品就不需要使用手册或培训
当你使用 Yahoo 、Google 、Amazon 的时候，你不需要一本使用手册。为什么不创建一个无需使用手册的产品呢？努力搭建一个零培训的工具。

如何做到这点？如我们之前提到的，让一切保持简单。应用复杂度越低，用户需要的帮助就越少。之后，利用应用内帮助和 FAQ 文档对可能存疑的地方进行预先支持。

例如：在使用 Basecamp 时，我们在上传 logo 的界面提供了预先支持。因为浏览器缓存的问题，一些用户会看见未更新的 logo 。于是，我们在 “提交 logo”区域的旁边，增加了一个链接，指向一条 FAQ ，向客户解释如何让浏览器强制刷新，以显示更新后的 logo 。在此之前，我们每天收到 5 封关于这个问题的邮件。 如今，一封都没有。

第三节 快速回复

对支持查询的快速回复应该具备最高优先级
当你快速回复问题的时候，客户会很高兴的。因为他们总是在几天之后才收能到一条预设回复。而通过快速、周到的回复，你能够与竞争对手产生明显的差异性。在工作时间，90% 的技术支持邮件会在 90 分钟内得到回复，通常都是半小时内。这深受欢迎。

即使你无法给出一个完美的回复，你也可以通过公开、坦诚的方式获得良好的商誉。如果某人抱怨的问题无法迅速得到修复，可以告诉他们，“我们听到了你的声音，会在未来进行处理。”这可以很好地消除潜在的负面状况。

如果能够以坦诚的态度快速回复，客户会欣赏这种坦率，并从愤怒转变为礼貌。

多数人的军队

一个只有三人的小团队，如何创造一个创新的产品，并在与巨头的竞争中获胜？答案就是争取多数人的军队。

从第一天起就记住，客户是你最重要的资产，他们对你的长期成功至关重要。像皇室一样对待你的用户社区。与巨头竞争的关键是，从小团队开始，重视你的每一个客户。

第一时间提醒你有 bug 的是你的用户，也是他们会提醒你一个从未被满足过的需求，为你摇旗呐喊并传播讯息的也是你的第一批用户。

这不是说你的产品在发布时就必须是完美的。恰恰相反，尽快发布，经常更新。然而，当你的用户遇到 bug 的时候，确保给予一个快速的回复，并感谢他们的告知。

客户并不期待你的产品是完美的，也不期待所有的功能都能够实现。但是，客户希望你在倾听，并对其重视，那就展现给他们。大部分大公司在这方面是有缺陷的，所以要尽快建立起社区意识。

在 Blinklist ，每条客户邮件都会得到回复，通常是一个小时内（除非我们在睡觉）。我们也有一个在线的论坛，我们确保每一个帖子和评论都得到重视。

同样重要的是，所有的开发者都会收到客户邮件反馈，他们也活跃与论坛的讨论。这样，我们慢慢地建立起一个活跃的，忠诚的 BlinkList 社区。

—— Michael Reining, Mindvalley & Blinklist 联合创始人

第四节 严厉的爱

愿意对客户说不
谈到功能要求时，客户就不总是对的了。如果把客户要求的每个功能都添加进去，没人想要我们的产品。

如果我们听从了客户的每一个奇思妙想， Basecamp 将拥有如下这些功能： 全面的时间追踪，全面的账单系统，全面的会议行程安排，全面的日历系统，全面的子任务系统，全面的即时通讯，全面的百科功能，以及全面的你能想象到的一切。

但是，我们从客户调查中得到的第一需求是，让 Basecamp 保持简洁。

这里是另外一个案例：尽管有一些抱怨，但我们决定不支持 IE5 。这意味着我们排除了 7% 的市场。但我们认为更重要的是考虑剩余的 93 % 。为 IE5 修复 bug 和测试的时间与价值不符。我们更愿意为其余的人提供更好的服务。

作为一个软件开发公司，你必须像一个过滤器。不是每个建议都是正确的。我们会考虑所有的需求，但客户不是永远正确的。有时你必须惹恼一些人，但这就是生活。

与此相关，作为一个开发公司，你必须热爱你的产品。如果你的产品充满了你不认同的内容，你不会喜欢的。当你相信这个功能不是必须的，这是另外一个拒绝用户的理由。

第五节 良好的论坛

利用论坛或聊天工具让用户互相帮助
论坛或基于网络的群组聊天是一个让用户提问并互相帮助的好方法。通过消除中间人，你提供了一个开发的交流环境，也节省了你的时间。

在我们的产品论坛，用户发布使用技巧，功能需求，等等。我们时不时地会跳出来提供一些帮助，但论坛整体是一个用户互相帮助，分享经验的场所。

你会惊讶于那么多人愿意互相帮助。

第六节 公开你搞砸的事情

把坏消息公布出来
如果某些事情错了，直接告诉人们。即使他们起初并没有看见。

例如：Basecamp 曾经在某个夜里宕机了几个小时。99% 的用户都不知道，但我们依旧在博客上贴出了“意外停机”通知。我们认为客户应该知道。

当发生错误的时候，我们会这么说：“我们为今早的故障感到抱歉，一些数据库方面的问题导致某些用户的访问延迟和故障。我们已经解决了问题，并采取措施确保不再发生。感谢你的耐心，再次，我们对故障表示道歉。”

尽量保持开放，坦诚和透明。不要隐藏秘密也不要遮遮掩掩。知情的用户是你最好的用户。此外，你会了解到，大部分你搞砸的事情在用户看来并没有那么糟糕。客户通常都乐于给你一些喘息的空间，因为他们知道你是诚实的。

顺便说一下消息的发布，无论好坏：当坏消息来了，马上对外公开。好消息，相反的，则应该一点一点地向外透露。如果你能延续这种良好的气氛，马上做。

保持敏捷、直接、坦诚

听起来可能奇怪，但最好的情况是由公司自己披露坏消息。这是一个主动的措施，能防止公司处于防守的弱势。

—— Greg Sherwin, Vice President of Application Thecnology, CNET, and Emily Avila, Principal, Calypso Communications(from A Primer for Crisis PR)