时间: 2021-07-30 09:21:22 人气: 2 评论: 0
编辑导语：客户成功是近两年来在 SaaS圈 开始火起来的一个理念，指的是销售后留客的种种行为，围绕以客户为中心展开，让客户启动、成长、继而达成续费，成为长长久久的客户。产品经理如果不懂客户成功，很可能就没有“未来”。
文章开篇，我们先用2分钟思考一个问题：假设老板给你一个任务，要求你用2倍单价赢得一个软件项目。你的竞争对手，不管是从品牌知名度、行业成功案例还是产品本身，都丝毫不逊色于你所在的公司。请问，此时你该怎么办？
这个任务确实有一定挑战。但是，如果给你一个前提条件，这事的难度就降低很多，即：你的团队和客户已经合作过多次，且都很成功。
其实这事是发生在我身上的真实案例。当时的情况是，除了价格是对方的两倍，甚至我们团队的项目经验也远远比不上对方。但是，我们和客户已经合作了一年多，帮助客户解决了很多疑难问题，客户对我们的高度信任，是对方所不能企及的。而这也最终成为了决定胜败的关键。
这个故事发生在几年前，那时候还是传统软件的天下。虽然很多迹象已经表明：“以客户为中心”才是软件公司长期发展的根本，但是传统软件的商业模式，与客户的根本利益却是背道而驰的。
传统软件的经营核心，其实就是软件交付，本质上是“一锤子买卖”。这种商业模式让生意变得简单的同时，也使得产品、销售、交付和售后等环节，变得相当割裂。
比如：在销售环节，那个时代最让人津津乐道的故事就是：把梳子卖给和尚。虽然和尚是不需要梳头发的，但是销售人员通过自己强大的“创意”或者说“销售能力”，可以让和尚产生购买梳子的需求。
实际上，传统软件的销售逻辑，和“把梳子卖给和尚”的逻辑是一脉相承的。比如，一次典型的传统ERP招投标，销售人员**竭尽全力向CEO证明“通过ERP能够给企业带来管理变革”，因为对于一家集团公司的CEO来说，“得到一套能够运行的软件”并不重要，重要的是软件可以给企业带来的巨大改变。
而有意思的是，一旦签署合同并收到首付款，软件公司就**暗示客户：本次项目的切实目标应该是把ERP运行起来，管理变革则是一个长期的工作。
传统软件合同也严格遵循“一锤子买卖”的逻辑。比如，合同**规定：本次项目需要交付哪些功能，达到什么运行标准；在每个项目阶段要支付多少比例的款项；系统上线多少个月后，要付完全部款项。对于软件公司来说，合同最大的意义在于：最大化规避项目交付的风险——确保在项目交付后，能够收回成本并实现盈利。
因此，在交付环节，项目团队**严格以“合同条款”作为交付标准。这是一场时间和成本的竞赛：如何用最小的代价拿到全部合同款，这就是交付的全部意义。至于客户购买软件时的诉求，谁**在意呢？毕竟我们已经“一次性”把钱赚够了。
传统软件的售后也更多是防守动作：帮助客户处理月结问题，解决客户使用过程中的bug等等。这些服务虽然必要，但创造的价值有限，客户付费的意愿也不高。这就导致了软件公司的困境：随着新市场开拓完毕，收入呈现下滑的趋势。
传统软件时代，一个曾经很成功的时代，但也注定是一个快速陨落的时代。
SaaS的商业模式，本质上是让客户用“较低的价格”使用SaaS，即便达不到预期效果，放弃的成本也很低。这大大降低了客户决策的风险，实际上是把主动权交给了客户：如果软件达不到期望，客户可以通过拒绝续费来“惩罚”SaaS公司。
同时，由于**上客户可以“无限续费”，如果每年续约率足够高，再加上一定的新客户签单，SaaS公司的收入数据将是一条陡峭的增长曲线。这就是SaaS模式的魅力。
从这个角度来说，SaaS产品的成败取决于客户成功。SaaS公司每个环节的运转，都应该以客户成功为核心。
市场和销售团队的目标不再仅仅是“赢得订单”，而是找到正确的客户，并且说服他们“试用一年”我们的产品。对“客户成功”影响最大的环节，其实就是找到“正确的客户”，因为即便我们再努力，“错误的客户”也很难把产品用好，因此他们的续费率很低。
由于第一年的收入往往亏损（即首年收入-获客成本-交付成本-首年服务成本<0），这就意味着：把产品销售给“错误客户”的能力越强，SaaS公司亏损就越严重。在这种情况下，销售技巧仍然很重要，但以前那种“把梳子卖给和尚”的思路，肯定不再适用了。
在交付环节，上线只是起点。产品成功上线，只是客户使用的开始。不管是客户本身的管理问题，还是软件的问题，只要员工的活跃度很低，或者客户没有达到预期的目标，结果都是一样：客户流失。因此，合同条款的重要性大大降低了，交付团队唯一应该关注的就是：客户成功。
SaaS模式下，真正的挑战从交付环节转移到了服务环节。为了实现“客户成功”，服务团队不得不想尽一切办法，帮助客户更好的使用产品。比如主动梳理客户存在的管理问题，并积极出谋划策；监控员工账号的活跃度，当低于“警戒线”时，及时采取干预措施。这与传统软件时代的“被动式服务”，有着天壤之别。
在SaaS时代，客户成功是软件公司的生命线。可以略微武断的说，无法做到客户成功的SaaS公司，注定没有未来。
产品是客户成功的基石。
互联网的魅力，在于无限趋近0的边际成本。比如微信，虽然软件开发的总成本并不低，但平摊到12亿用户身上，就显得微乎其微。最关键的是，微信的使用也是Self-Service的——大部分用户，依靠微信产品本身的指引，就能够完成“如何使用微信”的学习——这是互联网最完美的模式。
大部分SaaS产品则很难做到这一点，原因之一在于企业的需求很复杂。比如价格管理，企业往往具有复杂的价格策略，这就导致SaaS产品也需要做得很复杂——以至于用户必须依靠人工支持，才能完成软件的配置与使用。
企业在不同层次的价格策略
另一个原因在于，中国SaaS其实还很年轻。
而注重用户体验、MVP的迭代模式，决定了产品研发需要更多的资源。在各种紧急或重要的需求压力下，侧重于减轻“用户学习成本”的指引功能，很容易被产品经理所忽略。实际上，我觉得这也有产品经理的责任——如果多去接触用户，亲自感受一下用户第一次使用产品的那种迷惑和焦虑，相信他们**重新排列需求优先级。
因此，从结果的角度来说，客户成功部的工作实际上是在为“产品的不足买单”——不论这个“不足”是无法避免的，还是可以避免的。我经常听到客户成功部对产品部的抱怨。虽然我也是产品经理出身，但是我必须得承认：大部分产品经理的客户成功意识，确实有待提高。
在这方面，我有过成功的经验，也犯过很多愚蠢的错误。
曾经客户成功部的同事来找我，说用户经常**问报表上的“利润”字段是什么意思，能不能在页面加上注释：这样客户就能够自己搞清楚报表字段的含义。我想当然的认为这样的情况并不多，毕竟“利润=收入-成本”不是最基本的逻辑吗？
但是，当我去客户现场调研，客户问我收入是“含税收入”还是“不含税收入”，成本是否包括“赠品成本”时，我感受到了客户使用产品时的困惑，以及客户成功部所面对的巨大压力和工作量。
我马上纠正了自己的愚蠢行为：在最近的一次迭代版本中，我给所有可能存在疑义的报表字段都加上了注释。产品经理确实要有优秀的反省能力和敬畏心，否则，可能就**犯和我同样的错误。
除了帮助弥补产品的“不足”，客户成功部在传递产品价值和收集用户反馈方面，也有着不可替代的作用。
SaaS本质是经营管理工具，这就意味着客户必须充分、正确使用，才能获得最大的价值。而好的SaaS产品往往功能丰富，如果没有客户成功部的帮助，用户很难充分发掘产品真正的价值。
比如，SaaS产品可能提供一个“经营跟踪表”的功能，通过这个功能可以按照客户/供应商维度，查看关于某个客户/供应商的所有重要单据，包括销售订单、出库单、收款单等等，在与客户/供应商对账时非常方便。但如果客户成功部不主动介绍，那些以前没有使用过类似功能的用户，就可能忽略掉这个功能。
同时，作为与用户接触最紧密的人，客户成功部往往能够第一时间感受到用户的抱怨，因此，他们往往是提出需求最多、最靠谱的部门。在我做产品经理的时候，大部分的有效需求都来自于客户成功部。甚至可以说，客户成功部是SaaS产品迭代最高效的来源。
因此，如果产品经理想要做出优秀的SaaS，就必须与客户成功部亲密无间的合作。具体有以下几点建议：
理解客户成功部的工作，最好的方法就是多拜访用户。只有现场感受用户的无助和抱怨，你才能理解产品的不足给用户带来了什么样的伤害，以及给客户成功部带来了多大的工作量。
当你理解了为什么他们**如此迫切希望某个功能上线，实际上就加深了对彼此的理解，为双方合作打下了良好基础。
虽然客户成功部同事未必是最懂产品的人，但无疑他们是最能代表用户感受的人。让他们参加产品评审，一定程度上可以起到“让用户参与产品设计”的效果。
为了推动用户问题的解决，客户成功部同事往往**主动找产品经理沟通。
但是，产品经理也应该定期主动找客户成功部同事沟通，问一些产品相关的问题，比如“新功能上线后，用户反馈如何？”或者“客户续约率有改善吗？可以在哪些方面再优化一下？”。
根据我的经验，经常和客户成功部沟通，产品经理**加深对用户的理解；对“如何给客户赋能”也**有更加全面的认识。
产品是产品经理的**：如果你负责过的产品成为行业的标杆，这将成为你一生的骄傲。而如何才能产品成功？我个人认为：产品成功=客户成功+商业成功。
商业成功意味着SaaS产品是盈利的，这很容易理解，毕竟公司存在的意义就是盈利。而客户成功则是商业成功的基础：SaaS的模式决定了，没有“客户成功”的SaaS产品，是注定亏损的。
在互联网时代，随着AI、物联网和区块链等技术的成熟，世界仍将快速而剧烈的变化，新的市场机**和竞争对手将不断涌现。但是，“给客户创造更大的价值”，将是持续的创新热点。
从这个角度来说，不懂客户成功的产品经理，就没有未来。把客户成功放在最核心的位置，把更多注意力放在客户身上，这才是产品经理应有的“客户成功观”。
王戴明，微信公众号：To B老人家，人人都是产品经理专栏作家，多年互联网产品与信息化管理经验。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
