做SAAS产品，如何在标准化和定制化之间权衡？

萌沐 2023-08-09 03:03:14

SAAS在做产品时，不应该一直坚持做标准化产品，而是应该积极探索定制化产品的可行性和价值。

SAAS产品的个性化定制化是企业服务的重要方向，对一些B端客户来说，个性化需求和服务是他们考虑使用SAAS产品的主要因素。

不同的行业、企业之间具有很大的差异性和特征，SAAS产品应该根据企业的情况进行合理调整，以满足客户的个性化需求，同时保证产品的标准化，确保产品的质量和市场竞争力。

通过开放API和提供定制化功能来支持客户自主定制个性化的产品服务，仅仅是其中一种方法。同时，要注重与客户沟通和及时捕捉客户个性化需求，并以科学的方法去分析这些需求是否具有普遍推广价值。

首先需要先明确一个前提：大多数能够做定制化开发的企业是大型企业。

在进行产品月度续约率和月度续费率复盘时，我们发现小型客户的续约率相对较低，主要原因是缺乏预算或业务转型。

因此，SAAS产品的定位大多是在KA（关键客户）客户上。如果有3到5个客户没有续约，产品的续费率可能会急剧下降，甚至有可能下降了30%。

在初创企业或企业面临困境的早期阶段，定制开发是可行的，但目的和结果可能有所不同。

如果我们对产品没有好的想法，前期可以将用户调研和定制化开发相结合，互相受益。或者在公司面临创业或生存等问题时，定制化也是一种出路。

然而，在长远看来，不可复用的定制化并不适合。

主要原因如下：

（1）通常情况下，新签客户的第一年赚到的钱不多。

容易卷入价格战虽然定制化项目可以在短期内赚到钱，但赚来的只是“人头钱”，需要x人月，每人月费用y，所得收入即为z = xy。

如果在第一年花费大量精力来完成项目，结果客户在第二年找到了另一家厂商且价格更低，那么我们就将得不偿失，甚至会被卷入价格战。

（2）客户需求变化快，我们为每个定制化客户提供的软件都是独立的版本。

每个版本都需要进行客户需求升级、Bug修复、环境参数变化造成的软件维护等工作。因此往往需要高昂的成本和风险，并需要投入更多的人力、物力和财力进行开发，但无法在短时间内实现规模化生产。

此外，企业客户的需求和业务环境是不断变化的，定制化产品也需要随之调整和升级，甚至有些定制化产品需要非常具体和个性化的功能才能适应新的市场需求。对客户的及时响应也是需要一定的维护成本。

（3）无法传递价值。

在SAAS公司的产品开发中，我们可能会比客户更了解业务，可以通过数据等方式获得更多的玩法和经验，并将价值传递给客户。

然而，定制化产品更多地按照客户的想法来制定，可能无法获得好的结果。有时候客户也没有想清楚到底需要什么，或者是否正确？

因此，在产品开发中，我们应该在定制化产品和标准化产品之间做出权衡。

根据企业的情况进行合理调整，以满足客户的个性化需求，同时保证产品的标准化，确保产品的质量和市场竞争力，实现企业资源的合理配置和持续发展。

我们企业是一家专注于客服领域的SAAS标品提供商。受疫情影响，我们的业务出现了严重下滑，因为客服数量和业务形态发生了改变。

大多数客服不再在家办公，而是使用云客服，这与我们之前的管理模式有很大的不同。由于原有标品的功能无法及时满足企业的需求，客户的反馈也得不到及时响应和解决。

目前，我们面临着两种选择：

开发定制化产品以满足客户需求，单独收费，同时逐渐将定制化产品转化为标品；
坚持统一迭代，拒绝开发定制化产品，但可能会失去大量客户。

我们需要认真权衡这两种选择的优劣，找到最合适的方案来保持客户和企业的增长。独立搭建定制化小组承接项目，同时按照原有计划继续迭代标品。

我们认为定制化项目分为售前、售中和售后三个阶段，每个阶段都很重要。

下面以负责过的X公司的Y项目为例，结合场景谈一谈我们的经验和建议。

背景：X公司希望通过顾客的反馈和售后赔付两个维度交叉挖掘Y产品出现的问题，是由于物流？还是仓库？或是其他原因，从而帮助企业及时得到改进策略。

一、售前打单阶段

在售前阶段，首先需要了解客户的需求，包括客户的目标、目的和时间。

在这个项目中，我们需要询问X公司的业务情况，先了解他们要做什么，以及他们出于什么原因需要我们的帮助。然后提供方案，和X公司进行沟通，得到他们的反馈和确认，从而达成良好的合作。

由于缺乏经验，我们曾经遇到以下几种错误的场景：

场景1：根据我们按照X公司21年Y产品的开展时间（8月）推算，22年的业务也应该在8月开展。然而，X公司在22年提前了业务的开展时间（7月），我们没有了解到也没有询问。这导致双方对于业务开展时间的认知出现了差异，X公司认为我们不重视业务，签单后连续几个月都没有安排，导致业务开始了但是无法使用我们的产品。
场景2：最初对接人员M员工并不熟悉实际业务，且缺乏直接决策的权力。因此，需要X公司确认的内容较多，信息传输效率低，常常出现沟通困难的情况。这导致交付内容一直处于变更状态，范围无法明确，双方陷入落地僵局，难以达成共识。
场景3：在售前阶段没有研发代表参与方案和成本评估，导致后期开发周期紧张。起初项目计划书中，产品和研发团队都处于空白状态，付出和收益存在较大差距。
措施建议：

首先要确认双方的实际负责人，并授权他们能够直接进行决策和验收工作，共同推动各自的工作安排。
仅做好自己边界内的定制，对于边界外的需求应寻找成熟的产品，只需关注好接口即可；若市场上无合适产品，应尽可能地找第三方系统集成商进行定制开发。
应该将整个交付流程透明化和标准化，让所有参与者参与项目计划表的制定、确认何时可以提供支持以及在项目中需要完成的任务。这样客户和内部团队都能了解交付目标。
要进行准备工作，包括数据指标的定义、需求边界和预估研发时间等，并提高商务能力以便更合理地报价。这能让客户感到服务更周到，物有所值，也能让内部成员更有方向。
需公布初步计划表给客户和内部成员，并且允许有一定的变动。如果出现计划变动，双方应提前告知风险并采取改进措施。例如，如果客户的业务开展时间提前，需要提前研发时间；如果原定产研成员离职，需要新成员加入时不需要从头再做方案的调研。

二、售中交付阶段

在售中阶段，我们需要为X公司的Y项目提供完整且明确的方案。我们需要详细地解释方案涉及的技术、流程和时间，并确保X公司全程了解进度和风险。

在实施过程中，我们需要及时与X公司沟通可能出现的问题，并尽可能地解决这些问题，确保项目顺利完成。

1. 可以萃取好的几点经验

经验1：坚持做好过程管理，保证客户、研发和内部其他团队的信息一致。

具体几个方面需要考虑：

有条件可以安排人员去相应的城市共同工作，驻场时一定要与客户进行充分沟通，透彻了解项目，提前确定项目的风险并及时反馈给公司；
拉通需求所有相关参与者进行需求的对接，共同梳理出业务流程图。
以客户的关注点产出最终的方案，包含：能不能技术实现？具体的产品方案是否符合预期？工期多长，什么时候可以交付？是否有客户协同解决的问题？
多花时间与负责人进行细节讨论，所有需要进行系统变更的点都要与客户进行完全确认，保证结果被认可。哪怕4个方案最好的是选择方案1，也需要把4个方案和最佳推荐给客户自己做选择。
最终结果必须以邮件确认，再进入后续的开发，到规定时间主动反馈结果，遇到问题最好与问题提出者沟通。
技术团队需要输出有详细的数仓设计方案，在后台的数据配置和问题排查上有很大的帮助。
将所有的材料进行分类管理。前期放进共享文件夹，后续挪到知识库，包含所有文件（除X公司实际的数据文件），保证所有人可阅读，也知道变更情况。
服务期间，仍然需要多主动去找实际使用的人问使用中有没有遇到问题。

我们忽略的地方可能是导致用不起来的细节，要站在他的角度考虑，理解客户听下他有什么好的办法。在他的基础上思考更多的方案供选择。

经验2：解决问题是首要，但也要考虑解决客户情绪问题，共同改进合作方式。

具体几个方面需要考虑：