SaaS越来越火，然而这个行业并不容乐观，那么究其原因，其中企业为何频频面临失败？

最近，企业服务、B2B、产业互联网和SaaS越来越“火”了。

一方面是创投市场方面在C端的萎缩，让资本和VC们开始更加关注B端赛道。另一方面，因为中小企业在社会中的巨大作用，也让市场和行政资源，开始思考如何更好的服务于他们。

尽管2015年被创投圈称为中国企业服务的元年，但同一时刻，SAP、ORACLE和微软等企业，早已瓜分了中国大部分头部企业的信息化预算，而金蝶和用友等国产厂商，也在一定的市场定位中，打下了自己的江山。

眼馋于大洋彼岸成熟市场中，面向B端的成功商业模式占据半壁江山，越来越多创业精英们开始考虑，将SaaS模式作为国内企业服务行业的切入点，并疯狂付诸于实践。

很遗憾，差不多5年时间过去了，不少同志来也匆匆，去也匆匆，而除了一少部分跑出模式的个别厂商，大部分人都还在苦苦坚持。

在资本收益与时间的不断催促下，大家前仆后继，出局者让人心疼，坚持者让人怜悯。让很多人无法面对现实解开心结的，则是承认已经“失败”或者在坚持的路上等待“失败”到来。

来自灵魂深处，经受不断的拷问：你是“失败”的SaaS么？而又是什么原因失败的？

没熬到时候

中国最厉害的软件及科技互联网企业是谁？马云和他的阿里巴巴莫属。

阿里第一桶金怎么来的？依靠“中供铁军”们一次次敲开中小企业的大门，营销面向中小企业的互联网服务并签单。

马老板的理念是什么？服务企业，让天下没有难做的生意。为了服务做生意的中小企业，阿里推出了软件互联平台向企业推广SaaS类服务，而为何又在10年4月关闭了SaaS平台？以退为进，等待时机成熟。

时机成熟了么，阿里新的营收和业务增长点是什么？云计算基础架构生态和市场认可度趋近成熟，阿里将再战ToB。

就像很多优秀的政治家，能够把握趋势的变化。在最合适的时机，一脚踢在土堆最薄弱的地方，然后引发摧枯拉朽一般的联动效果，伴随着土堆的倒塌，享受世人的敬仰，并被尊为时代的开创者。

数年前，公共云计算的技术能力还不成熟，稳定、快速、安全的服务还只是宣传的语录，企业对于管理和业务数字化还存在疑虑。如今，技术难题被攻破，企业理念在升级，之前的问题或许都不是问题了。

身边的朋友，数年前带队开创了国内最早SRM（企业供应商管理）的SaaS产品，但熬不住孤单，最后黯然放弃。而从去年开始，SRM市场开始在国内打开，越来越多的玩家开始涌入这个领域。

《三次转型，阿里决定再战ToB》,而很多ToB人，既没有阿里这般雄厚的生态实力，也没有继续从资本市场上获取资金的能力，各种原因无法坚持到这个时候，无不为他们感到惋惜。

选错了赛道

男怕入错行，女怕嫁错郎。

脑袋一拍，杀入红海，半年打磨产品，6个月疯狂推广。铺面而来的是，竞争对手在产品形态和市场认可方面，领先好几个数量级。

市场都杀红眼了，如果还没有想清楚自己的价值、优势、特点，或者拿到足够充足的资本弹药，这个时候入场的结局，基本是给同行做嫁衣。

虽然你也有情怀，虽然你也是某企业服务行业领域的资深专业人士，但是市场真刀真枪的拼杀，就是这么残酷。

当然，成熟市场的赛道，也必然不那么好攻占。就像很多人一提到高端ERP，就直接和SAP、ORACLE划等号一样，很多产品在市场中都已经完全挤占受众心智了，如果你选择直接硬杠，而不是通过破局讨巧或模式来降维打击，也基本没戏了。

中国市场规模最大和利润最多的行业是什么，如果你观察最新的财富500强：金融、地产、汽车、家电、零售、互联网。把握一轮行业红利，踩在上升的电梯里，你也很有可能赌对赛道。

所谓旱的旱死、涝的涝死，下行周期及淘汰行业，都已经进入供给侧改革清单了，金融资源都不投放了，你还认为这类企业能挤得出利润，来购买可能是锦上添花的产品和服务么？

上升周期的企业，优先考虑的是如何通过投入、合作共赢等方式，扩大市场和利润。

而面对下行周期的企业，你和服务对象之间的供应链供需方的博弈关系又会如何呢，你难道不怕被企业的回款和账期拖死？

服务客户所处的周期，以及行业利润和市场容量，决定了你的营收天花板和回款质量。想一下占据年营收大约3%的中国企业信息化投入，落实到具体的企业个体上，哪些因素会左右，不言而喻了吧。

背离了模式

市场和资本对SaaS模式非常认可的核心重要逻辑和最大价值之一，是通过向企业提供标准化的产品或服务，获得基于时间片段的订阅付费等持续性企业用户付费的营收模式。

绝对理想化的形式是，SaaS产品标准化，以及多租户和按需订阅的付费制，让企业服务的经营模式一旦滚动起来，获客成本(CAC)与留存成本(CRC)能够边际递减，迅速规模化。

而现实的情况，除了在一些集中度不高的行业中，各企业需求相对标准，其余的行业头部大型企业，相对强势且可能有自己的特点及特殊需求。

因此，依靠高度标准化的SaaS模式，在客户定制化和产品标准化之间，往往充满了难以调和的矛盾。

坚持标准化，还处于发育阶段的SaaS厂商很难吃下大客户市场，向“SaaS市场就是得大客户者得天下”的战略目标进发。

放弃标准化，回到客制化，营收保住了，却和非产品化的软件开发公司没什么区别了。按照程序员人天，核算项目成本利润的方式，让企业价值和商业模式，瞬间变得平平无奇。

一些厉害的SaaS厂商，在发育过程中，能够很好的平衡这一矛盾。在增长、营收、成本、资源投入中，做到符合当下战略的杠杆平衡点。而或许某类行业或赛道，就暂时不应该出现SaaS倡导的商业模式，特殊的客情及客观的现实限制，即使交给厉害的人来操盘，也无法达到那个平衡点。

行业内一直有个说法，通用型的MES(制造企业生产过程执行)系统和服务，是很难出现在市场中的。而某MES厂商能获得多少市场份额，则取决于自家有多少既懂某行业生产业务的特殊性，又能设计客制化信息系统的专家，能扑在客户的项目上。

值得关注的是，SaaS倡导的付费订阅模式，并不能完全代表企业服务行业的先进模式。而这个行业的高价值模式，其实是有更多的体现方式的，甚至毛利率或者ROI会远远高于SaaS模式！

叫好不叫座

这几乎是是最悲惨的一类SaaS创业者。

如果你产品或者服务太烂，亦或者杀入时点市场已经是红海，苦苦坚守后选择放弃，怨念不会太大。

面对市场认可和行业好评，却无法迅速攻占市场并夺取客户的SaaS创业者，最后换得一地鸡毛的结果，令人无不惋惜。

当然导致“失败”的原因有很多，和上面提到的几点都可能有关系。可是对比来看，很多市场口碑和评价平平甚至糟糕的SaaS产品，一样卖的很好，估值一样很高。怎么才能把自家产品卖出去？怎样才能让产品又叫好又叫座？

而ToB营销，公认的行业难题，获客效率之低，成本之高，是企业服务厂商能做大做强的一道鸿沟。用户增长的核心秘诀，一定还是落脚在渠道和转化上，无论方法怎样，比拼的是效率和投入产出。

影响渠道转化效果的因素很多，比如预算和人员的限制，比如缺乏某渠道的管理运维经验，比如没有挖掘某渠道转化效率的方法。也有在渠道和转化开拓过程中，不断组合尝试各种方法，最后“死于”折腾的。

同样是做云ERP产品，紧紧依附阿里商家生态模式的聚水潭，为何比其他云ERP厂商会有更多的线索来源渠道？为什么Slack这种具备聊天功能的协同类SaaS，能够获得病毒式传播的高转化效果？

究其原因，是产品与获客渠道，是否能够很好的契合。一方面是上面说的人为的原因。但更令人悲伤的是，很多SaaS产品，目前阶段是先天客观无法与获客渠道契合的。这就导致对应渠道获客成本挖下的坑，是无法被后续客户生命周期内的持续营收，来填平的。

俗称，越卖越亏！SaaS这个行业，不成功便成仁。

最后“失败”的原因，肯定不止上面说的四种，甚至是很多复杂因素和变量综合影响下的结果。

年初的时候，一篇《谈谈to B业务的难点》的文章火了，无数企业服务行业从业人员和投资人在朋友圈疯狂转发，无一不捶胸顿足痛苦流涕。

如果是行业的外围人员，或者是还看不透行业的投资人转发，根本不用感到意外。毕竟这个阶段，理解B端生意模式的，只是一部分人。而行内人士的拼命转发，我更相信是文章中提到的痛点难点，勾起了大家梦魇般的过往历史回忆，以及一些行业内人士对未来的黯淡感。

回顾这几十年，企业服务的这些问题改变了么？有被解决么？

要知道，这些都是“现象”，而不是“问题”。“问题”需要被解决，而“现象”则需要穿透并抓住“本质”，搞清楚什么是果什么是因很重要。

这些东西，过去无解，现在也一向无解。

换句难听的说，这也是to B行业的一些顶层企业玩家在生态和商业格局下，为保持自身优势，留给竞争和后来者的坑和套。可怕的是，还有人不断在怂恿和督促，让这些进退两难中的一些并不适合客观市场规律的从业者，不断坚持继续打磨产品，这简直在“杀人诛心”啊。

如果复盘，几乎所有成功的ToB厂商，都是做营销、生态及运营的战略化高手。

就如同上面这张底层逻辑图所展示的，每一个优秀的ToB服务企业，都是在战略上优化上图的高手。

其中的明星们，有的通过借力来降低获客成本或者推前盈亏点的到来，有的通过产品或服务模式，延续并拉长每个客户的生命周期，还有的通过技术和能力输出，抬升两条线的夹角，提高用户生命周期内的利润产出。

而通过不断的获客，并将大量客户形态的上图不断的叠加，并通过财务报表展示。一般的to B企业，做精其中的一个环节，就能在市场上活下来。

而一步一步走来并成为行业龙头的企业，除了符合客观的市场环境，更是找准了每个阶段最值得投入的事情，并坚持下来了。

如果回顾开头说的各种“失败”的SaaS们，我们都能总结回归到一些最底层的商业逻辑上，而破局点就在这些底层逻辑上。这里先卖一个关子，我后续会聊聊底层逻辑。

本文由 @小哈公社 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议