其实这是个相当浅显的道理：保持我们成功的最好办法是帮助我们的客户成长和获利。一家电信设备厂商发现今年合同额少了很多，原因是运营商的采购量大大减少；为什么运营商的采购量减少了呢？经过调查发现，宽带网络的服务建设遇到了困难，运营商没有钱赚。于是这家电信厂商邀请多家运营商举行论坛，主题就是：“设备商怎么帮助运营商赚钱？”这是一个很好的以客户为中心的案例。电信厂商看到合同额减少，并没有以自己为中心，一味抓住运营商，用尽一切手段增加合同额度；而是站在运营商的角度分析原因，主动把自己和运营商放在一条船上，共同担负起开拓市场的任务。这样的情况下，即使市场还没有开辟，运营商对这家厂商的满意度也会大大增加，这也正是设备商的目标之一啊！
上面是外部客户的例子，所谓外部与内部之分是以企业组织为界限的。下面来谈谈谁是内部客户。
在稍大一些的企业，个人都不能够单打独斗做成事情的，必须与人合作，因此就有了流程。那么我们每个人就会有上游和下游，上游流程为我们提供工作产品，可以说是我们的供应商；工作产品经过我们的加工，传递到下游，那么下游就是我们的客户。举例来说，假设我是研发团队的详细设计人员，我的工作是根据系统设计和模块划分，做出详细设计，在规定的时间内交付开发人员进行编码实现。那么如何衡量我的详细设计文档质量呢？就我个人而言，我认为那些复杂算法很能体现我的设计水平，我要把他们写得详细些；而那些一般的接口方法，我就只定义其名称、参数、返回值域及其含义。只要以上内容我写得详细清楚，而且遵守公司和项目的相关规范就可以了；不必面面俱到，那写着多累啊。这样行吗？我有没有考虑过我的编码人员对系统是否熟悉？那些没有设计方法体的接口，对他而言其实现方式是否已经了然于胸？如果我的编码人员是第一次为我们的项目工作，应该会有很多约定俗成的不成文规则，如注释的内容和格式，我有没有给出提示？如果我的编码人员是个高手，那么我写得那么详细的复杂和精巧算法，对他是否必要？如果我对文档质量的认同标准与编码人员差距甚远，可想而知其后果必然是，他经常拿着文档要求我解释一下，再解释一下；如果他忽略了，到后期再发现问题，那项目付出的成本可就更大了；而且大概一转身，他就会讲：“这个家伙，以为自己了不起，其实水平不怎么样，谁搞得懂他写的是什么！”
