“SaaS（Software as a service）的本质是交付一套保准化的服务（方法论），而软件只是这套服务上的一个载体。”

这个观点是之前在某篇关于SaaS的讨论上看到的（若之后再看到会补充引用），那时候感触不深，但是近期发生的几件事情让人会对于这个观点有一些新的体会。

如果你觉得这篇文章太长，可以直接看我的结论：

以下将结合最近发生的两件事情为例展开解释。

最近我在搭建一个知识库，其中我需要邀请一些创作者一起来共创。为了更好的进行信息管理，我需要一个「创作者联系和管理」的工具。

我的需求是：

“我需要记录我和哪些作者建立了联系；我转载了他们哪些文章，他们要能快速看到这个文章列表和对应的文档链接；内部人也要能够知道wiki有哪些更新。”

这时候，一个在效率工具软件和项目管理上颇有经验的朋友给我提供了一些帮助。他结合过往的经验帮我初步搭建了一套，然后我根据他搭建的底层去自主添加我的需求点。

在这套服务里面，我觉得最重要的是他提供的这套方法论。

比如在搭建我的「内容管理库」时，我会发现对方提供的管理工具超出了我本身的预期，有一些字段或是表格的设置逻辑我本身是没有提出这个需求，但这又属于为了做好这件事情应该要有的配置。所以在这套工具的基础标准上，我又多沉淀了一些信息。

这让我想起我之前看过一篇文章，讨论「客户成功和客户满意二者之间的关系」的问题（详见：客户成功就是让客户满意吗？）

这篇文章所讨论的内容结合我今天所讨论的话题是：一个没有成熟方法论的客户在对一个产品提出需求时，如果一个产品本身提供的方法论不足，不能洞察到客户更深层次或是所处场景之下所需要的系统性方法论，那最多只能实现「客户满意」而非「客户成功」的阶段。

因此，「客户成功」的实现需要的不仅是一套工具，并且是通过工具承载的那套方法论。因此，客户在购买产品、愿意为产品付费并且是高额付费的，是这样一套具有系统方法论的工具。工具本身的溢价并不高，但产品竞争差异更多是在方法论或是用户体验等更悬的地方。

我们公司最近也恰巧在寻找一个更加成熟的CRM软件，需求是工具，但其实缺的也是一套好的方法论。

本来公司内部是用多维表格自己搭建了一套，但是逐渐发现并不能很好的满足使用需求，于是开始选型，最后面采取的解决方案是通过airtable来管理。

我有一个做CRM的朋友，针对这件事我们俩也交流了一下。

他说：“airtable虽然在部分功能上比你们当下的解决方案会更好，但是未来你们还可能因为两个问题去切换工具。一个是产品协同问题，另外一个是公司商业化规模化发展之后，airtable也不能满足你们的使用需求，那到时候也还是需要切换到其他的工具。”

“为什么你会觉得airtable未来不能满足我们的使用需求呢？”

“一个好的SaaS产品应该承载的是一套完善的方法论，你们虽然在工具使用上有更强的意识，但是在工具所承载的方法论上并不是那么精通，因此会觉得现阶段的解决方案能够满足需求，等到了未来规模化发展之后，需求增加了，那对应的问题自然会显现出来。”

一个是数据迁移成本问题。

如上文所述，工具承载的是一套成熟方法论。但当一开始选择的工具和之后的方法论不适配，那后续很可能还是需要切换工具。

软件当中承载着大量的企业数据，而随着使用时间的增加，数据迁移的成本也会递增，想想我个人现在要把数据从不同的kMS平台上迁移过来这时间成本就多高了，更别提一个发展规模大的企业日积月累所沉淀下的数据。

浅浅咨询了一下几位朋友，数据迁移目前并不能完全自动化，其中还是要耗费大量的人力来完成。如果说未来这部分市场需求能够被满足，那还是很有吸引力的。

第二个是抽象方法论和垂直场景下更多的需求之间的矛盾。

一个工具如果要适合更大的市场，在设计思路上就要更往底层走一些，但是越底层的工具对具体的垂直场景理解就稍显不足。

抽象的方法论并不是完全通用的，不足以应对复杂多样的需求。

所以这里面就要看哪一家的方法论能够抽象得更好、产品搭建得更底层，并且用户根据自己的需求自主配置的灵活度更高，并且从产品供给端能够更多垂直场景下的解决方案，那才是真正具有强市场竞争力的。

以上浅见为近期的一些新想法，不一定都对。但提笔撰写此文，一是为自我表达，督促自己把一些想法及时记录下来；二是为找寻对这些问题有更多思考的朋友一起来交流探讨。