第十四章 技术支持
感知痛苦
拆除研发和技术支持之间的墙壁
餐饮业中，在厨房干活和在前台服务顾客是两个截然不同的世界。这两边的相互理解和支持尤为重要。这就是烹饪学校和餐馆经常让厨师在前台作侍者服务顾客的原因，这样厨房的员工就可以和顾客接触并且体会到前台工作的真实情况。
很多软件开发人员也有类似的分工。 设计者和程序员在“厨房”工作， 支持人员应对客户。 不幸的是，这意味着软件大厨从来不会听到客户的真实意见。这是很有问题的，因为倾听客户的声音是你改善产品优缺点的最好途径。
解决方案？ 避免在你的客户和研发/设计之间竖起一堵墙。 不要把客户支持外包给呼叫中心或第三方。而是自己来做。 你，和你的整个团队，应该搞清楚客户的意见。 当客户烦恼时，你需要知晓。你要听他们的抱怨。你也要因此烦恼。
在 37signals公司， 所有我们的技术支持邮件，都是真正的产品构建者亲自回复。 为何如此？ 首先， 这为客户提供更好的支持。 他们得到了从构建应用的某人脑中想出的一个 直接回应。 其次，这使我们和使用我们的产品并且遇到问题的人们保持接触。 当他们受挫时， 我们也受挫。我们可以说， “我感知到了你的痛苦”，并且我们感同身受。
依靠统计分析来揭示问题点，很有诱惑力。但是统计数字和真实声音不可能一样。 你需要尽力去消除尽可能多的这种缓冲区，它挡在你和客户的真实声音之间。
前台是行为发生的地方。 去那里。 让你的大厨干侍者的活。 读客户邮件，听到他们的挫折，倾听他们的建议并且向他们学习。
拿掉中间人
在 “运作监控” 软件的开发所有时间里，支持和市场营销工作由2个人承担。 即便我们被迫扩充团队，我们也从不把技术支持从研发中分离出去。通过亲自对每个请求进行响应，我们强迫自己设身处地为客户着想，并且从他们的角度看问题。
理解你的客户因何需要某物很重要，不仅因为客户需要它。这种情形对于我们如何设计有直接影响。拿掉中间人。 当你把耳朵贴近地面仔细倾听时，会更容易地满足用户的需求。
我和很多人讨论过这种情形，他们的第一反应往往是： “你怎么不雇一个初级工程师来作技术支持？” ，为用户设身处地着想。 如果想要你的牛排按照你喜欢的方式烹饪，你是要和一个巴士男孩说，还是应该和那个真正在烹饪牛排的大厨讲呢？
—David Greiner, Campaign Monitor 创始人
零培训
使用内嵌的帮助和常见疑难解答，产品就不需要手册或使用培训
你不需要一个手册去使用Yahoo 或者 Google ， Amazon。 因此， 为什么你不能也建立一个不需要手册的产品呢？ 力争建立一个这样无须培训的工具
你该怎样去做？ 好吧， 就像我们以前提到的，你开始就要保持简单。 你的应用越不复杂，你就越能免除帮助人们摆脱困境的麻烦。之后，一个伟大的事前支持途径是在潜在的、容易引起疑惑的地方，使用内嵌的帮助和常见疑难解答。
例如, 我们在屏幕上给出事先支持，允许 Basecamp 用户上传他们的 徽标。 有些人经历过这样一个问题，他们老是看到老的徽标，这是浏览器缓存引起的一个问题。因此在”提交你的徽标” 旁边的一个区域，我们增加了一个链接指向 这个常见疑难解答，来教客户 强行刷新 浏览器 以便看到新的徽标。在我们这样做之前， 我们每天都要接到5个关于此问题的邮件。现在一个也没有了。
快速回答
在疑难问题上的快速响应时间应该置于最高优先级
当你快速解答他们的问题时，客户很高兴。 他们已经习惯了录音电话式的支持，需要等几天（如果有的话），因此你可以通过提供体贴的即时响应区别于你的竞争者。 在工作时间， 我们在90 分钟内答复百分之九十的支持邮件，并且经常不到半个小时就完成了这项工作。人们喜欢这样。
即使你没有一个完美的答复，说点什么。 你可以用开放，诚实的方法 一个快速回复来赢得善意。 若有人抱怨有个不能马上得到解决的问题，象这样告诉他们, “我们已知道你所言那个问题，我们即将在不久之后仔细研究一下。” 这是驱散潜在负面困境的一个很好的方法。
客户欣赏直率，并且经常转怒为喜，如果你用一种切中要害的方式快速响应。
混合部队
一个3人小团队怎样才能研发出一个创新型产品并且怎样成功地和那些大人物们竞争呢？ 答案就是招募一只混合部队。
从你创业的第一天起，就要牢记客户是最重要的资产，他们对你的长远成功至关重要，因此对待社区用户要礼貌至上。和大人物竞争的方法是要从小处开始， 并且关注每个客户。
是你的客户第一个警告你，有bug（程序缺陷），第一个警告你需求还没有得到满足。 并且你的第一个客户会扛着你的大旗，替你广而告之。
这不是指你的产品要在上线时做到完美无缺。 恰恰相反，这是要你早早发布，常常发布。无论何时，当你的客户遇到bug时，一定要即时答复并且感谢他们的告知。
客户不指望你的产品完美无缺，也不指望你能实现他们所有想要的特性。然而， 客户一定想要你的倾听和你的关心，因此要显示你的关心。这是很多大公司表现尤为不足的地方，所以要早早建立一种社区归属感。
在Blinklist, 每个客户的邮件都得到答复， 通常在第1个小时内（除非凑巧我们在睡觉）。 我们有个在线论坛，我们确保每个帖子和评论都会有回复。
同样重要的是， 所有我们的开发者都收到客户反馈，并且他们积极参与在线论坛。这样，我们慢慢地，确信地建立起了一个活跃的，忠实的BlinkList 社区。
—Michael Reining, MindValley & Blinklist 联合创始人
强硬的爱
乐于向客户说 不
至于功能需求，客户并不总是正确。如果我们把客户需求的每个零零碎碎都加入产品中，那么没有人会要我们的产品。
如果我们屈从一个客户的一时的兴致， Basecamp 中就会有： 全面的时间跟踪， 全面的帐单，全面的会议安排，全面的日程安排，全面的附属任务系统，全面的即时消息聊天，全面的wiki功能，和全面的随便什么你能想到的。
然而， 我们通过客户调查得到的第一号 需求就是 要 保持 Basecamp 简单。
这里还有另一个例子： 尽管有一些怨言， 我们决定产品不支持IE5， 这样就有 7% 的市场被我们抹去了。但是我们认为我去关心剩下的 93% 更加重要。 为IE5 修补产品错误和测试在时间上不划算。 我们宁愿为其它93%的每个人作一个更好的产品。
作为一间软件研发公司，你必须扮演过滤器的角色。 并不是每个人建议的每件事都是正确答案。 我们认为客户所有的需求并不总是正确。 你不得不时常让一些人伤心失望。
关于这点， 作为一间研发公司热爱你的产品是最重要的。如果你的产品中掺和了一些你不认可的因素，你将不会爱你的产品。这是必须要否决你不认同的客户需求的另一个明证。
良好的论坛
使用论坛或聊天室让客户互相帮助
论坛以及基于Web的讨论组是让客户提问及互相帮助的绝佳方式。通过提供开放的交流平台，消除了中间人——即你自己的角色，为你节约了流程时间。
在我们的产品论坛中，客户发布应用技巧及窍门、功能需求、故事等诸多信息。 我们常常参与其中以为他们提供帮助。但论坛应主要是社区成员互相帮助及分享产品体验的地方。
你会惊奇地发现有那么多人是如此乐于助人。
公开你的错误
拿出坏消息别让它挡道
如果某事出错就告诉人们。即使他们开始并未曾发现。
例如， Basecamp曾经在半夜宕机了数小时。 99%的顾客都未曾察觉，但是我们仍然在我们的Basecamp博客大全上张贴了“意外停机”的公告。 我们认为顾客该知道此事。
这是一个在我们出错时，张贴的公告的一个样本： “我们为今晨停机谨此致歉-我们有一些数据库问题，导致了某些用户的重大减速和故障。我们已经修复问题，并正在采取步骤，保证这个故障不会再次发生… …感谢你的耐心，并再次，为停机道歉。”
要尽可能开诚布公和透明。 不要保秘也不要遮遮掩掩。知情的客户是你最好的客户 。 另外，你也会意识到大多的错误,在你的顾客的心中并不是那样地糟糕。 客户通常乐意给你一点喘息空间，只要他们知道你对他们是诚实的。
关于发布消息的旁注，好和坏： 当坏消息来时，立即把全部公开。另一方面 ，应该慢慢地一点一滴地透露好消息，如果您能延长好的信息起到的效果，那么一定要这样作。
快速，直接和诚实
也许听起来奇怪，但是最佳情景是，当公司报告自身的坏消息时。 这是一个积极主动的举措，防止您的公司被置于不利的被动防御地位。
—Greg Sherwin, CNET应用技术副总裁, 以及 Emily Avila, Calypso Communications负责人， (摘自 A Primer for Crisis PR
