本文作者回顾自己在SaaS软件厂商工作的历程，认出自己存在三个失误：渠道合作偏斜、定制项目走样、客户成功没有落实，特意分享给大家，避免各位踩坑！

2016年至2019年我在某SaaS软件厂商工作，以产品经理身份入职，离开时是产品线的业务负责人。

完整经历了从软件上线无人问津，到销售略有起色，再到完成千万级别的业务流水的整个过程。最近在与一些企业主交流软件厂商的销售工作，随即将交流过程整理成文章发出。

因为目前还在涉密阶段，简单分享一下过程，进结果来说还是能看的。

• 2016年4季度上线，万级别流水；
• 2017年百万级别确认收入；
• 2018年千万级别确认收入。

今天这篇文章来聊聊我过往的遗憾和失误。

一、渠道合作偏斜

2017年底，我们和国内某知名企业硬件服务商达成了合作意向，对方出渠道，我们出产品进行合作销售。我们收获付费用户，对方获得分成收益。

对方是一家知名的企业，背后拥有非常优渥的企业资源，同样有合作代销新业务的需求。从资源基底到商业动机到项目执行都是过硬的，但为什么结果依然不乐观呢？

我先来复述一下执行过程吧：

• 确定意向，资质准备；
• 产品准备，销售准备；
• 开始销售过程。

一般而言，企业逐渐壮大的过程会伴随着制度的完善。话事人达成一致之后，各侧会围绕项目开始推进工作。

但其中工作包含了很多场外事宜的准备，比如资质审核，验资/垫资，知识产权划分。这些环节固然很重要，但是作为一个创业团队，大量的时间和精力会被消耗在这类场外事宜上。更加保守的是，是资质准备完毕才能开启后面的工作。他从一个条件变成了前置环节。

合规是重要的，但是一鼓作气再而衰三而竭，项目组的士气被消耗也是非常实际的。

好不容易走完制式流程，进入推进阶段。我方要准备的产品定制能力的开发与销售支持。前者是为了为他们的销售团队入场做好完善准备，确保不会有品牌的隔阂；后者是让对方的销售团队用我方认为最有效的方式进行销售推进。

有过大型团队管理经验的人看到这里一定会敏感地意识到会有问题出现。

这本质是分属两个企业的团队融合协作的议题。按照客观规律，每个企业都有自己的秉性风格，在各自的领域里自成一派。我方非常积极地给对方提供「销售培训」本质上是进入另一个团队进行部署。对于对方而言，接受程度低是必然的，没有抵触情绪就万幸了。

所有准备工作完成，进入销售过程。

本以为会看到大量企业注册进入，但只收获了星星点点的几个。接下来的故事你们也能猜到，无尽地沟通，无奈地跟进，最后在销量束手无策四个字之上落脚。除了口头叮嘱，婆婆嘴跟进，毫无任何进展。

为什么会这样呢？我认为这次合作存在如下几个问题：

• 策略错误
• 能力的不足

以我有限的认知，在中国做商业，考虑合理的情况下，也不能忘记考虑合情。这里合情特指的是，两个组织是对等的。

一个完善的大型企业和一个创业团队天生是地位不对等的。合作可以开展，但是无法收获有效的结果时弱势一方只能不了了之，除了像个小媳妇一样赌气什么效用都没有。

现在回过头翻看协议里条款，牵拉感太强了。线被捏在别人手里，协定脆弱地跟纸一样。所以这里犯了策略上的错误。

能力不足这个没啥说的，技不如人甘拜下风。当时对于跨企业合作，有效沟通都是一知半解的状态，只能交学费了。

后来复盘写《如何成为靠谱的项目负责人- 肆》的时候，才有如下认知：

• 我认为冲突发生的因素有很多，但在企业中，分歧大多数来自于专业知识方面（来自俞军老师的观点）。
• 这些专业知识，分散在员工个人脑中，既包括用户的、市场的、行业的、政策的知识，也包括企业内部运行机制的、文化价值观的、以及企业内其他人的工作内容和个人能力风格偏好等属性。这些专业知识，就是企业的核心竞争力来源。
• 员工在个人岗位的工作中持续获得和积累的知识，起初都是个人专有的知识，但如果通过语言文字转换为显性知识，就可以被传播，成为企业的共同知识。
• 专业知识在组织内积累的越多，企业的共同知识就越多；企业积累的共同知识越多，企业内组织效率就越高。说白了，就是大家互相信任，有足够的默契。
• 曾经有同学跟我打趣说，我在公司开会发言时出场频次最高的词汇就是“共识”。我提议的“共识”便是上文说的共同知识。

怎么破局呢？

直接说观点吧：

• 把鸡蛋放在多个篮子里
• 找更高级别的话事人
• 更高质量的工作

合作方可以比你强大，但它也不能是你唯一的选择，用数量来分摊风险。在确定合作时就同步寻找多个同类型的合作伙伴，择优进行深度合作。

跨企业跨部门的深度合作是典型的职场高危场景，好比这个case，对方owner至少得是VP级别的人物。很多时候title代表了能级。这里并不是低估某个人的能力，此处关注的是商业可行性。

说一千道一万还是个人能力不够强，比如这种级别的项目，出差驻场是必须的。但那时候我对合作的理解非常浅薄，以为组织好电话会议，例会就万事大吉。现在看来真的幼稚的可笑。

所以这么好的牌面，但依然打出了流局的牌局。

举个不恰当的例子，如果1927年8月1日南昌起义是中国革命的必然。但是这个决策到底是共产国际决定的，还是中共的决定的，还是前敌委员会决定的。这背后的立场是要搞清楚的。不同层级的决策，带来不同能级的推动力度和影响结果。

渠道合作偏斜，这是我工作过程中很遗憾的一件事

二、定制项目走样

无论是SaaS业务的实践者，还是软件行业的从业者都会头疼大客户的个性化需求。

以我个人的认知，中国企业的职业化进程依然比较低，所以很容易进入机会主义的循环。说白了大家做事“豹有豹术，牛有牛招”。在A企业完全行得通的方案，在B企业那里是不以为然。

所以SaaS业务在中国天生面对着多样化的挑战。这是无法规避的天然属性。

上篇文章里有人问到：怎么应对大客户的个性化需求？

我的方式是：即便作为乙方也要用更深刻的洞察，更扎实的方案去管理客户。

你比他高，同时你有能力把他的认知提升上来，他自然而然就会认可你。

因为我本人在加入这家企业前，做过将近两年的技术外包的业务。同时自认为在向上管理上有些心得。虽然立场上一直在乙方，也一直是乙方管理甲方的状态。五花八门的业务需求，我会将需求进行提炼抽象之后再反哺产品，丰富能力。

所以，在17年大量打客户的阶段也基本没有被客户牵着鼻子走过，在增长和产品迭代中能达成一个可靠的平衡。

后来因为增长的和其他一些原因，公司在18年单独成立了大客户部。

这个团队是企业中典型的创新业务模式，一个研发+一个销售就开始工作了。他们的职责是基于当前产品，用私有化部署的方式满足个性化和定制化的需求给公司创收。

一部分业务从团队里分割了出去，这给企业带来了一些定制的项目收入，但也随之而来让品控出现问题。

• 从管理的角度，对方团队不需要向我汇报就可以直接改动产品
• 从销售的角度，关注业绩指标也算不上什么错误

综合到一起，大客户团队做定制项目是一个局部利益最大化的结果。但在全局利益的角度上，带来了一些问题。我记得自己跟大客户团队的人可没少吵架，这些管理债务在后面的阶段埋下隐患。

我个人的理解是先用产品满足通用需求，再靠行业解决方案满足个性化需求，最后从SaaS到PaaS走完最后一公里。

不同的阶段，重点各有不同，阶段性目标也不一样。很可惜，当时我沉浸在完善企业信息化的基础设施中，没能控制好这个变动。这也从侧面反映出来当时的战略能力缺失和管理意识的不够扎实。

如果回到当时，我会在管理例会中反对在那个阶段成立大客户团队做定制项目，至少让机制更加完整些。

三、客户成功没有落实

上篇文章我提到了，我用做产品的思路设计销售团队。为了获得增长，用双脚沾泥的方式解决SaaS模式下解决不了的问题。刀耕火种的阶段是奏效的，但是最终也还是要回归到正规的销售团队管理中。我们必须要考核业绩，进行系统化地增长。

新的问题就随之而来了。

开始前先说说客户成功吧。客户成功是一个在SaaS行业中大家耳熟能详的概念了。应该没有人会拒绝和质疑他的价值。我当时任职的这家企业也客户成功团队，但观察下他们的工作日常你会发现其实客户成功团队在做客服的工作。可能这是整个行业的通病。

他们每天用在线客服软件，电话，工单的方式跟用户接触。为用户答疑解惑，解答产品使用方法等，打心眼我很感谢他们。他们的存在让服务的手指也能触达用户。

文章聊得是销售体系的搭建，为什么我这里要谈客户成功呢？

因为很多时候销售和客户成功的关键节点是存在重合的，也是阶段性矛盾的。

举个栗子：

• 用户付费了，日常的服务是谁的工作？
• 用户未付费时，答疑解惑的服务做好了，付费转化了。这单算谁的？
• 用户自行付费，没联系任何人。续费期谁去跟，业绩怎么算？

除此之外的衍生问题：

• 销售的岗位特性就是攻城略地打单拿佣金，客户成功也可以有吗？
• 作为客户成功他们的工作事项也会导向付费，那这时他和销售的区别是什么？
• 总要有人做好日常的服务，别的小伙伴做销售收入增长，怎么保障团队稳定，平复人性驱使下的心态变化？

后来在一些同事聚会上听到，甚至出现客户成功团队和销售团队发生冲突的现象。从我在那家企业任职以来，我的工作和客户成功一直是平行的两条线。如果有机会实践，或许情况又会变得有意思些。

四、总结

相较于上篇文章，今天聊得更多的是过往的遗憾和失误。以上谈到的这些或多或少都在我曾经的管理范围内，需要我思考和设计的部分。

遗憾的是我在18年底就不再列席公司的管理会议了，很多本来有机会去完成的挑战，也无法继续推进了。以后有机会再进行实践吧。

讲了很多，不变的观点「SaaS的增长是一套完整的系统工程」需要高屋建瓴，也得放得下身段双脚沾泥。在更深刻的理解中国商业，中国式生意之后，或许才能让SaaS这个舶来品更坚韧地扎根生长。

毕竟发展的问题只能通过更高质量的发展来解决。

作者：马曦文，公众号：maxiwenfine

本文由 @马曦文 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议