微软对客户打进来的电话，从总体上端正了认识。客户电话具有两重性。一方面，客户的求援、咨询和投诉电话越多，说明产品的使用不太容易，或者说明产品的缺陷很多，或者说明公司向客户提供的信息和培训太少等，以致客户不得不花很多时间来打电话，既增加了客户的购买成本，也增加了公司的生产成本（不得不派出大量员工来回答和解决客户的提问）。所以，客户打进的电话增多并不是一件好事，公司不应该因为客户电话很多而沾沾自喜，而应该想办法减少客户打进来的电话。可是从另一方面来看，一个公司接到了客户的很多电话，确实是一个了解客户需求及其困难的绝好机会。因此，公司不应该因为客户电话很多而背上包袱，而应该视客户电话为信息资源的宝藏，并且运用各种科学技术工具，从中加以发掘，以提高公司智商，改善公司的生产和经营。从这两方面来看，微软都有很好的表现，使它在建立学习型组织方面向前迈进了一大步。
就努力减少客户电话、降低成本的角度来看，微软采取了两个成功的措施：
第一个成功的措施，是深入了解客户打电话求援的情况，有针对性地采取相应的办法。微软人发现，向产品支持服务部门（PSS）打电话的，绝对数量虽然很大，但相对数量并不是很大，只是客户中的少数。实际上，70％的软件用户，从来不向PSS打电话；电话总数的70％，是仅占总数15％的用户打进来的。大多数打过电话的，也只是就某种产品打过一两次，并且一般仅限于购入之后的前90天内，因为在此期间电话可免费打入。在前90天打进的电话中，所涉及的问题40％～60％是有关设备配置或软件安装的。其他常见的问题是打印问题，新的或有变化的功能的使用问题，操作环境问题，与其他产品共同使用时的可操作性问题，特别重要的是，很多客户在遇到问题时，会首先求助于邻居，然后会利用产品的帮助文件和说明书，或者去找卖给他们计算机或软件的零售商。打热线电话，是大多数用户的最后求援之道。针对这种情况，微软人尽最大努力，生产出更加容易使用的软件，写出通顺流畅的帮助文件和产品说明书，并且向计算机零售商、软件咨询商、乐于帮助周围人的熟练用户，提供更多的信息和培训，以此来减少客户电话的数量。
第二个成功的措施，是改革各部门交纳“产品支持组织费”的计算标准。起初，微软要求每个部门等额交纳“产品支持组织费”。这就是说，一个部门推出的产品即使非常好，顾客使用起来非常顺手，根本就没有发生客户打电话求援的事，但也必须交纳“产品支持组织费”。相反，另一个部门推出的产品非常差，用起来麻烦不断，用户投诉电话接连不断，所交纳的“产品支持组织费”也不比其他部门多。显然，这不利于各部门努力生产出好的软件。微软的高层管理者注意到这个问题，并加以改革。“自1991年7月以来，微软已改为向单个产品单位收取支持费用。这意味着如果一个组的产品用起来很费劲，设计的功能有许多都是‘电话发生源’，那么这个产品单位就必须承担所有这些支持费用。”
就运用科学技术，从电话信息中发掘宝藏来看，微软开发出了一套工具。这套工具能够跟踪客户提出的问题，自动统计出各种数据，包括：电话数目、通话长度、等待时间、每个产品的电话数、每类客户的电话数、每类问题的电话数等。在这些数据的基础上，就可以生成各种报告，制定出按重要性程度排序的问题表。微软产品支持服务部门的员工，对使用这套工具的好处，作了如下描述：每一次和客户的接触，每接听一个客户打来的电话，都能够获取一定量的信息，通过自动统计，就知道多少电话是针对安装的，多少是针对打印的，多少是关于普通用法的，多少是有关操作环境的，多少又是涉及共同可操作性的。
3、分析客户信息，集成客户建议
随着微软的发展，每天从不同渠道收到的、来自客户的信息，数量非常庞大。如何组织和分析这些信息，是对微软的挑战。
1991年，微软产品支持服务部门的6名高级技术人员，成立了一个小组，被称为产品改进组；其使命是帮助微软更好地满足客户需要，通过客户的信息反馈和建议而改进产品。这个产品改进组建立了两种分析客户信息的机制：一种是编写《电话分析电月报》，分析上月从客户打到微软的电话里收集到的各种主要信息；这些信息按产品里界定的功能组织起来，并按产品细分。另一种是建立一个独立的客户建议数据库，这些建议既来自客户的电话，也来自客户的信件，是这两个来源的集成。建议数据库中的信息，也有选择地写入电话分析月报。电话分析月报通常包括对每种产品的主要15条建议。
4、把客户投诉转化为更好的产品和服务，让客户如愿以偿，使公司提高智商
分析客户信息，集成客户建议，无论怎样全面、深入和细致，但如果仅仅停留在一个公司的产品支持和服务部门，那就会失去它应该具有的重大意义。必须把这些经过分析和集成而得到的信息，及时传递到产品的设计、开发和制造部门，把它们转化成为更好的产品和服务，使其成为竞争优势，让客户如愿以偿，提高公司智商，才算暂时完成了任务。
然而，这是一个什么样的任务呢？比尔·盖茨说：“聆听客户意味着听取他们对当前产品不足之处的投诉。但把坏消息从客户那里，递到产品设计组却是很困难的，这点让人吃惊。大多数公司在客户和技术完善人员之间拥有一个不太有效的人为或信件联系链。当客户的要求被最后交给产品设计组时，对他们来说，理解要求的重要意义和优先安排它是不太容易的。所有这些延误加起来意味着产品改进不能如他们想象的那么快捷。”简言之，这是一个相当困难的任务。
任务虽然困难，但在微软还是完成得不错。产品改进组编发的《电话分析月报》，其中揭露的问题和建议在微软其他部门得到了迅速广泛的传播。这是因为，比尔·盖茨和微软的其他高级主管们，思想上很重视，他们都是月报的热心读者。因此，产品组对于报告中反映的问题一般会在3、4小时内就做出反应，并让PSS知道他们打算怎么处理。通常，测试组会有一名人员负责把PSS鉴定问题录入产品组的数据库，并确保开发员对仍存在的问题加以解决。程序经理既要关心本产品的新版中哪些功能有待修改，又要注意：客户就新功能或功能变化所做的建议。
微软的产品改进组，不仅通过电子邮件以《电话分析电月报》的形式提供信息，还发起组织研讨会，把各个产品组的营销、程序管理、开发、测试和用户培训人员聚合在一起，共同磋商对策。这不仅密切了公司内部方方面面的关系，而且导致了开发员时间的再分配。过去，开发员80％或90％的时间，都是用在产品的新功能上，很少动脑筋考虑如何使产品现有功能更好用，如何进一步改进；现在不是这样了，开发员把1/3的时间用于改进现有的功能，1/3的时间用于增加新功能，1／3的时间用于考虑兼容性（使自己的产品和世界上的其他产品能够协调一致）。这就培育了微软人在保证软件功能运行可靠、实用好用的前提下来增加功能的质量意识，而这恰恰是用户最需要的东西。
总之，把客户投诉的坏消息，迅速传递到产品的开发者、设计者和制造者那里，并进一步转化为更好的产品和服务，在微软进行得颇为成功。所以，当比尔·盖茨写作《未来时速》这本专著的时候，对于如何把客户的投诉和要求，结合进产品和服务的开发中去，能够提出比较中肯的建议。所谓建议，实际上是微软实践经验的三点总结：第一点是“关注您的最不满意的客户”。因为“您的最不满意的客户，是您最丰富的学习源泉”。第二点是“用技术来搜集丰富的客户信息，这些信息是有关他们使用您的产品时不愉快的经历的”。第三点是“用科技把消息快速送交给合适的人”。比尔·盖茨写道：“如果您做到这三点，您将把那些烦恼的不快经历变成完善您产品和服务的令人兴奋的过程。客户的不满总让您心存顾虑，但他们同时给了您最大的机会。采取一种虚心学习而不是消极防御的态度，可以使客户的投诉化为促进您提高产品质量的动力。采用适当的技术手段将有助于您尽快理解并把投诉转化为更好的产品和服务。”
当然，无论哪个软件公司，包括微软在内，从客户的抱怨中学习和完善产品的任务，只能相对地暂时完成，不可能绝对地永久完成。对此，比尔·盖茨也有清醒的认识。他说：“客户总想要得到更好的软件。如果您提高了软件的可靠性，客户会表示极大的认同。但标度调整性怎么样呢？如果您改进了标度调整性，他们又会想软件集成化。我们的客户总是随心所欲地提出各项要求，而且理应如此。”
一个软件产品，使用起来是不是可靠，是不是容易，应该通过广大用户的实际使用来检验。这是没有疑义的。所以，一个软件公司，必须十分重视广大客户使用软件后的信息反馈。全面搜集、精心整理、深入分析来自最终用户的信息，虚心向最终用户学习，软件公司就能生产出越来越可靠、越来越容易使用的软件。
但是，软件产品的用户，是在该软件已经上市、已经出售的条件下出现的。当客户信息反馈到公司的时候，该软件的生产开发过程已经结束。如果来自客户的信息表明，该软件运行不可靠，使用有难度，已经成为产品缺陷，只能等到下一个版本时加以改进。一般说来，软件公司要通过很多次版本的修改和提高，才能生产出既可靠又易用的软件。
那么，能不能在软件的生产开发过程中，及时收到客户反馈的类似关键性信息，以便在新产品正式上市之前，就消灭其产品缺陷，达到软件运行可靠、使用方便的目标呢？微软的可用性实验室，就是为了达成这个目标而创建起来的。这可以说是微软创建学习性组织过程中的一项创新。
建立可用性实验室的创意，始于1989年和1990年间微软开发Excel3、0的时候。当时由很少的几个人，建立了一个试图对每种产品都帮上忙的服务性组织。他们帮忙的方式，是当开发员完成了某些功能，就随意找上十来个人，让他们来试试使用这些功能，也就是进行可用性测试，所以被称为可用性实验小组。
起初，对于可用性实验小组反馈过来的信息，开发员是不屑一顾的。比如说，该组成员向开发员反映，你完成的那个功能，不那么好用。10个人中有6个人不会做。开发员就会反驳说：你们从哪里找来了这么6个傻瓜？开发员们都相信自己是有知识的聪明人，都对自己完成的功能易于使用充满信心，都认为“我的点子很棒，只是你找了10个笨蛋才导致可用性实验室里的运行失灵”。
但有一次，一个正在进行的可用性测试，被几个开发员偶然看见，使事情发生了转机。他们说，要不是亲眼看见，是不会相信在实验室里发生的那种“用户”与“功能”奋力斗争的事实，也不会发现自己知识的局限性，更不会想到人们对软件作出反应的方法会如此复杂多样。从那以后，开发员对来自可用性实验室的信息反馈越来越重视。以致把可用性实验室中的测试，固定为软件开发过程中一个必不可少的步骤。开发员们为了改进功能的使用可用性，往往把大部分功能不止一次地送进可用性实验室检验，开发员出入可用性实验室成了家常便饭。
在微软生产的大量软件中，应用性软件的开发，如Word和Excel的开发，使用可用性实验室最为频繁。系统软件和语言软件的开发，使用得相对少些。一般只对界面特性或功能做可用性测试。产品支持服务部门，也利用可用性实验室来测试用于支持新产品和特性的不同方法的有效性。
“微软请到可用性实验室测试产品的可以是任何人，比如用户组人员或‘从街上拉过来的’人员。如果开发员想检查一下与竞争产品的兼容性情况，如WordPerfect，他们就去找个该产品用户。”
微软人通过实践发现，测试一个特性并不需要一大批用户。事实证明，如果一个软件真是有问题的话，让一个人来做实验，该软件得的是零分；就是让10个人来做，也还是零分。因为人们倾向于犯同样的错误。
微软通过对可用性实验室的长期观察，得出了软件开发方面的两大“教训”：一是仅仅依靠开发员单方面的常识，并不总能生产出易于理解和使用的产品；二是软件用户手册基本上不太必要，可有可无。“当用户不能理解一种功能时，只有30％的人会首先阅读用户手册。大多数用户有问题时会首先想到向邻居请教；要是不起作用，他们一般就向产品支持部门打电话。多数客户只是最后才向用户手册求援。”
微软创建的可用性实验室，在使产品易于使用和易于支持方面收效显著，使客户求援电话减少了一半。“你能做得这么好，以致他们用不着打电话，你成功了。而他们首先想到的也不是打电话，他们也赢了。”可用性实验室也有助于防止程序经理和开发员添加太多不必要的和复杂的功能。
五、各组之间相互学习，实现资源共享
微软生产软件，原本是分成若干彼此独立的产品组，各自基本上互不相干地进行的。如语言组生产BASIC，系统组生产MS-DOS，电子表格组生产Excel，文字处理组生产Word，等等。这种生产模式，是公司起步阶段自然而然形成的，有它出现的原因和存在的理由。其优点是各个产品组的自主权很大，可以随心所欲，想要用什么代码就用什么代码，高兴采用什么界面就设计什么样的界面，制作进度、质量要求都是本组说了算，从而比较容易调动组员（特别是那些比较聪明、有自己独立见解的组员）的积极性。但是，这种非系统化的、每个“原子”都可以独立行动的生产方法，缺陷也是十分明显的：重复劳动，每个组都“重新去发明轮子”，人力成本居高不下；就一个产品来看也许问题不大，但从全公司的产品组合来看问题就严重，微软的产品中竟然有14种各不相同的文本处理代码，数学计算、绘图制表、帮助功能和完成其他任务所使用的代码版本也各不相同，用户界面五花八门，不统一、软件不兼容的现象随处可见，客户抱怨此起彼伏。
公司离起步阶段越远，非系统化的“原子”独立行动的优越性就越来越少，而危害性却越来越大，成了一个照此下去公司就难以竞争取胜的大问题。
