一、稳定的商业模式，细分市场和顾客分层
成熟的SaaS产品已经建立了稳定的商业模式，收费方式和定价不再是一个设想，而是事实上经过了验证，不仅是第一年的新客户获得，还至少要经过一次到两次的续约。大部分企业SaaS都至少需要100-200家企业客户的商业化实证才能确定商业模式的有效性。
反过来说，如果仅仅提出一个商业模式的设想，没有事实上通过它得到持续增长的收入，它不可能是一个成熟的产品。在这个发展中市场，并没有现成的公认可靠商业模式，所以，必须依赖厂商的商业模式有效性来证明它的成熟度。
同时，成熟产品的客户构成也会从早期的杂乱无章走向某种规律，要么是聚集在某些行业，要么是聚集在某些规模上。如果是行业SaaS，也依然可能有进一步细分市场的选择。比如明道的客户构成经过几年的沉淀，已经具备鲜明的现代服务业特征，他们要么是TMT行业，要么是一个项目任务型组织，在规模上，90%的客户集中在20-200人的范畴内。这个过程到底是服务商选择了客户，还是客户选择了服务商是很难说的，它就是企业战略选择和竞争的结局。有了明确的细分市场选择，产品成熟度提高的速度反而能够进一步加快。因为如果知道90%的客户都有鲜明的特征和需求分布，你自然能够更加从容地设计有效的产品路线图。
有了明确的细分市场还不够。产品的商业模式还要能够有效地进行顾客分层，比如20人的企业和200人的企业总是会有很大的不一样。这个价格分层到底是通过用户量线性分配，通过产品功能特性组合，还是打造完全不同的版本来区隔客户？这是要根据实际运营的效果来决策的。初创的SaaS产品可能对这个问题并不敏感，只要能够有客户就好了，所以我们甚至看到过一口价的SaaS产品，但这个简单求快的办法并不会长期，很快你就会发现这个价格对于任何客户来说不是高了，就是低了。于是我们来寻求一个最合理的变量来确定阶梯价格。经过一到两轮的客户分层方法调优，产品服务不同层次客户的综合能力也会加强。顾客分层并不是无谓的复杂，也不是价格歧视，也是保证总体最优效率的最基本办法。
当一个商业模式和对应的价格水平能够稳定一到两年，感觉已经没有大幅修订的必要时，SaaS产品在商业模式上才算稳定下来，它是对产品成熟度的第一大贡献。
二、产品透射了专业和行业最佳实践
早期的SaaS产品基本就是一个可运行的程序，它接受用户的输入，给出用户需要的输出。但大量的主流用户并不知道如何输入，甚至也不知道如何使用输出的结果。比如用户企业需要实施CRM软件，它需要什么输入呢？软件给出的输出能够帮助企业解决什么问题呢？在中国SaaS市场的绝大多数领域，这些问题的答案都是不明确的。
所以，一个成熟的CRM应用必然需要将销售管理方法、流程和工具内置在产品中，它不仅需要提供一个程序，还需要提供一个使用程序的程序。
我们曾经花费了很长时间要搞定营销自动化这个需求，但是坦白说，作为一个SaaS软件企业，我们自己都不太清楚这个行业的营销自动化的基本原理、核心目标、执行手段和评估方法是什么，所以如果一个产品不能帮助我们解惑，即使有很大的动力，我们也没有足够的能力去使用它。
这样的例子无处不在。BI算是企业软件比较成熟的一个领域，但是在SaaS化的产品中，能够帮助企业建立有价值的数据看板，能够提供合理现实的数据整合工具的产品依然罕见。大多数产品还只能停留在“创建看板”、“创建图表”这样的功能链接上。这当然不能征服那些有需求，但又不知道如何去做的用户。
我再举我们行业内部的一个例子。SaaS企业的财务核算是一个老大难问题，因为我们通常有大数量，小金额的订单，又有周期性订阅、一次性收入、退单、流失、回流等影响准确收入核算的复杂行为组合，所以每家公司在财务信息核算方面都极度痛苦，但是缺乏有效的解决方案。http://MRR.io和http://Chartmogul.com是硅谷的两个针对此问题的专业产品。它们不仅提供了可用的软件，还直接帮助SaaS企业一次性创建了所有必要财务指标的看板。在软件工程以外，它们投入更多的是行业最佳实践的分析和整理，所以它们帮助客户提升不仅仅是工作效率，还包括运营水平。
作为SaaS产品，你有没有能够帮助客户提高运营的水平，获得从未有过的新知，从而帮助客户企业的员工建立一种新的能力。如果你能够做到，那不仅仅是成熟度的标志，还是客户口碑的保证。
三、健全的用户入场协助
大多数的企业SaaS在一个组织中都是多人使用的。所以软件的设计和运营必须考虑怎样帮助这些用户同步入场。一个财务软件需要CEO，财务主管和会计人员一起使用，一个CRM软件至少需要销售主管和销售成员一起使用，一个协作软件更加需要一个组织的几乎所有人都一起入场才好。
为了做到这一点，SaaS产品需要首先拥有完善的团队账户架构，能够支持每个个体用户使用实名账户，被初始管理员授予合适的权限，如果有多个团队，还可能需要团队管理员这个角色来减轻大管家的压力。为了加入新成员，调整成员和分组的过程必须足够清晰和简单，让客户有动力来维持这个用户系统。相反，如果我们在这个问题上忽视，胡乱地分配一些001，002工号出去，甚至允许用户合用账号，那客户总是会走到混乱失序的那一天，距离客户流失也就不远了。
仅仅有了科学完善的账户结构体系还不够，我们还要帮助企业穿针引线，让多成员进入这个系统非常简单和轻松。比如一个BI应用，在配置外部数据源的时候，需要用户添加Google Analytics的Profile，问题是掌握这个信息的人可能不是管理员本人，他可能需要同事的帮忙才能完成这个配置，这时候软件可能需要直接将邀请成员完成一个配置作为一个用例来对待，设计出专门的交互界面。
我们协作软件面临最大的集体上船挑战，怎样让一个企业的管理员用最小的精力，最大的准确度完成员工账户邀请和配置消耗了我们多次的迭代投入，才稍微有点样子。
大家都上船了还不够。软件还需要设计一个用户引导过程，帮助他们快速了解软件的基本功能，必要的时候要让他们上手操作一下，让用户能够创建自己的数据，才能够保证用户留得下来。光这个事情，也许就要花费一年的时间，因为在同一周期，你的软件功能本身也在迭代。
我有一次在机场顿悟，昂贵的机场设施和几乎所有的机场地勤人员其实只为一个事情，让乘客登上飞机。而我们去机场，其实是为了坐飞机旅行，我们不一定意识到onboarding的过程这么重要和昂贵。
当一个SaaS产品意识到这一点，把帮助用户上船，上飞机作为一个大型项目来看待，它距离成熟就不远了。
四、支持外部数据整合的开放性
最后一点，成熟的SaaS产品必然考虑开放性，如果没有API，几乎就不可能成为一个长期存在的SaaS产品。CRM软件要考虑主要的线索（Lead）数据可能来自另一个营销平台，销售成员的日程和任务信息如果孤立存在在销售平台就无法产生有效的协作；客服平台需要考虑工单需要在企业内部多个角色进行流转，而不仅仅是客服专员；财务软件需要考虑订单，发票可能由ERP系统提供；协作软件更加需要把几乎所有的数据实体开放。
在帮助企业客户克服数据孤岛问题的过程中，整个SaaS行业别无他法，只能是每一家都有一套可靠好用的编程接口。然后，有朝一日，中国也会有像IFTTT，Zapier这样的整合平台，可以帮助大多数用户轻松建立两个应用之间的数据流转自动化。
一个标准化的SaaS软件可能增强到特性丰富，组织有序的良好状态，但是它绝无可能提供用户所要的所有功能，企业用户结合使用多个产品工具解决业务问题是一个常态。有了丰富的编程接口，至少让用户有机会能够通过变通的办法来实现他之所想。这其实也是产品成熟度的表现。因为，这时候，客户成功团队面对客户需求基本都可以很有信心地答复：“嗯，这个是可以做到的，而且并不复杂”。
我们从2011年开始内部打造明道，到现在已经整整六年了。我平时也特别关注北美同行，好不容易发现一个特别厉害的产品，仔细一看，也几乎都有五年以上的历史。当回头看一个产品的发展史的时候，你对产品成熟度的理解会更加深刻。因为我们做这一行，所以特别理解这个过程，愿意接受长期耕耘的挑战。但是话说回来，成熟度的到达，总应该有个标志，所谓瓜熟蒂落的时刻。祝你丰收。
