SaaS產品如何滿足客戶A的個性化需求？

客戶A的需求，專項開發不難，只要針對分析開發即可。但問題是：邏輯固化，數據固化，業務固化，一句話，通用性不夠。通用性是產品功能的生命力。因此，我們需要將客戶非常具象的專項需求做模型抽象。

好系統，對用戶的要求是粗放的。如果我們能夠把客戶的場景設計成通用的邏輯、數據和關系，意味著可以為客戶解決更多的問題，可以更靈活應對這個客戶的業務調整。這是面向標準化抽象的基礎邏輯，也是SaaS產品OneCode的技術保障。

一、最忌諱湊功能、湊邏輯：絕大多數的管理應用類軟件，都是基于主系統邏輯做開發。現在大多數的系統都有自己成熟的框架、體系和技術上的基礎。用現有的東西去搭建，比從零開始寫容易。產品經理在設計方案的時候會依賴原有的體系，這就容易出現用原有的組建、原有的邏輯、原有的界面、原有的UI去湊功能。凡是湊出來的功能，都不夠強壯，缺少魯棒性。魯棒性強的系統，容錯性就強，允許系統在一定（結構、大小）的參數攝動下，維持其它某些性能的特性。

二、需求分析的方法論：模型抽象分2步：1）分析使用場景。2）業務抽象：邏輯，數據和關系。關系：輸入數據時的約束，表和表的關聯，觸發機制。業務需求元素：場景、用戶、使用頻次、數量級。

三、在大背景中分析小場景：小場景后面可能是企業核心業務依賴，養成把小場景放到客戶A企業整體業務邏輯中去分析的習慣，才能真正讀懂用戶需求。對于很多廠商而言，用戶需求的滿足不是難度，但是他看不出用戶需求背后的業務重要性。如果我們只是把用戶的需求看成一個小功能，在感知上就發生錯誤了，看不出背后的關系。舉例，超兔最近有個醫療行業的客戶，提出一個業務員回訪終端客戶發掘分銷機會的場景需求。看起來是一個不大的事情，但是放在該企業的整體業務中，即可發現其重要性：

1）對于一個核心依靠分銷的企業來說：該公司要求銷售對終端客戶（醫院方）做信息挖掘，通過終端客戶去挖掘分銷合作伙伴。這是該公司分銷網絡渠道建設的重要一環，屬于戰略級的行動。

2）企業的分銷網絡越豐富，影響面越廣，觸及的銷售面越大，相比較一個個找終端客戶，渠道可以起到四兩撥千斤的作用。不過這家醫療公司找渠道分銷合作伙伴的方式更獨特，也更有效。他不直接找，而是通過終端客戶最直接的感覺、最真實的評價，去判斷、去選擇優質分銷商。

3）企業逐步建立起一個相對強壯、廣泛的分銷網絡，其中根本的業務包括：

1.發掘新的分銷商線索。包括：分銷商的基本信息，哪家企業，業務員，主營產品，覆蓋區域等。

2.更新分銷商信息。包括：分銷商有沒有換業務員？換地址？換聯系方式？

3.監督已經簽約分銷商的服務質量。意義：確保終端客戶滿意度；淘汰不合格的分銷商。

4）銷售層：一次行為的終端拜訪。分銷商與終端客戶并重。銷售需要把了解到的關鍵數據記錄到系統中，并刷新到各自的主業務表，包括：1.發掘了幾個新線索；2.更新了幾個老線索；3.回訪監督分銷商的數據。

最終，我們根據客戶提供的所有需求，抽象為：

1.我要經常回訪老客戶，刷新關鍵聯絡信息。【這是客戶回訪的標準邏輯，通用程度大于90%】

2.回訪老客戶時，轉介紹了新潛客給我。【通用性可以達到80%】

3.回訪中我還想記錄和刷新聯系人信息、其他業務信息（支持分類）。【提取共性+拓展自定義：分銷商的終端質量回訪，適應性不超過30%；但是，通過將銷售行為做抽象，即銷售操作記錄與刷新聯系人信息，刷新對應主表數據，可以達到90%的通用性】

4.上述事務要集成在一個行動事務下。

到這里，客戶A的個性化小場景，通過系列標準化分析范式，得出了最大普適的標準化邏輯和功能。