我们为什么会选择给 SaaS 产品提价？

作者： Database Labs 创业团队

编译：拓扑社 原野

Database Labs 创业团队提供了某种 2B 的数据库服务，在本文中，他们详细解释了产品选择提价的理由和时机。

我们做了一款线上的数据库服务，这个数据库的类型是Postgresql（自由的对象-关系型数据库服务器，在灵活的BSD-风格许可证下发行。）与现在市面上的 Google、AWS、DigitalOcean等服务展开正面竞争。最近，我们把这款产品的价格给提上去了，然后客户群就彻底炸了锅，大家纷纷前来问询我们：你们为什么要涨价？涨价也总得有个原因吧？所以，也就有了这篇文章。我想借此跟大家解释一下，SaaS 产品提价的时机，背后的原因，以及有可能出现的影响。

不要觉得这次提价只是拍脑袋的举动，提价的背后是有大量数据给予支持的，而这些数据来自于很多方面，有的是在后台分析客户行为，有的是找出关键用户进行调研，表单上很多数字需要一一的分类，细化，找出最具决定性作用的那一批，最后得到“涨价”这个结论。而总的来说，下面的三点因素，是促成这次涨价的最重要理由。

绝大多数的用户在价格上并不是十分敏感

我们刚刚踏上创业之路，首先环顾四周，打量一下周围竞争对手的价格，然后松了一口气，原来它们在市场上挂出的价格这么贵啊，我们完全可以在价格上面获得优势。我们算了一笔账，自己在运营维护上的成本其实并不是很多，由此价格就会定的低很多。在我们脑补出来的画面里，客户们成群结队地转移到我们的这个平台上，原因只有一个：价格便宜。

但是结果呢？事实上，几乎没有几个人真正在意我们的价格有多实惠。商业数据库的用户在价格上面呈现出高度不敏感的特点。我自己的判断是：这是他们老板的钱，或者说是公司的钱，并不是他们自己的。所以，他们更在乎的是服务的可靠性，技术支持的完备专业性，而不是考虑争取一个低价。（事实上，价格低到了某种程度甚至就意味着低劣的品质。）

同时，正因为我们的价格特别低，所以我们的利润也就特别得薄。我算过一笔账，我们的利润跟竞争对手相比，连他们的一半都达不到。

解决办法：要让我们的利润率跟业界平均水平保持一致，涨价是最终唯一的选项。

客户获取成本，你们想象不到的贵！

我们周围的竞争对手，要么是一些超级大公司，比如 IBM、Amazon、Google；要么是一些获得了风投资金支持的初创公司。不管是哪一种竞争对手，它们烧钱的速度简直可以吓人，感觉钞票如废纸一样的往马桶里扔，目的就是为了在短时间获取到市场份额。

为了达到这个目的，他们甚至愿意好几年都是赔本运营。每一个月，每一个季度，每一年，他们都在死扛，他们确信自己不是最先倒下的那一个。等其他竞争对手的钱全部烧光了，那么市场就由它一个人来垄断。

我们不一样，我们的钱都是自己的，并没有风投公司送钱进来让我们烧，所以这场烧钱大赛的游戏，我们玩儿不起。我们不可能为了获取用户，把几年的收入拱手相让出去。我们现在所能做到的就是稳健增长，每个月争取不赔钱，然后一点点的撑到明天。但在这儿过程中，我们获取用户也是需要成本的，我们在每一个用户获取渠道上面还是在跟他们展开竞争。

我们这些公司在几年后，要么一些彻底倒下，要么被一些大的公司收购兼并。而我们为了成为最后的生还者，必须提价，来在营销及获取用户上面做最起码的较量。

提供优质的技术支持会花掉不少的钱

我们一直有一个目标：致力于在云软件服务供应商这个圈子里，打造最棒的技术支持服务。我想，我们的客户应该同意：没有哪个地方的技术支持会比 Database Labs 做得还要出色。小公司做的比大公司好的地方并不多，而技术支持就是其中之一。

我们自己也曾经作为客户，选择过某些大的云服务供应商。这其中经历了不可避免的“运营维护”期，我们深知现在的技术支持普遍停留在何种层次上面。有些时候电子邮件忘记发了，有些时候问题提交上去迟迟不见回应，就算有回应也是几天之后的事，寥寥几句就把你给打发了。还有很多云服务供应商的技术支持人员更换频繁，每次负责接待你的那个人，似乎永远是新兵蛋子，一头雾水，什么都不知道，要么就是误解你的意思，要么就需要你从最起点，花足够的耐心来解释整个问题的来龙去脉。

现在对于很多用户来说，最残酷的事情就是：就算你每个月在云系统上投入的预算已经达到了 5 位数甚至 6 位数，但是在Amazon 的季度营收报告中，那也只不过是一个零头。他们压根不会在乎你或者你的生意。因为这些巨头享有足够强势的地位，客户高兴满意与否并不会直接对他们的存在构成威胁，所以他们只需要提供某种马马虎虎的技术支持服务就好了。

而回到我们这家小公司身上，虽然我们是初创公司，其体量规模完全不能与Amazon 一战，但是我们在技术支持上面可以做得更好。但……

提供一个完美的数据库，并不能解决一切问题。

可靠稳定，性能卓越的数据库有了，但是这弥补不了应用底层架构的一些缺陷。如果这款搭载在数据库上的应用结构本身就漏洞百出，代码错误比比皆是，那么不管你的数据库有多么优秀也无济于事。

但是有很多客户可不知道这些。他们只是看到应用出现了错误，或者某些表现不尽如人意了，然后他们就开始把所有的怒火投向了我们。有些时候他们还会对事情抱有更高的期待值，觉得“数据库”是一个灵丹妙药，把所有问题都能解决了。

于是，麻烦接踵而至。他们开始不断地找技术支持麻烦，要求我们对数据库进行调整，认为问题是出在我们这里。在经过好几个月的拉锯战，浪费了我们大量的人力、时间之后，他们最终拍拍屁股走人。

如果我们提前能够识别出这些客户就好了，尽管他们占比很少，但是确实严重的影响了我们团队的服务质量以及工作安排。但是我们没有办法提前辨识出来。

现在摆在我们面前的就有两条路：要么，是给技术支持拨出更高的预算，将技术支持水平维持在理想的水准上，当然这里面要应付上述所说的“无知客户”；要么，我们在技术支持上面做妥协。

但最后，我们还是选择了前者，并将上扬的成本体现在了价格上面。

最后的话：定价其实就是某种平衡之术

定价是非常微妙的，你可以之前做无休无止的实验和分析，但最终搞清楚一切的方式还是把一个价格投到市场上，看大家的反馈是什么。

我们在未来还会继续调整价格，市场也永远处于变动之中，我们的各种成本在变动，客户的偏好也在变化，竞争对手来了又去了。我们在调整价格之前，需要通盘考虑这一系列的变量，随时适应市场的需求。

本文为拓扑社编译，未经同意不得转载或引用

寻求报道&合作请联系：tobshe@itjuzi.com

关注拓扑社微信：tobshe，获取更多内容哦~返回搜狐，查看更多