专业性是进行高价值沟通的基础

专业性首先建立在对自身方案的熟悉上

• 在需要专业供应商的特定领域，我们需要假定客户没有我们专业：
  • 客户对我们的专业性有依赖，所以依赖我们提供专业性的分析和建议
  • 我们不应该嘲笑客户不专业，而是要帮助客户去了解更多信息、去清晰表达自己的需求
• 对接客户的技术团队人员需要在相关的产品和技术解决方案上具备完整的知识，不被质疑
  • 对接前做好功课，内部做好确认
  • 熟悉细节，能清晰总结和列出各项事情，了解关键点，可以做出明确的判断
  • 不清楚的不要给客户错误的信息，可以说还要内部再确认之类的

通过自身的专业性，跟品牌建立对等沟通

• 客户对我们的专业性有很高的期待：客户希望我们协助挖掘问题，同时提供完整的解决方案，甚至去引导他们如何去做
  • 在客户依赖我们的领域，我们不应该比客户不专业。若真实情况是客户比我们更专业，则我们需要庆幸自己碰到了好的客户，同时需要更加努力，为客户贡献他们所意想不到的价值
• 跟客户对话的人具备站在客户角度思考和引导整个解决方案的能力，而不是完全按照客户的想法做
  • 比如去思考方案而不仅仅是响应方案，挖掘表面需求下隐藏的更深层次的需求。
  • 考虑客户受到的各种约束，以及决策的局限性，给出更完善的解决方案，帮客户实现价值最大化，比如不了解国内市场的客户和技术生态，或者不懂技术的业务人员，或者部门壁垒高的团队

某些非专业沟通场景，则至少服务上要是专业的

• 客户一线对接人员包括项目、IT服务、运营、维护等，可能就某个专业业务领域沟通理解不深，但是至少要建立好有序的流程，以及及时去找到更专业的人去解决问题

价值导向的思考 - 建立一套挖掘客户的真实需求、核心需求的思考流程

• 表面上：对接的客户代表可能会在一个很高层次说要什么，不要什么，甚至什么都要，可能是他的老板有个想法，也可能是友商有这么做，也可能是自己想出的需求
• 目的判断：需要在跟客户沟通过程中，了解客户要解决什么业务问题？或者希望实现什么业务价值？甚至有可能需要进一步接触客户的上级、高级管理人员、其他业务团队等，去了解这个需求下实际上要解决的业务问题，要实现的业务价值
• 方案分析：基于了解到的需求以及业务目的，我们需要判断能帮客户解决什么，哪些问题解决不了，客户哪些重要问题没有想到等，进一步澄清和细化，可能会涉及到客户不同团队的调研、多轮的需求澄清等
• 有价值的建议：基于最终的需求和业务目的，以及自身的团队能力，判断怎么做最符合双方的利益，达到客户期望实现的价值&实际可达成的价值的平衡，并获得共识，确认好拿到最终的工作范围

用业务语言沟通 - 跟客户处于同一个沟通频道

• 用一种客户可以理解的语言进行沟通，通常是业务语言，而不是技术语言，即每个讨论都需要聚焦到对业务的影响，技术沟通只是作为一些论证辅助
• 建立“总-分-总”的沟通结构，先将结论、目的等总结性的内容描述出来，再描述细节进行支撑，这样业务端不理解具体细节时，也可以知道整体情况
• 下面是一个典型的用业务语言沟通的模板：
  这个方案主要解决XX业务问题，对业务影响XXX，技术上采用XX方案，满足业务需求
  ** 我们碰到了什么问题，会导致什么业务影响，我们已经找到了解决办法。这个问题原因是：XXX。我们的解决办法是：XXX**

了解客户内部团队、决策和流程

• 了解客户内部不同的团队，以及团队之间的合作流程：客户也可能存在团队配合问题、部门壁垒问题，不同团队也有强弱、以及团队之间可能有矛盾等，了解客户团队情况可以制定不同的沟通策略
• 知道谁是关键决策人，谁能对需求和预算谁拍板：对接人可能不一定能够做出决策，甚至某些对接人做出的决策是不准确或者不算数的，所以要确保关键决策人能做出判断，必要的时候谁可以升级等

获得非正式信息

• 通过非正式信息通常可以获取到正式场合不会提到的客户对我们和对其他人的背后的评价，客户对某个敏感问题的看法、客户将来的业务规划和我们结合的机会点，客户内部的团队变化等情况，由此可以提前应对
• 通常日常的信任感是获得非正式信息的前提，所以跟客户建立可信赖关系以及日常性的客户沟通可以帮我们获得更多准确的非正式信息，甚至是客户善意的“提醒”
• 没有信任感时，通过日常的沟通也可能获得非正式信息，但是不一定能获得非常有效的非正式信息，即“拉关系”可能可以比较好运的获得一些信息，但是若不能真正解决客户的问题，则不一定能获得长久有效的信息

引导客户的重要性

• 同一样事情不同的表达方式会带来截然不同的结果，不好的表达可能带来非常棘手的善后工作，因此需要引导事情往良性的方向发展。
  ex. 我们的产品没有准备好 VS 建议分阶段降低业务风险：客户提了某个需求，但是由于资源问题、产品准备问题等，我们无法马上响应，但是这个客户又是关键客户，在公司有影响力。此时若以没有资源来回复客户，可能带来问题的升级，需要各种解释，非常被动，最后的结果可能是由于这个客户的影响力，客户通过升级、我们也消耗了很多沟通资源，结果要把这个客户的事情放到高优先级，舍弃其他已经承诺的客户的需求。换种方式可能更好，比如跟客户沟通分阶段实施、提出一些要客户确认的问题等，通过其他方式将问题拖一拖，能拖就尽量拖就一点等。
  ex. 事故的答复：有时候实事求是的、无所保留的将事故的内部原因全部暴露给客户不见得是一个好的选择。事故的披露以不带来更多的麻烦作为原则，即给客户披露客户可以理解、且足以解释整个事故的原因，说明影响范围、当前处理措施、善后措施等，避免带来更大恐慌。
• 有些多方参与的讨论，且主导方缺乏足够的控场能力时，七嘴八舌，没有办法聚焦到具体的事情、而我们也是整个方案重要的参与方时，也需要我们能够进行整体上的引导，将事情往有序的方向去发展。这个时候可能就需要借助主导方的决策权去引导整个方向的发展。
• 要引导客户，就需要比客户想得更深、更全面，否则引导的权威性就会降低，也容易被客户质疑，进一步导致引导失效。
• 引导不是忽悠，要按照双方都尽量获利的原则去引导客户，即站在整体业务角度去引导，分析方案对客户带来的价值，对业务的影响等，客户也更容易支持这个方案。

主动权的把握

• 面对猪队友，我们要主动到什么程度？
  • 客户价值 & 资源的问题：并不是什么时候我们都需要主动，因为主动则意味着要投入非常优秀的资源去跟进这个事情，所以需要判断客户或项目的价值是否值得我们去主动跟进或推进事情的发展；否则只能依据合同工作范围进行力所能及的资源配置，并预估项目失败的风险以及做好自保。
  • 通常客户专业度或第三方主导供应商不足以支撑整个项目，整个项目对我们也非常重要，则需要我们把握主动权，形成整体的Action list，帮助客户推动整个项目的发展。
• 怎么样才能主动
  • 对整个解决方案心中有数，熟悉细节，知道关键点在哪里
  • 想到客户前面，提前预估可能存在的风险、障碍，以及解决方案建议
  • 获得核心关键人的认可。通常需要在关键人面前表现出对问题的全面理解和分析才能获得关键人的认可。所以跟关键人沟通前需要准备充分，比如问题讨论会一定要有先内部有完整的问题分析和解决思路，才去对外沟通

说话的分寸

• 商业合作上双方都有各自的利益，要注意正式场合和非正式场合说话的分寸：
  • 正式场合：客气、留有余地。比如在正式会议中由于有多方参与，因此语气上尽量保持平静和客观，尽量避免情绪化表达，以免问题被放大，带来负面影响。
  • 拒绝客户：有理有据，不留下话柄。客户的需求通常不是很好拒绝，尤其是当公司文化里面有“客户第一”基因，决绝客户更加需要勇气。所以在拒绝客户时，通常需要分析拒绝的利弊，并且在拒绝时有充足的理由，最好是在拒绝时还能给出建议。
  • 撕逼会议：准备充分，避免被反撕。复杂的项目不可避免会涉及到一些争论，比如问题回顾、事故复盘等。我们可能会主动提出一些问题，也可能被问到一些问题。所以会议前通常要先进行内部总结，知道可能哪些问题会被问到，原因是什么等，被问到的时候能够冷静应对。通常回顾会议时，客户也可能征求我们的意见，以及我们也期望通过这类会议推动一些流程的优化，此时则需要我们先总结好这些问题点、明细数据等，以及期望的优化，避免再提出问题时，被客户反杀。
  • 原则问题：直接了当，不留空间：当涉及到一些公司政策等原则性问题时，需要直截了当的拒绝客户，并说明这样做的公司依据。客户再有问题，应该去进一步升级，而不是给客户凌磨两可的答案，但自己又处理不了。
  • 寻求支持：列明前因后果，建议方式，尽量不给客户惹麻烦。在项目过程中，可能有时候需要客户的支持，此时则需要明确列明要支持的事项，如何支持等，方便客户直接做出决策。
• 在跟客户沟通中，也有些问题不建议说：
  • 公司内部矛盾 & 内部资源问题（内部解决）
  • 客户内部需要解决的事情（点到为止）
  • 不用暴露给客户的问题（不引发更多的麻烦作为判断）
  • 有损公司利益的事情（“不清楚”）

避免低价值的沟通

• 避免敏感问题的发酵和扩大
  • 敏感问题包括信息安全问题、法务问题、重大影响到客户和业务的问题等。
  • 一个敏感问题的发生会带来一系列附加后果，以及成本，比如若发生数据安全问题，则可能会带来客户对供应商在保障数据安全方面的质疑，这个质疑是非常致命的。为了确保后续的继续合作，也可能会带来后续持续的信息安全审计、整改、报告等
  • 处理问题的态度有时比问题本身更重要，因为客户会根据这个态度考虑这个客户是否适合长期合作。通过诚恳的态度+邀请更高层面的人背书，让客户意识到供应商是认真看待这个问题。
  • 为了避免敏感问题的持续发酵，需要有明确的问题分析、解决方案、减少业务影响的短期和长期措施等，尽量将问题控制在问题本身，而不是蔓延到对整个体系的质疑上。
• 适当透明，降低沟通成本
  • “一个谎言可能需要更大的谎言去圆”：尽量避免谎言，有些自己不知道怎么说的，宁愿不说，或者达成内部口径换种方式去说。否则谎言会持续下去，耗费更多的资源去解释，也可能维护不下去导致信誉破产。
  • 一个足够令人担心、且无解的问题也会带来后续的处理成本：所以也不是所有的内容都毫无保留的暴露给客户
  • “恰好”的透明；对客户保持适度的透明能增加客户理解，更快达成共识，同时也不给团队带来过多的解释相关的麻烦
  • 用一种建设性的方式向客户披露问题：我们有XXX问题，对业务有XXX影响，我们正在XXX，预计在XXX时间解决这个问题，后续还有XXX措施，避免此类问题发生
• 避免假设，让大家都知道问题是什么
  • 不要假设客户知道我们的要求，知道问题所在。因为先入为主的假设，可能导致鸡同鸭讲。双方都认为是对方的问题，但是双方对这个问题的理解完全不一致。ex 针对天猫是否存在测试环境的理解。
  • 尽量去理解问题的原因，并加强跟客户的沟通，说明我们是怎么理解这些问题的，客户是如何考虑的等等，双方就问题达成共识，才可能进一步去解决问题
• 找到问题的根源，避免低效处理问题
  • 基于表面问题进行沟通，会把简单问题复杂化，甚至进入没有尽头的沟通，可能只是一次又一次描述现象，然后去穷举所有的涉及到的系统去定位，带来非常大的问题定位成本。所以要先在理论上分析这些问题的最可能来源，更有针对性的进行处理。
  • 若没有办法自己处理的话，找到相关人给出专业建议，而不是一步一步重复错误。IT服务相关岗位容易碰到这类问题，IT服务人员进行初步筛查和分析，无法自行解决时，需要产品、开发团队进行支撑。
• 面对客户的不专业，不要被拉入到坑里
  • 专业应对，有理有据：前因后果调查充分，并提出建设性方案，比如这个事情的背景是XXX，发生原因是XXX，为了推进事情的进展，我们建议XXX
  • 不怕升级：我们碰到了XXX问题，期望得到XXX协助，问题具体如下XXX，我们建议能够XXX，能否帮忙推进？
  • 不挖坑，也尽量不被坑到：客户或客户的主导供应商缺乏能力，可能把项目往比较危险的方向发展时，尽自己的能力和精力给出客户一些支持，同时也保护好自己和团队，留好沟通记录，不要被坑到。
• 灵活和平衡，走出僵局
  • 通常商务沟通并非只有一个答案，而是双方根据当前的情况的一个妥协，选择一个平衡的答案。若沟通进入僵局，无非就是你将我的我讲我的，陷入长期持久战，甚至影响到业务和发展。
  • 进入僵局时，需要考虑到双方的立场、利益、条件限制等，尽量提出一个让大家都摆脱僵局的方案。ex 商务价格谈判

链接：
导言
1. 有价值的产品或解决方案
2. 有价值的沟通
3. 有利可图的销售
4. 价值导向的交付
5. 持续创造价值
6. 发展价值导向的能力