客户信任度的建立
| 在项目实施过程中的绝大多数时候，我都很“憎恨”我合同乙方的身份，因为我要时时刻刻满足客户的需求。 如何让客户满意？ 在项目立项的初期，这简直就是我考虑项目实施风险的全部。客户方企业文化、客户团队组成、客户项目经理的技术能力、客户对本项目的关注、客户对项目进度的要求、客户方对故障的容忍度、客户方与公司的关系融洽度、甚至客户的爱好、性格等等。这是无法回避的问题，我们必须面对它。 什么是客户？客户是我们的工作动力和目标；是给我们为其服务的机会而给予我们的恩惠；是我们为其服务，使他们和我们都得益，实现客户利益和企业效益的“双赢”。 短缺时代的过去，注定了今天的客户就是上帝，他们更多的是需求，是挑剔，他们很少去宽恕，去理解。随着营销观念的转变，从“产品为中心”走向“以客户为中心”，客户关怀和客户满意日益成为企业经营理念的重要组成部分。 需要说明的是，这篇文章是一个实施项目经理在客户现场工作的体会和经验，它不应该是教条，更多的是值得商榷的观点和经验的借鉴。 客户信任度主要包括那些呢？个人认为主要包括技术信任度、责任心信任度、执行力信任度、突发状况处理能力信任度。 限于篇幅，让我们首先讨论一下，技术信任度的建立问题。 技术信任度的建立 我很想把责任心信任度放在第一条，但作为一个软件企业，客户最先关注的还是项目经理技术能力的考察，所以，如何建立或者说提高项目经理在客户心中的技术信任度应该是首当其冲的。 实施项目经理在现场作为公司技术代表的身份是客户潜意识中确定的。对于项目经理出具的功能方案、解决手段、故障处理能力、解决问题的时间考虑、架构方案等等都会因为初次合作而被客户方在技术层面上打上问号。“对于这件事情，我借助的是我多年的业内工作经验和整个公司的技术团队，请相信我！”我通常这么说。但客户在初期根本不会相信你的工作经验和公司技术团队，因为它们没有得到检验。 一直在说团队精神和团队协作，所以千万不要忘记公司有售前团队和研发中心，MGS内部有专业服务部，我们还有很多并行的相同技术线的项目。在考虑问题的时候，我宁可多花一些时间聆听他们的意见和建议。大多数的时候，这些建议和意见是非常有益的。至少他们会对我的决定有很多补充和建议。我个人是讨厌唯技术论和个人英雄主义的，因为个人的能力还是存在盲区。 好吧，在客户等待的时候，给他一份表格，在项目的初期甚至以后。不要怕麻烦，事实证明这些是有用的。不同技术、不同架构、不同开发工具……优缺点请列示出来，然后结合客户的要求，分析之后给一个结论。别忘记将公司技术团队的建议和分析附加在你的表格的后面。若我是客户，我会认为在这个需求的处理上，你做了很全面的分析和规划，你是值得信赖的，至少你采用的技术是有竞争力的，我会很认真的去考虑你给的这份方案。若你有不同技术的成功案例和失败案例的分析，简直就是美妙了。邮件发送给你的客户项目经理，然后找个时间去和他进行沟通，给他将部分不明白的地方进行细致的解释。专业、全面、责任，将这些明白的体现给你的客户。 对于出具的技术方面的文档和思路，通常来说，我一定会找一个时间来听一下客户评审的意见和建议。这不仅仅是礼貌以及对客户的尊重。只有最终用户最清楚他们原始的想法和需求，在向项目经理转述的过程中，这些需求和想法是呈现一个衰减的态势的，仔细认真的听取客户反馈回来的评审意见和建议，是还原这些需求的最佳途径。采用递归的方法决定的技术手段，才能如实的反映客户的原始需求，最优的方案处理这些需求。 曾经和一些项目经理讨论过这个问题，“客户已经和我们签订了合同，这个项目、案例我们采用什么技术，为什么采用这种技术，其实客户已经不关注了，他们更多的关注的是结果。”没错，但我们现在讨论的是实施项目经理在客户现场技术信任度的建立问题，若一个长期的项目，让客户对你的技术放心，这是没有坏处的。 可是，还有一些时候，比如在日常的会议、讨论的过程中，客户针对某一技术问题咨询你的意见、建议、方案。除非你有十足的把握，否则，请审慎的用词。“以我个人的经验来说，我认为……，但是否存在其他的问题，例如……我需要下来之后进行一些技术准备和咨询工作，您看，您什么时候需要这样的一份方案？”大多数的时候，客户不会逼着你，在没有准备的前提下，当场进行明确的答复和解释。剩下来，我们需要做的工作，还是和上面一样，咨询相关的人员，分析各种方案的优缺点…… 相对于时间和正确性来说，站在技术的角度上，我认为正确性更重要一些，努力去说服你的客户，让他们给你充裕的时间，给他们一个正确的技术文档。 将你处理技术问题的手段和方法常态化，并持之以恒，算是一个经验共勉吧！ |
| 撰稿人：吴骏 |
更多相关信息，请点击[url]http://www.mochabsm.com[/url
本文转自赖永锋51CTO博客，原文链接：http://blog.51cto.com/mochasoft/90487，如需转载请自行联系原作者]
