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

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

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

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

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

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

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

第二個問題：“如何才能做好SaaS產(chǎn)品？” ——這是今天想分享的內(nèi)容，主要是分享五條經(jīng)驗教訓(xùn)。

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

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

SaaS產(chǎn)品核心是提供標準化服務(wù)，規(guī)?；鉀Q客戶群的共性需求。

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

以通用型HR SaaS產(chǎn)品為例。

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

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

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

第二是管理理念差異。

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

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

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

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

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

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

“如何有效解決個性化需求”成為了做好SaaS產(chǎn)品的關(guān)鍵。

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

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

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

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

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

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

舉個例子。

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

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

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

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

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

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

經(jīng)驗2：產(chǎn)品功能設(shè)計之初，全面進行抽象化設(shè)計

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

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

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

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

舉個例子。

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

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

當(dāng)時，面臨兩個不同的解決方案：

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

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

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

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

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

經(jīng)驗3：關(guān)鍵功能的設(shè)計，最好在初始時就支持自定義

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

以報表為例。

一般會有兩種方案：

• 方案1：內(nèi)置“所有”報表，但不支持自定義字段、列表順序、顯隱設(shè)置等。比如內(nèi)置日統(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：內(nèi)置關(guān)鍵報表，但支持自定義報表、字段，以及自定義列表顯示順序以及字段顯隱等。比如內(nèi)置日統(tǒng)計表、日明細表、月統(tǒng)計表，同時支持按對應(yīng)三種類型自定義報表（可選所有出勤類、加班類、補貼類、扣款類、外勤類字段），以及允許自定義字段與顯示順序等。

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

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

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

比如：

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

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

經(jīng)驗4：用戶端的功能，最好設(shè)計初始時就支持配置化

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

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

我們經(jīng)常會遇到類似的問題：

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

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

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

經(jīng)驗5：用戶關(guān)鍵操作全部留痕，并外化給用戶

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

比如：

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

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

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

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