編輯導語：對SaaS企業服務來說，“標準化”可以理解為“領域 群體 環境 業務目標”之下的平均的可接受的作業規范和條件。本篇文章梳理了SaaS產品中解決個性化、加固標準化的方法，幫助產品更好地發展，一起來看。

一、怎么理解“標準化”？

標準化是個相對性的概念。針對SaaS企業服務來說，“標準化”可以理解為“領域 群體 環境 業務目標”之下的平均的可接受的作業規范和條件。

這些規范和條件包括組織架構、人員角色、操作流程、數據儲備、作業效率等。

倘若把“領域”從鞋業換到房地產行業，“群體”從山寨作坊換到品牌廠商，那么規范和條件自然就不同。

站在SaaS產品角度，產品的標準化，依賴于行業標準化。這些標準化要素可以分為兩類：業務標準化和客戶標準化。

1. 業務標準化

業務標準化程度，存在進程和地區上差異性。

宏觀層面，國際標準化組織ISO（International Organization for Standardization）負責當今世界上絕大部分領域的標準化活動，內容涉及信息技術、交通運輸、農業、保健和環境等，每個工作機構都有自己的工作計劃，該計劃列出需要制訂的標準項目（試驗方法、術語、規格、性能要求等），ISO已經發布了17000多個國際標準。

相對宏觀層面而言，微觀層面的標準化更加接近客戶需求本身，對產品規劃的意義更大。

比如客戶企業內部的SOP類的文件和制度、區域性企業之間的“效仿”等，都能更直接地有助于標準化的形成。

國內企業之間的行業標準化程度低的原因之一，是發展的快的企業組織變革頻繁，而效仿者很難保持同樣的節奏。

通過行業標準峰會或委員會等組織，有助于行業圈的規范化和共同提升，但這是一項存在“愿志愿者困境（The Volunteer’s Dilemma）”的行為。

因為一旦標準推行成功，受益的是大家，但推動者的付出與其收益之間不成比例。因此靠一定的“奉獻”精神支撐。

標準化程度低，導致需求本身在大環境下穩定性就不好。加上契約精神缺失，甲方到上線前還要求改這改那，需求風險太不可控。

2. 客戶標準化

客戶標準化主要體現在不同企業的發展時間、企業規模、管理風格、企業效益、信息化、數字化程度要求的不同，必然導致公司成員的工作習慣、整體素質、培訓能力、管理制度等方面的參差不齊。

企業作為SaaS產品的客戶，有著不同的規范偏好；企業的成員作為SaaS產品的用戶的時候，自然就產生了個體之間的差異。所提出的訴求自然有所差異。

二、加固產品標準化

如何讓標準化產品篤定持久，是SaaS產品的理想之一。

回到源頭，需求從哪里來，就重新回歸到哪里去。

筆者過去的工作經驗中，提煉出如下幾種加固標準化需求和產品的方式。

1. 產品共建與業務共建

尤其是垂直行業的SaaS服務商，單靠拜訪客戶、接聽回訪電話是遠遠不夠。甚至只會收集到一些干擾視線的偽需求。

要更加深入理解客戶的場景，方法之一是與客戶共生，比如孵化客戶：以合作的模式與部分客戶一并開展業務，互利互惠，形成利益共同體。不僅在產品上實現共建，而且在業務上一起成長。

作為服務商，以實踐為契機，以盈利的二次分配為造血、以痛點為需求源、以契約關系鍛煉供需邏輯，將收費、場景、價值，拉近了進行打造。

2. 與標桿客戶戰略合作

如何將標桿客戶和SaaS產品綁定在一起，共同把這艘SaaS大船開好，而不是淺表層面的租用軟件關系呢？

其中一本辦法就是尋求戰略合作。

曾經做過一個平安的項目：SaaS服務方幫助平安的某片區打造600家本地標桿前置倉庫，平安方幫助推廣自己的客戶五年內使用這套SaaS軟件，并提供融資合作。

這樣的好處是綁定利益共同體，增加抗風險的能力；另一方面可以讓客戶更加深入地提供產品顧問作用。

3. 單點突破

多年之后，大家所熟知的瑞士軍刀，通常是下圖這種多功能的：

但誰想到這是多年迭代后的結果，真正的瑞士軍刀其實很單純，就是下圖這種直男，它定位明確（堅硬耐用）。

也就是這種單一的功能產品，是他在多個國家的軍隊和民間廣受好評，并成為多個國家采購的軍刀。后來才衍生出多中用途的多功能軍刀。

類比于SaaS產品，也可以借鑒這種單點突破的經驗。

一方面，單點突破，是產品找到突破口的最短路線，有助于快速構建基本產品體系，優先搶占需求單一的中小客戶，完成SaaS產品生命周期的起步階段。

另一方面，單點功能一定是非做不可的，不太可能出現差異化，能被廣大用戶接受，所以一定是標準需求范疇的內容。

三、識別個性化需求

1. 個性化需求主要有這幾種常見的特征

（1）不切合實際

舉一個例子，有客戶用慣了本地版的系統，換成SaaS版之后，仍要求一次加載2000條列表數據。

因為SaaS是B/S架構的，數據都存儲在云端服務器上，每一條數據都是通過網絡請求后獲取的。

很難和C/S結構下本地數據的訪問量和速度相提并論。所以大量的數據，很容易造成瀏覽器負荷超載而直接崩掉。

那么怎么辦呢？

筆者的觀點是不直接做，而是重新回歸到他這個訴求的原點：展示2000條打算干什么？解決什么訴求……然后重新給他新的解決辦法。

比如他要對比，那么是否可以提供導出功能；他要計算，那么是否可以直接就算好輸出結果。

（2）ROI低

一般人家的正常公司，不看ROI都是耍流氓。除非家里有錢，就是要占著茅坑不讓任何人拉屎的那種公司除外。

“沒有實現不了的需求”這句話雖然不嚴謹，但是有時候產研不能為了試探技術的底線而不計代價做需求。

比如不能無限在這種小概率事件上投入過多成本。不僅包括當前開發和維護的成本，還包括產品日后的建設性受到不可預測的局限。

（3）違背產品的價值定位和理念

案例：某商戶新開發自己的App，但是沒有后臺，希望直接搭接服務商的中臺，管理他們的后臺。

理論上這是能實現的。但是即使給錢也不能做。因為一旦接了就意味著要兼顧兩側的業務，這將會導致整個產品中臺定位的坍塌。

（4）通用性差

個別客戶的、地區差異性的、時間階段性的需求，往往不能長期通用。

所以在調研需求的時候，橫向要調研更多客戶，縱向要考慮時間等因素是否會導致需求不持久。

2. 可接受的個性化場景

常見的可接受的個性化場景包括但不限于數據、界面、功能的個性化。

（1）數據個性化服務

在SaaS軟件中，需要提供數據個性化定制的功能來滿足不同租戶的數據需求。

（2）界面個性化

不同的客戶來自不同行業，不可能使用同一個系統LOGO以及系統名字。因此，在SaaS應用中，有必要解決界面個性化問題。

（3）功能個性化

客戶來自各行各業，有著不同的業務需求，系統的功能要與每一個客戶的需求相符是一件基本不可能的事情。

因此，SaaS軟件需要提供功能個性化定制的功能。

四、個性化需求的處理

個性化需求的處理永遠是與標準化對立統一進行處理的。對企業服務商來說

• 上策：標準版解決了差異需求；
• 中策：在保證標準的同時，用其余方式解決用戶的特異訴求；
• 下策：定制和標準二者保全一個。

常見的具體辦法如下：

1. 直接拒絕

每一個不合理的需求本身都有可能導致底層架構的不兼容，引入諸多風險因素。

如果產品只是走馬觀花地應付眼前的需求，最終會讓這個產品越走越艱難。

直接拒絕是一種“斷舍離”的做法，可能會失去一兩個客戶。

但從好的方面看，也是過濾非價值用戶，以及市場份額把握的手段。

2. 為用戶的個性需求定制開發

為客戶的個性需求，另行提供產品或團隊來解決，或者將該客戶進行項目化獨立開發。

比如在與一個大客戶的合作過程中，由于其獨特的業務模式和記賬方式，導致無法與通用版的相匹配。通用版的客戶根本用不到他的功能。

最終的解決辦法是就將該客戶的產品轉化為私有云部署，獨立開發。

3. 配置

配置說起來簡單，但是也不是好辦法。對大部分客戶而言還是增加了操作復雜度，對開發更是增加了多倍工作量。

最理想的SaaS產品是開箱即用的，而不是增加前置的配置工作。

配置包括套餐配置、數據配置、功能配置等，將會在專門章節具體介紹。

4. 灰度發布

在處理一個醫藥門店場景時遇到這樣的案例：

正常的流程是顧客可以通過線上B2C下快遞單，總部會從遠處的倉庫把貨物郵寄到客戶手里。

但是異常的場景式有客戶希望郵寄到附近的門店中，而不是顧客家里。并提供了如下理由：

• 有些藥品放在驛站，或者園區的快遞專柜，擔心溫度等條件影響；
• 藥店希望與客戶有更多接觸，以便增加線下的溫度；
• 物流公司減少菜鳥驛站你的看管費用；
• 提出訴求的顧客可能更順路、更順手。

于是邏輯就變為：

顧客下單——>選擇到店自提——>系統獲取門店地址作為收貨信息——>倉庫接單發貨——>郵寄到門店——>店員接收通知顧客到店自提。

這種功能具有小眾化，并且暗含了一些風險，比如系統獲取到的門店的收貨信息中電話是店員維護的，萬一他不在店怎么辦，門店保存的時候沒有專門的設備萬一紕漏怎么辦等。

這時候如果客戶執意要做，從產品角度來講，可以提供灰度的功能。若客戶能將其形成一種模式，那么就可以擴大化，并且從功能上做到更多的適配和支持。

5. 冷處理

如果你作為一個房屋設計師，智能居室的觸控位點設計在那幾個位置呢？

如圖所示。如果在交付之前就標準化一刀切設置，那么會發現這并不一定是用戶習慣的？

在工作一段時間之后才發現這種情況下讓用戶DIY更合適。或者干脆改用不局限位置的聲控、紅外感應等。

同樣做產品也是這樣，在沒有足夠樣本的情況下，很難一步到位，只能委屈求全做一些臨時過渡功能。

那么這就提示我們，某些需求可以冷處理一下，不要著急著做。即使要做也不要深做，做好統一重構的思想準備。

6. PaaS化

走到PaaS服務能力的公司畢竟是少數。這依賴于足夠的技術能力和資源，以及對高價值、高頻接口和應用的拿捏。

典型的例子是Saleforece，如圖所示，是艾瑞咨詢提供的資料，其按照“共性需求解耦化、通用能力平臺化”的思路，將分通用的部分從主體產品中解耦下來，以aPaaS的形式將其積木化。

并將通用的API以iPaaS的方式提供給外部。整合產業鏈上下游廠商等不斷豐富生態，顯著提升客戶粘性，不斷抬高公司營收與估值天花板。

其好處如圖所示，包括但不限于如下：

• 客戶需求：定制需求被滿足。
• 邊際效益：得到整體化的解決方案生態閉環,而非彼此獨立的CRM、ERP、 OA孤島。
• 第三方共贏：ISV開發商被開放API吸引，合作共贏。
• 服務商效益：增強其影響力與話語權,延長自身的服務鏈條。構建護城河！

總結

以上，個性化和標準化需求是相對的，并貫穿于任何產品研發的始終。

通常情況下，服務商會先將明確的部分標準化，然后滿足部分客戶的個性化需求，再逐步將這部分個性化需求標準化……如此一個循環過程。

另一方面，筆者認為合理的個性化需求更符合企業發展的現狀。

此外，只有重視客戶的每一個訴求，才有機會掌握市場動向。

總之，標準化與個性化的博弈，考察的是產品經理或高層長處著眼，短處著手的能力。

在整個過程中應當掌握一定原則，以價值為導向，不讓產品鎖死服務。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者。《后端產品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型后臺體系，社交APP。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自pixabay，基于CC0協議。