五条经验告诉你做好SaaS产品

SaaS（软件即服务）产品作为企业运营的重要工具，一直以来在企业中扮演着重要角色，但是要想做好一款合格的SaaS产品并非易事，尤其是面对不同行业、不同规模客户的多样化需求时，如何在标准化服务与个性化需求之间找到平衡，是每个SaaS产品经理必须面对的挑战。下面小编结合自己在这个行业多年的经验给大家一起分享下成功的SaaS产品五大经验，感兴趣的朋友可以关注下。

2022年进入SaaS行业时，第三面的招聘HR问我：“为什么要从教育产品转向SaaS产品？”

我回答道：“SaaS产品是面向不同行业的不同客户，对产品经理的抽象能力有一定要求，而这是B端产品最重要的能力，我期望进一步提升这种能力。”

3年过去了，虽然答案没变（即坚信抽象能力是做好SaaS产品的关键能力），但问题变了。

作为一名SaaS行业的“过来人”，分享三个相关问题的看法，让你对SaaS产品经理有更进一步的了解。

第一个问题：“是否还要进入SaaS行业？”——俗话说“男怕入错行，女怕嫁错郎”。

上次分享是否进入SaaS产品？写给传统企业主的四点建议时，已经从市场空间、成本、人才结构、产品架构四个方面，分享了对这个问题的看法，不再赘述。

第二个问题：“如何才能做好SaaS产品？” ——这是今天想分享的内容，主要是分享五条经验教训。

第三个问题：“如何落地AI应用？看看HR SaaS产品的答案”——提前预告，下次分享，主要是分享AI在HR SaaS行业里的真实落地情况。

SaaS“致命伤”——个性化需求

SaaS产品核心是提供标准化服务，规模化解决客户群的共性需求。

这是理想结果，现实是不同行业、不同阶段、不同规模、不同管理理念、不同风险偏好等，导致出现大批量的个性化需求，无法有效解决，影响最终的服务满意度与续签率。

以通用型HR SaaS产品为例。

它面向企业提供通用化的人力资源管理解决方案，包含人才管理、组织人效、招聘、绩效、考勤、薪酬个税、培训、数据等模块。

首先是行业差异。

比如同样是排班跟加班，制造业和餐饮业需求差异明显。制造业通常需要周期性的白夜班、大夜班连班以及班后自动加班，而餐饮业则更倾向于每天灵活排班和调班，且通常不允许加班。

第二是管理理念差异。

比如同样是制造业企业的客户A和客户B，面对同样的政策，由于管理理念不同，对加班时长控制和结转的做法大相径庭。

• 客户A严格限制加班时长，确保不超法规上限。即每月加班时长不超36小时，工作日加班不超3小时，公休日/节假日加班不超11小时；
• 客户B则不限制每月加班时长，但通过固定结转36小时加班费，优先使用1.5倍工作日加班费，保留2倍公休日加班费，鼓励员工调休消耗，以此来节省成本。

第三是企业阶段差异。

比如同样是互联网行业的客户A和客户B，因企业阶段不同，导致对年假发放/使用规则差异非常大。

• 客户A，作为上市企业，除依法执行年假规定外，还根据司龄额外发放福利年假。严格按法律规定执行的情况下，还会根据司龄的不同，每年单独给员工新增发放福利年假（1-10天不等）；
• 客户B，作为成长期企业，统一每年5天年假，司龄超过5年后逐年增加，上限为10天/年。

结果是某个模块的需求池里，待解决需求常年在5000条左右的状态，而这些需求呈现非常明细的离散性（即需求无共性）。

“如何有效解决个性化需求”成为了做好SaaS产品的关键。

分享五条相关经验，希望对你有所启发。

经验1：立项之初，提前规划并设计个性需求解决方案

过去几年，我们看到太多国内的SaaS厂商，为了追求市场占有率，采取快速推进研发的方式。

导致出现两类常见问题：

第一类是频繁重构。前期追求快速研发，架构设计不合理，导致企业进入成长关键阶段后，不得不重构系统。每次重构约需1年，造成需求空窗期，这是追求速度的“代价”；

第二类是个性化解决方案成本高。企业成熟后，客户体量增大，市场竞争加剧，解决个性化需求成为难题。因前期欠考虑，研发成本翻倍，且解决方案常需妥协，与完美方案有差距。

举个例子。

SaaS企业A早期专注于通用型SaaS产品迭代，未考虑PaaS、插件平台或低代码建设。进入成熟期后，面临客户个性需求堆积和产研资源有限的问题，重新设计产品架构的成本，至少是立项初的2倍以上。

目前经过半年的建设，其插件平台仍仅限内部使用，未能实现共享外部产研资源的目的。同时，其功能与适用范围受限于现有SaaS产品架构，难以达到理想的技术与产品架构。

俗话说：“磨刀不误砍柴工”，这是亘古不变的道理。

因此，在SaaS产品立项之初，必须深思熟虑：随着企业成长，个性化需求问题不可避免，我们应该采取什么样的解决方案，必须提前进行架构设计。

如果目标客群是中大型企业，则SaaS+PaaS的产品架构，可能是立项之初，可以考虑的架构设计；

如果目标客群是中小企业，则SaaS+低代码平台或插件平台的架构，可能是立项之初，可以考虑的架构设计。

经验2：产品功能设计之初，全面进行抽象化设计

有时，我们迫于某个客户的签约压力，追求快速实现客户需求，不得不采取一些折中方案。

结果，功能上线后，更多客户开始使用，延伸问题频发，不得二次迭代（甚至重构）。

原因，“欲速则不达”，过于追求当下解决问题的速度，放弃了长远的价值思考。

所以，在产品功能设计之初，最好追求全局最优设计，而不仅是局部最优。

举个例子。

加班属于制造业员工的常态需求，其中一个场景是：因生产任务紧急，班组长需要按需安排员工加班。比如周一至周五白班08:00-17:00（正常上班），周六安排白班加班08:00-17:00（补偿2倍工资）。

在项目立项之初，承诺了其中一家新签客户，必须在2023年3月底之前上线。

当时，面临两个不同的解决方案：

• 方案1：单独新增一种班次（即加班班次），它区别于正常班次，只根据打卡统计加班时长，不会计算员工迟到、早退、旷工等异常，不出勤也无需请假，预计投入1.5月；
• 方案2：仅新增一种班次类型，本质与正常班次一致。即可根据打卡统计加班时长的同时，支持用户自定义，是否计算员工迟到、早退、旷工以及请假，预计投入3个月。

为了“节省”了1.5个月时间，以及履行对新签客户的承诺，选择了看似“最合理”的方案1。

当后续客户安排加班时，期望正常计算迟到、早退、旷工异常时，必须重构——所需投入的时间，甚至超过当初的3个月——必须兼容现有逻辑，避免影响已有客户的使用。

这就是“临时方案”的代价，“贪小便宜”而吃了“哑巴亏”。

如何全面设计与落地，可参考如何在入职1周内，输出产品规划？

经验3：关键功能的设计，最好在初始时就支持自定义

报表、列表、工作台属于SaaS产品的标准化功能，如果设计之初，因为工期等原因而选择标准化方案，不提供“千人千面”的自定义能力，那就是在给自己“埋坑”——除非你不想在公司久待。

以报表为例。

一般会有两种方案：

• 方案1：内置“所有”报表，但不支持自定义字段、列表顺序、显隐设置等。比如内置日统计表、月统计表（含出勤统计表、加班统计表、补贴统计表、扣款统计表、外勤统计表、工时统计表、每日出勤统计表等）、年统计表（含假期余额表、请假统计表等）、加班统计表等。
• 方案2：内置关键报表，但支持自定义报表、字段，以及自定义列表显示顺序以及字段显隐等。比如内置日统计表、日明细表、月统计表，同时支持按对应三种类型自定义报表（可选所有出勤类、加班类、补贴类、扣款类、外勤类字段），以及允许自定义字段与显示顺序等。

我们曾经追求快速上线，选择了方案1，大概花了1.5个月时间支持了日报、月报，后面陆陆续续又花了1个多月，才完成了内置“所有”报表的工作。

上线后的2年内，基本都可解决大部分客户的报表类诉求.

可当进入第5年后，报表定制类的需求成为了“客户的痛点”——客户认为的基础功能，而你却不能提供。

比如：

• 有人觉得内置报表以及字段太多，很多用不到，每次查看/导出都是干扰；
• 有人觉得内置字段的定义，跟客户需求不匹配，无法实现重新定义；
• 有人想要每天出勤明细表，而不仅仅是每日/月的统计；
• 有人觉得报表都是统计类或明细类，实际需要每月统计和每日出勤明细表是可以组合在同一张报表；
• 有人需要每周的统计表，而不一定是每日/每月/每年；
• 等等。

当我们想迭代时，发现基于现有的产品和技术架构，必然需要重构，且现有用户量非常大，考虑兼容的话，所需花费的成本，将比立项之初高2-3倍（即半年以上）；

经验4：用户端的功能，最好设计初始时就支持配置化

SaaS产品面向两类人：客户、用户。用户又可分为管理员、员工等角色。

当我们在给用户（尤其是员工类角色）设计产品时，最好是做成可配置化，否则可能会带来各种意想不到的客诉问题。

我们经常会遇到类似的问题：

• “是否可以仅显示员工的上班打卡，而隐藏下班打卡时间，避免员工知道自己的真实上班时长？”
• “是否可隐藏年假的周期？或只显示年假余额，而不显示调休假余额？”
• “是否可按小时显示年假余额，而不是按天？”
• “是否可隐藏请假审批，今年所请假的总天数？或不按自然年统计天数？”
• “是否可以在员工确认工资条后，自动隐藏，不让后续再查看，避免后续可能的纠纷？”
• “是否可控制员工打卡时，必须拍照，避免员工不在办公区打卡，而是在楼下？”
• “是否可自定义提醒打卡时间？以及仅支持某个端口打卡？”
• “是否可自定义模块的名称？不要叫“奖金提成”或“工资条”？”
• 等等。

不同管理员对期望可自定义控制的内容，千奇百怪。唯一可以做的就是：尽可能确保与员工相关的元素，均可自定义控制显示/隐藏、名称等。

如果我们在每个设计之初不考虑，后续就只能采取“半妥协式”方案。

经验5：用户关键操作全部留痕，并外化给用户

我们每年会有近6000条客诉问题，其中超过30%以上都是规则确认、数据不一致等导致。

比如：

• “加班规则是按0.5小时的倍数进行取舍，结果却有员工加班时长是2.89小时？”——原因是先加班后修改规则导致不生效；
• “张三请了3天假期，为什么只扣了2天年假？”——原因是管理员改动了排班，将其中一天修改为休息；
• “为什么李四的年假余额被人调整过，麻烦查询下是谁操作的？”——原因是管理员A调整后，管理员B有疑问。
• “张三的调整年假和调整婚假都有值，实际不应该有值的，麻烦看下是谁修改的？”——原因同上
• “李四10月01日有法节加班记录，而他并没有申请加班，是什么原因？”——原因是管理员安排了加班，生成加班记录后，又把排班取消了。
• 等等。

SaaS产品面向的是多客户、多用户的模式，每个人的操作可能都会对数据结果产生影响。

如果我们想确保后续溯源的高效且精准，则在产品功能设计之初，必须进行详细的操作记录、日志明细等设计。

否则，功能上线后，所带来查询类的客诉问题，将会占据大量的产研成本。