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

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

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

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

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

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

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

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

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

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

主要原因如下：

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

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

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

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

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

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

（3）无法传递价值。

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

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

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

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

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

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

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

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

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

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

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

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

一、售前打单阶段

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

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

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

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

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

二、售中交付阶段

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

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

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

具体几个方面需要考虑：

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

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

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

具体几个方面需要考虑：

1. 不轻易承诺。在承诺前，进行充分的调研并评估项目的可行性，以免给客户带来误解和不必要的麻烦；
2. 让客户成为产品研发的一员，积极地让其参与整个项目的流程及决策，确保双方对产品方案及交付时间有着相同的认知；
3. 保持一颗耐心和尊重的心态，让他愿意找你。
4. 并在客户提出问题后，了解透彻其痛点所在，积极地尝试理解客户需求，并及时回应客户提出的问题，保持与客户的紧密沟通，共同解决问题。没有必要争输赢，因为不是辩论赛。
5. 建立良好的沟通平台与文化，鼓励和欢迎客户对我们的业务和产品提出建议和意见。

用谦虚、开放的心态去接受客户的建议，将其转化为促进业务发展的机遇。以上维护客户关系的措施，有利于建立良好的客户关系和提升客户满意度。

同时，也需要时刻注意客户需求的推移，以便及时做出调整，为客户提供更好的服务和满足更多的需求。

• 场景1：产研按时在6月底完成项目的开发，但是交付时间延长1个多月，主要是测试时间比较长，在数据指标的验收上经验不足。
• 场景2：没有清晰的项目空间进行管理，当时在JIRA的数晓晓空间管理，有顾家和X公司2个项目。不好进行看板的搭建，解决问题的进度不好跟踪，后期在结果验证环节有点混乱。

措施建议：

（1）加强数据产品设计的知识，并及时分享内部经验。

例如，在数据产品设计过程中，要进行数据指标的定义，可以按照什么模式更好的理解和使用。应该对数据产品如何设计、如何利用组件和工具进行分析和处理进行培训和分享。

参考其他人在做数据项目方面有丰富的经验。

同时，也可以将SQL以及其他技术课程与实际案例相结合，让团队成员更清晰地了解技术知识的实际应用场景和解决方案。

（2）为数据项目安排测试人员，质量同样重要。

在测试过程中，应该及时发现和解决问题，始终保持对客户的信任。同时，在测试人员对数据产品进行测试时，应该对测试内容进行充分有效的沟通，定期向团队负责人通报测试进度和结果，让整个团队高度重视测试的结果和检查。

（3）有单独的项目空间和看板，开放给内部的所有参与者，方便协同工作。

可以为项目设立独立的空间和看板，方便团队成员及时查看和更新项目的进展和问题，起到更好的协同作用。

（4）建立所有在银河进行查询的SQL共享空间，方便所有人快速排查数据问题。

建立查询SQL共享空间，有效降低相同问题的重复查询，推进数据问题快速解决，提高团队工作效率。

（5）提前熟悉和会使用公司内部的公开产品和组件。

例如低代码平台，这可以提高数据产品设计和实现的效率，缩短研发周期，更好地支持客户的需求。应该积极主动地熟悉和学习公司内部的公开产品和组件，并在后续的项目中更好地应用。

三、售后服务维护阶段

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

• 场景1：售后保障方案是后期临时加上的，并且是客户强烈要求才做的；
• 场景2：按照新的售后方案对以前出错情况进行定义和分类处理，要算入费用中。倒推比较耗时间。

建议：

（1）在项目报价环节，应该将售后保障方案纳入规范。

不是必要的可以规避掉，让客户清晰了解相应的费用与服务，避免在后期客户强烈要求下，临时进行售后保障方案的添加，影响项目的进展。

（2）在项目的开展和维护过程中，应该将问题池整理归纳好，并及时进行追踪和解决。

不同类型的问题应该有不同的解决方案，可以通过专门的流程来定性化地处理。在这个过程中，需要将具体细节的问题汇总到需求池中，进行统一管理。

本文由 @萌沐 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。