在當今數(shù)字化轉型浪潮中，SaaS（軟件即服務）產品已成為企業(yè)運營的重要工具。然而，做好SaaS產品并非易事，尤其是面對不同行業(yè)、不同規(guī)模客戶的多樣化需求時，如何在標準化服務與個性化需求之間找到平衡，是每個SaaS產品經理必須面對的挑戰(zhàn)。

2022年進入SaaS行業(yè)時，第三面的招聘HR問我：“為什么要從教育產品轉向SaaS產品？”

我回答道：“SaaS產品是面向不同行業(yè)的不同客戶，對產品經理的抽象能力有一定要求，而這是B端產品最重要的能力，我期望進一步提升這種能力?！?/p>

3年過去了，雖然答案沒變（即堅信抽象能力是做好SaaS產品的關鍵能力），但問題變了。

作為一名SaaS行業(yè)的“過來人”，分享三個相關問題的看法，讓你對SaaS產品經理有更進一步的了解。

第一個問題：“是否還要進入SaaS行業(yè)？”——俗話說“男怕入錯行，女怕嫁錯郎”。

上次分享是否進入SaaS產品？寫給傳統(tǒng)企業(yè)主的四點建議時，已經從市場空間、成本、人才結構、產品架構四個方面，分享了對這個問題的看法，不再贅述。

第二個問題：“如何才能做好SaaS產品？” ——這是今天想分享的內容，主要是分享五條經驗教訓。

第三個問題：“如何落地AI應用？看看HR SaaS產品的答案”——提前預告，下次分享，主要是分享AI在HR SaaS行業(yè)里的真實落地情況。

SaaS“致命傷”——個性化需求

SaaS產品核心是提供標準化服務，規(guī)模化解決客戶群的共性需求。

這是理想結果，現(xiàn)實是不同行業(yè)、不同階段、不同規(guī)模、不同管理理念、不同風險偏好等，導致出現(xiàn)大批量的個性化需求，無法有效解決，影響最終的服務滿意度與續(xù)簽率。

以通用型HR SaaS產品為例。

它面向企業(yè)提供通用化的人力資源管理解決方案，包含人才管理、組織人效、招聘、績效、考勤、薪酬個稅、培訓、數(shù)據等模塊。

首先是行業(yè)差異。

比如同樣是排班跟加班，制造業(yè)和餐飲業(yè)需求差異明顯。制造業(yè)通常需要周期性的白夜班、大夜班連班以及班后自動加班，而餐飲業(yè)則更傾向于每天靈活排班和調班，且通常不允許加班。

第二是管理理念差異。

比如同樣是制造業(yè)企業(yè)的客戶A和客戶B，面對同樣的政策，由于管理理念不同，對加班時長控制和結轉的做法大相徑庭。

• 客戶A嚴格限制加班時長，確保不超法規(guī)上限。即每月加班時長不超36小時，工作日加班不超3小時，公休日/節(jié)假日加班不超11小時；
• 客戶B則不限制每月加班時長，但通過固定結轉36小時加班費，優(yōu)先使用1.5倍工作日加班費，保留2倍公休日加班費，鼓勵員工調休消耗，以此來節(jié)省成本。

第三是企業(yè)階段差異。

比如同樣是互聯(lián)網行業(yè)的客戶A和客戶B，因企業(yè)階段不同，導致對年假發(fā)放/使用規(guī)則差異非常大。

• 客戶A，作為上市企業(yè)，除依法執(zhí)行年假規(guī)定外，還根據司齡額外發(fā)放福利年假。嚴格按法律規(guī)定執(zhí)行的情況下，還會根據司齡的不同，每年單獨給員工新增發(fā)放福利年假（1-10天不等）；
• 客戶B，作為成長期企業(yè)，統(tǒng)一每年5天年假，司齡超過5年后逐年增加，上限為10天/年。

結果是某個模塊的需求池里，待解決需求常年在5000條左右的狀態(tài)，而這些需求呈現(xiàn)非常明細的離散性（即需求無共性）。

“如何有效解決個性化需求”成為了做好SaaS產品的關鍵。

分享五條相關經驗，希望對你有所啟發(fā)。

經驗1：立項之初，提前規(guī)劃并設計個性需求解決方案

過去幾年，我們看到太多國內的SaaS廠商，為了追求市場占有率，采取快速推進研發(fā)的方式。

導致出現(xiàn)兩類常見問題：

第一類是頻繁重構。前期追求快速研發(fā)，架構設計不合理，導致企業(yè)進入成長關鍵階段后，不得不重構系統(tǒng)。每次重構約需1年，造成需求空窗期，這是追求速度的“代價”；

第二類是個性化解決方案成本高。企業(yè)成熟后，客戶體量增大，市場競爭加劇，解決個性化需求成為難題。因前期欠考慮，研發(fā)成本翻倍，且解決方案常需妥協(xié)，與完美方案有差距。

舉個例子。

SaaS企業(yè)A早期專注于通用型SaaS產品迭代，未考慮PaaS、插件平臺或低代碼建設。進入成熟期后，面臨客戶個性需求堆積和產研資源有限的問題，重新設計產品架構的成本，至少是立項初的2倍以上。

目前經過半年的建設，其插件平臺仍僅限內部使用，未能實現(xiàn)共享外部產研資源的目的。同時，其功能與適用范圍受限于現(xiàn)有SaaS產品架構，難以達到理想的技術與產品架構。

俗話說：“磨刀不誤砍柴工”，這是亙古不變的道理。

因此，在SaaS產品立項之初，必須深思熟慮：隨著企業(yè)成長，個性化需求問題不可避免，我們應該采取什么樣的解決方案，必須提前進行架構設計。

如果目標客群是中大型企業(yè)，則SaaS+PaaS的產品架構，可能是立項之初，可以考慮的架構設計；

如果目標客群是中小企業(yè)，則SaaS+低代碼平臺或插件平臺的架構，可能是立項之初，可以考慮的架構設計。

經驗2：產品功能設計之初，全面進行抽象化設計

有時，我們迫于某個客戶的簽約壓力，追求快速實現(xiàn)客戶需求，不得不采取一些折中方案。

結果，功能上線后，更多客戶開始使用，延伸問題頻發(fā)，不得二次迭代（甚至重構）。

原因，“欲速則不達”，過于追求當下解決問題的速度，放棄了長遠的價值思考。

所以，在產品功能設計之初，最好追求全局最優(yōu)設計，而不僅是局部最優(yōu)。

舉個例子。

加班屬于制造業(yè)員工的常態(tài)需求，其中一個場景是：因生產任務緊急，班組長需要按需安排員工加班。比如周一至周五白班08:00-17:00（正常上班），周六安排白班加班08:00-17:00（補償2倍工資）。

在項目立項之初，承諾了其中一家新簽客戶，必須在2023年3月底之前上線。

當時，面臨兩個不同的解決方案：

• 方案1：單獨新增一種班次（即加班班次），它區(qū)別于正常班次，只根據打卡統(tǒng)計加班時長，不會計算員工遲到、早退、曠工等異常，不出勤也無需請假，預計投入1.5月；
• 方案2：僅新增一種班次類型，本質與正常班次一致。即可根據打卡統(tǒng)計加班時長的同時，支持用戶自定義，是否計算員工遲到、早退、曠工以及請假，預計投入3個月。

為了“節(jié)省”了1.5個月時間，以及履行對新簽客戶的承諾，選擇了看似“最合理”的方案1。

當后續(xù)客戶安排加班時，期望正常計算遲到、早退、曠工異常時，必須重構——所需投入的時間，甚至超過當初的3個月——必須兼容現(xiàn)有邏輯，避免影響已有客戶的使用。

這就是“臨時方案”的代價，“貪小便宜”而吃了“啞巴虧”。

如何全面設計與落地，可參考如何在入職1周內，輸出產品規(guī)劃？

經驗3：關鍵功能的設計，最好在初始時就支持自定義

報表、列表、工作臺屬于SaaS產品的標準化功能，如果設計之初，因為工期等原因而選擇標準化方案，不提供“千人千面”的自定義能力，那就是在給自己“埋坑”——除非你不想在公司久待。

以報表為例。

一般會有兩種方案：

• 方案1：內置“所有”報表，但不支持自定義字段、列表順序、顯隱設置等。比如內置日統(tǒng)計表、月統(tǒng)計表（含出勤統(tǒng)計表、加班統(tǒng)計表、補貼統(tǒng)計表、扣款統(tǒng)計表、外勤統(tǒng)計表、工時統(tǒng)計表、每日出勤統(tǒng)計表等）、年統(tǒng)計表（含假期余額表、請假統(tǒng)計表等）、加班統(tǒng)計表等。
• 方案2：內置關鍵報表，但支持自定義報表、字段，以及自定義列表顯示順序以及字段顯隱等。比如內置日統(tǒng)計表、日明細表、月統(tǒng)計表，同時支持按對應三種類型自定義報表（可選所有出勤類、加班類、補貼類、扣款類、外勤類字段），以及允許自定義字段與顯示順序等。

我們曾經追求快速上線，選擇了方案1，大概花了1.5個月時間支持了日報、月報，后面陸陸續(xù)續(xù)又花了1個多月，才完成了內置“所有”報表的工作。

上線后的2年內，基本都可解決大部分客戶的報表類訴求.

可當進入第5年后，報表定制類的需求成為了“客戶的痛點”——客戶認為的基礎功能，而你卻不能提供。

比如：

• 有人覺得內置報表以及字段太多，很多用不到，每次查看/導出都是干擾；
• 有人覺得內置字段的定義，跟客戶需求不匹配，無法實現(xiàn)重新定義；
• 有人想要每天出勤明細表，而不僅僅是每日/月的統(tǒng)計；
• 有人覺得報表都是統(tǒng)計類或明細類，實際需要每月統(tǒng)計和每日出勤明細表是可以組合在同一張報表；
• 有人需要每周的統(tǒng)計表，而不一定是每日/每月/每年；
• 等等。

當我們想迭代時，發(fā)現(xiàn)基于現(xiàn)有的產品和技術架構，必然需要重構，且現(xiàn)有用戶量非常大，考慮兼容的話，所需花費的成本，將比立項之初高2-3倍（即半年以上）；

經驗4：用戶端的功能，最好設計初始時就支持配置化

SaaS產品面向兩類人：客戶、用戶。用戶又可分為管理員、員工等角色。

當我們在給用戶（尤其是員工類角色）設計產品時，最好是做成可配置化，否則可能會帶來各種意想不到的客訴問題。

我們經常會遇到類似的問題：

• “是否可以僅顯示員工的上班打卡，而隱藏下班打卡時間，避免員工知道自己的真實上班時長？”
• “是否可隱藏年假的周期？或只顯示年假余額，而不顯示調休假余額？”
• “是否可按小時顯示年假余額，而不是按天？”
• “是否可隱藏請假審批，今年所請假的總天數(shù)？或不按自然年統(tǒng)計天數(shù)？”
• “是否可以在員工確認工資條后，自動隱藏，不讓后續(xù)再查看，避免后續(xù)可能的糾紛？”
• “是否可控制員工打卡時，必須拍照，避免員工不在辦公區(qū)打卡，而是在樓下？”
• “是否可自定義提醒打卡時間？以及僅支持某個端口打卡？”
• “是否可自定義模塊的名稱？不要叫“獎金提成”或“工資條”？”
• 等等。

不同管理員對期望可自定義控制的內容，千奇百怪。唯一可以做的就是：盡可能確保與員工相關的元素，均可自定義控制顯示/隱藏、名稱等。

如果我們在每個設計之初不考慮，后續(xù)就只能采取“半妥協(xié)式”方案。

經驗5：用戶關鍵操作全部留痕，并外化給用戶

我們每年會有近6000條客訴問題，其中超過30%以上都是規(guī)則確認、數(shù)據不一致等導致。

比如：

• “加班規(guī)則是按0.5小時的倍數(shù)進行取舍，結果卻有員工加班時長是2.89小時？”——原因是先加班后修改規(guī)則導致不生效；
• “張三請了3天假期，為什么只扣了2天年假？”——原因是管理員改動了排班，將其中一天修改為休息；
• “為什么李四的年假余額被人調整過，麻煩查詢下是誰操作的？”——原因是管理員A調整后，管理員B有疑問。
• “張三的調整年假和調整婚假都有值，實際不應該有值的，麻煩看下是誰修改的？”——原因同上
• “李四10月01日有法節(jié)加班記錄，而他并沒有申請加班，是什么原因？”——原因是管理員安排了加班，生成加班記錄后，又把排班取消了。
• 等等。

SaaS產品面向的是多客戶、多用戶的模式，每個人的操作可能都會對數(shù)據結果產生影響。

如果我們想確保后續(xù)溯源的高效且精準，則在產品功能設計之初，必須進行詳細的操作記錄、日志明細等設計。

否則，功能上線后，所帶來查詢類的客訴問題，將會占據大量的產研成本。