編輯導語：SaaS系統近來得到了較為快速的發展。伴隨著客戶不斷增長，人們對SaaS的要求也會與之增多，包括一些個性化需求。本篇文章里，作者就對如何平衡SaaS的標準化規范與個性化需求做出了他的回答，讓我們來看一下。

我們知道，做Saas產品和做定制化項目之間最大不同是：做定制化項目，可以根據客戶的需求，考慮其業務的特征，最大化的滿足客戶個性化需求；做Saas產品時，就要考慮其通用性，如何把產品做的通用，滿足更多客戶的需求。

但同時，當Saas產品服務的客戶越來越多，還是會出現不同的客戶有著一些不同的個性化需求。這時，這個問題該如何解決？

我們可以通過配置化的手段來解決。

• 當個性化需求的業務流程與現有產品業務流程差別較小，可以從功能層面進行配置來解決個性化需求問題。
• 當個性化需求的業務流程與現有產品業務流程差別較大，可以從系統層面進行配置來解決個性化需求問題。

通過以上2種可配置方法基本上解決了大多數遇到個性化需求應該怎么辦的問題。

不過做個提醒，我們做可靈活配置的目的，是為了解決顧客問題，我們有必要把配置做的非常靈活嗎？還是要根據實際情況把握好靈活的度（這個問題我文章后面會回答）？

因此，為了解決如何通過可配置方法，高效地滿足顧客個性化需求，本篇文章，我將從以下3個方面來講解：

1. 功能層面的可配置；
2. 系統層面的可配置；
3. 如何把握好可配置的靈活度？

接下來，我將一個一個展開來講。

一、功能層面的可配置

當個性化需求的業務流程與現有產品業務流程差別較小，可以從功能層面進行配置來解決個性化需求問題。

具體怎么用？

拿到需求，首先分析需求與現有產品業務流程的差別是否較大。

若差別較小，則先站在整個產品架構的層面來看個性化需求，把需求歸類到屬于它的模塊，在對應的模塊里進行可配置操作。

1. 案例1

這里我還是以上一篇文章聊到的景區智慧營銷Saas系統為例，講一講面對一個個性化需求時該如何思考并落地。

首先，先介紹一下智慧景區Saas系統目前的現狀，目前模塊現狀是：一級模塊“商品管理”里包含了“門票（此時的門票是指付費門票）、特產”兩個二級模塊。還有其它如，訂單管理、店鋪管理、數據管理等一級模塊。

大概的架構如下面這樣：

然后現在遇到了以下2個最終確定有價值的需求：

1. 有的景區想提供給游客免費門票，但需游客提前預約，而有的不需要；
2. 有的景區入園時需要出示身份證，而有的景區則不需要；

這時面對不同的景區，都有不同的個性化需求，該如何落地產品設計？

思考過程如下。

1）有的景區想提供給游客免費門票，但需游客提前預約，而有的景區不需要；那么，這業務需求肯定要歸類到商品管理里面的門票管理模塊里面去。

通過梳理發現，免費門票和付費門票的業務邏輯，在整個后臺景區工作人員的工作流里，基本上是一致的，不同點就是有的景區門票收費、有的免費。這時只需要在門票管理模塊里配置一個是否要收費的功能，就能把這這個問題解決了。

如果不需要收費的門票，工作人員選擇了不需要按鈕，圖片中的市場價和銷售價框就會被置灰，不能操作。

2）有的景區入園時需要出示身份證，而有的景區則不需要。這時也簡單，在門票管理模塊里配置一個“景區可選擇取票時是否需要出示身份證按鈕可供選擇”就能解決問題了。

2. 案例2

還是以上面的景區Saas為例，每個景區都需要有一個店鋪（或者說，叫做商城系統）來面對C端游客，供游客查看、下單各種商品。

這個時候，行業內的不同景區都希望自己家的店鋪和別家的不一樣，想要自己個性化的店鋪，面對這樣個性化的需求如何解決？

1）方法1

可以開發出很多套來供景區選擇，這樣做不好的地方是，開發的越多，投入的產研成本越大，甚至開發出來的店鋪模版，景區不一定滿意。

2）方法2

開發出來的每一套店鋪模版，店鋪模板中的功能組件（景區可以自由增加、刪除、修改），最終搭配出一個自己比較想要的個性化店鋪模版。

3. 案例3

有一款產品叫“微伴助手”，是企業微信里做私域流量運營的一個工具。

在幫助服務的商家解決客戶轉化問題時，其中有一個解決方案是，圍繞用戶的全生命周期做精細化運營管理的方案。

可在微伴助手服務的所有商家里，大家的生意業務邏輯不一樣，對客戶的全生命周期管理也不一樣，也就是“圍繞用戶全生命周期做精細化運營管理”有了不同的個性化需求。

這時，微伴助手給出的解決方案是：給出了一套可配置的“全生命周期管理方案”。

從圖中我們可以看到微伴助手軟件首先給出了一個默認配置好的用戶全生命周期解決方案，分為，新客戶——初步溝通——意向客戶——商家——無意向客戶這5個階段。

這個生命周期的劃分只是初步劃分，商家可以根據自己業務的個性化需求，對這個劃分進行編輯、增加、刪除。

• 刪除是指，這5個階段，可以刪除掉1個、2個等等，根據你的業務需要，進行調整。
• 增加是指，除了這5個階段，你還想增加更多的階段，根據你的業務需要，進行調整。
• 編輯是指，你可以對客戶階段名稱、階段提醒規則的重新調整。

我舉的這幾個案例，我們可以看到一個現象，就是默認項的設置，比如門票是否收費、默認的配置是需要收費（這是因為，收費門票的場景會更常用）。

我們在做功能配置項時，也要做好默認項設置工作，看什么的設置需求更高頻，把它變為默認設置項。

以上，就是面對個性化需求時，當個性化需求的業務流程與現有產品業務流程差別較小，從功能層面進行配置來解決個性化需求問題的一個整體講解。

二、系統層面的可配置

當個性化需求的業務流程與現有產品業務流程差別較大，可以從系統層面進行配置來解決個性化需求問題。

為什么需要從系統層面來進行配置？

因為，功能來源于需求，需求受流程的影響，當用戶個性化的需求與現有產品架構流程差別較大時，只能從系統層面來配置。

從系統層面來配置時，有三種解法：

1. 配置的權限在Saas產品服務商手里，Saas服務商根據顧客的需求，進行后臺配置；
2. 配置的權限在顧客手里，顧客根據自己的業務需求來進行權限配置；
3. 系統自動配置。

具體什么意思呢？我們下面用一個案例來講講。

這個案例，還是用文章中，我們提到的景區Saas產品案例來講解。

景區Saas產品中，目前有的業務系統就是票務系統；但是根據Saas軟件服務的景區中，有的景區還有酒店管理系統需求，而有的沒有，這個時候應該怎么辦？

首先我們經過初步分析，發現酒店管理系統和現在產品架構的業務流程差別還是比較大的。

只能在商品模塊里面在添加一個房型管理（之前的商品模塊里有一個門票管理），然后因住宿而增加的訂單、數據需求加到之前的訂單、數據模塊，新增加的這些功能合在一起形成一個完整的住宿管理系統。

這個住宿管理系統可通過以下幾種方法在系統層面進行配置，最終滿足景區的個性化需求。

• 默認景區都有住宿系統需求，景區注冊Saas軟件后，若景區不需要住宿、或者是門票系統，聯系Saas服務商，服務商手動給景區配置，把不需要的系統去掉，給景區留下需要可簡潔操作的功能；
• 給景區默認的是一套沒有住宿系統的版本，當景區有需求時，Saas服務商再通過后臺給配置；
• 景區注冊系統時，提示景區是否有哪些系統需求，景區選擇完后，根據景區的需求，自動配置出景區需要的系統。

最終選哪種？這沒有標準答案，根據產品經理綜合評估以后來選擇（包括產品收費方式、發展階段，技術實現難度等等因素）。

三、如何把握好可配置的靈活度？

當然，可配置不是萬能的解藥，我們不能認為，既然有那么多個性化的需求，我們把各個功能都做成可配置就可以了。

要記得我們的一個終極目標，我們開發的Saas產品是為了幫助客戶解決問題的，希望客戶能持續用起來，以后還繼續付費。

如果靈活配置度過高、配置項多，就會帶來頁面的不簡潔，看起來、且操作起來就會麻煩，增加顧客工作量，且還會大大的增加開發成本和開發周期。

因此我們需要綜合評估以后（包括對客戶的理解、收入方式、客戶服務投入度等），把握好靈活度。

比如，就像我在文章中提到的：景區對店鋪有個性化需求，因此開發出來的每一套店鋪模版，店鋪模板中的功能組件，景區可以自由增加、刪除、修改，最終搭配出一個自己比較想要的個性化店鋪模版。

假設是給中小商家用，你說，如果你問顧客，他有店鋪個性化需求嗎？

回答是肯定的。

但是開發出來以后，我們會發現，小商家根本就用不了、不會用，你需要的是給他一套固定好的模版就行。

同時，就算會用，由于小商家對產品的購買付費金額會比較低，而在店鋪模版環節做那么多的個性化需求，投入的產研周期是比較長，且成本比較高，會大大的增加產品的盈利難度。

綜合評估完，只需要有一兩套簡單固定的店鋪模版就好。

最后，關于Saas產品如何解決標準產品和個性化需求之間的平衡就講到這里了。

#專欄作家#

豐憲飛，微信公眾號：小飛哥筆記，個人微信：f1506620495。人人都是產品經理專欄作家。某互聯網創業公司合伙人兼產品總監，多個項目“從0到1”項目負責人，擅長戰略、運營、產品的整體規劃及落地執行。

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

題圖來自Unsplash, 基于CC0協議。