從目標、定位、落地三層面，談談我的CRM產品方法論

近兩年產品工作的核心基本在圍繞CRM展開，本文將從CRM的目標、定位、落地三個層面系統的總結關於CRM的產品方法論。

一、目標

CRM系統搭建和迭代的前提，基於3點：

目標的制定屬於戰略層的業務決策。其影響因素不僅限於內部資源、組織架構，同時與外部市場趨勢及競爭環境相關。對於科技公司，業務目標基本可以歸類為收入增長、用户增長、用户行為數據增長3類。

針對CRM系統，核心目標一般服務於收入增長。用户及其行為數據的增長雖然是收入增長的基礎，但系統層面的目標，多數是如何通過這些數據更好的幫助團隊達成預期收入。

對於收入的拆解，不同業務模式的定義大相徑庭，總體上可以抽象為：收入=符合某些特徵的用户數×該類用户付費金額，通常這個公式的表述是：收入=用户數×每用户平均收入（ARPU），ARPU值的影響因素，通常與產品服務用户的頻率和時長相關。

若引入用户生命週期的概念，則可優化為：收入=用户數×生命週期價值（LTV=LT×ARPU），簡單描述，LTV就是產品從獲取一個用户到徹底流失該用户所得的全部收入。從應用層面理解，LTV應是一類用户的平均生命週期價值，因此某段時間週期內的收入應=用户數×流失率×ARPU。

基於上述公式，可推導出下列因素均可幫助收入增長：

• 用户數增長
• 高質量用户增長
• 提升服務頻率及時長
• 提升運營人員服務效率（即人效）
• 降低用户流失率

運營人員的數量和工作時間往往非對應的產品經理能決定，因此CRM系統層面，產品負責人能有效提升的因素是人效。而提升人效最重要的產品方法是將業務行為數據化，再通過數據幫助運營決策。

二、定位

從業務運營的角度如何看待CRM系統？

傳統的觀點認為CRM就是運營人員進行業務操作和分析業務數據的系統，面向當前數字化管理、精細化運營的經營理念，以及獲客成本逐漸提升的市場現狀，CRM系統不單是操作和分析數據的平台，也是業務戰略落地的核心要素。

此外，任何系統都是為人服務。對於業務人員的激勵也是實現目標的重要一環，因此，CRM系統的定位可以歸類如下：

基於上述定位，產品落地的Road Map如下：

三、落地

CRM系統的落地基於業務行為的數據化，整體流程可參考下圖：

首先要説明的是，整個系統的起點和終點都來自系統外部的人。雖然產品自動化的程度日漸提升，但仍需人的參與提供基礎數據，並通過系統的反饋優化決策者的想法，進而產生業務價值。

達成營收目標的前提，是運營決策者的戰略思考。當CRM系統在公司業務模式裏佔據不可或缺的位置時，系統的價值才能更好的實現。

因此產品經理需要深入思考當前的業務模式存在哪些問題？其中哪些是收入增長的瓶頸？是否能在系統層面讓瓶頸得到改善？甚至不通過系統也能改善？

產品經理需要針對此類業務問題和運營決策者達成高度共識，同時基於組織內外的資源現狀梳理出可行的落地策略，Road Map的推進節奏，才能儘可能保證在後續的工作推進和迭代過程中得到各方足夠的信任和支持。

策略的執行環節，可以理解為將產品方案落實在CRM系統，並推進運營方使用的過程。如果此前已有承擔相應功能的系統，則需考慮新舊系統（或功能）的遷移策略。該過程至少要解決如下核心問題：

• 從使用者角度，新舊系統的遷移成本是什麼？如何最小化？
• 舊系統面向的業務場景和問題，在新系統中如何解決？如何最大化新體驗？
• 新舊系統並行期間，如何制定灰度策略逐步推進所有業務方使用？
• 如何搭建合理的反饋機制，快速響應遷移過程中的問題並迭代？
• 迭代過程中，判斷問題優先級的標準和原則如何適應業務的變動？

如果是從0開始搭建新系統，在各方達成共識的基礎上相對而言會更好推進，同時也對產品經理的架構策劃能力有更高的要求。關於搭建靈活可擴展的產品架構問題，可參考文末章節。

運營者使用CRM系統期間可能訪問多個功能模塊，操作者需要不停的決策並記住下一步的目標，注意力很容易失焦。

為了提升人效，讓運營者聚焦業務本身而非系統操作，可以將核心業務流程抽象成“任務”，並將統一的操作入口固定為“任務列表”，將高頻操作環節集合到“任務”中，在其中提供運營所需的用户信息，將原本需要在多個模塊進行的分析、觸達、記錄等環節合併至一個“任務”中，提升人效。

每個使用者對用户的觸達記錄，均可作為數據源生成整個CRM系統的統計數據，結合觸達後用户的行為數據變化，可以在一定程度上反映使用者的工作成效供運營決策者進行分析，進而判斷當前的業務現狀，幫助決策者和團隊迭代戰略構想。至此便形成一個基礎的業務數據閉環。

細節層面，CRM系統的高頻操作流程可以抽象為圖中3個核心節點：

下面將根據這3個節點分別闡述對應經驗。

1. 搜索用户

高頻操作的第一步即查找用户。解決該問題最簡單的方法是提供多維度的搜索、篩選條件。操作者通過各種搜索&篩選條件的組合尋找目標用户。這種方式類似在京東、淘寶購物，顯然是低效的解決方案。

這種低效源自業務發展過程中熵增的複雜篩選項，以及重複的搜索行為。更好的解決方式是在系統層面把複雜的篩選項抽象成業務邏輯，讓使用者無需搜索即可找到目標用户。基於該邏輯，可以將“搜索用户”轉變為“分配用户”。

如圖，操作者的行為從左側轉變為右側循環。這樣一個看似簡單的變化對於提升人效而言卻是本質性的改進：

關於分配邏輯，根據業務模式的不同可分為“固定業務邏輯”、“自動召回邏輯”兩類。

固定業務邏輯即根據指定的分配邏輯將用户分配給不同的運營方。比如具有地域性銷售&分潤特徵的業務，一旦涉及到渠道業績的結算，銷售線索的分配和策略調整即牽一髮而動全身，甚至需要重新簽訂合同。

一種接受度比較高的解決方式是通過唯一的渠道鏈接，追蹤渠道帶來的線索或付費用户。

此外也可通過搭建“全局線索池”，根據不同用户的地域、行業等屬性特徵，分配至對應渠道的“本地線索池”。根據直營、分銷、特許經營等業務模式，固定業務邏輯的分配策略不盡相同，這裏不作深入討論。

自動召回邏輯即結合用户的屬性、特徵，以及運營人員的屬性、特徵對樣本數據進行召回，並將運營人員和用户進行匹配，在CRM系統中生成“任務”。

該模式解決的問題是幫助運營層管理者減少為執行人員定期重複分配任務的次數。這種自動化分配規則的核心包括：召回策略、匹配策略、頻率、有效期4個方面，即：

• 用什麼邏輯召回用户和運營人員
• 用什麼邏輯對召回的用户和運營人員進行匹配
• 多久進行一次召回、匹配
• 規則在多長的時間段內生效

具體的規則邏輯，需要根據自身業務和用户的特徵進行數據分析及決策進行迭代，不做贅述。

基於分配邏輯，還可以為每次分配設置跟進“優先級”。即根據任務列表中用户的行為數據，將具備更高跟進價值的用户置頂或加入明顯的標識，幫助操作者優先跟進更容易產生業績的用户，降低決策成本。

2. 分析用户

越優質的用户越需要長時間的分析。

這個過程類似醫生對病人的診斷。過去的中醫通過“望聞問切”給病人看病，對醫生的要求較高，其次對醫生的時間利用效率低，且由於主觀因素影響過大，不同醫生對同一症狀的判斷也不容易達成一致。

現代醫學把診斷和治病分開，把診斷通過機器（CT、B超、X光等）和護士完成，結果非常精確。讓醫生的時間聚焦在根據診斷數據治病。對於簡單的診斷結果，比如日常的發燒感冒，甚至普通人就能自行處理。

借鑑現代醫學的診斷思路，在客户分析層面，產品經理可以根據帕累託定律（二八法則）將已經驗證的有效分析過程產品化，提升運營人效。

用户分析產品化的第一步，是將複雜的用户屬性和行為數據通過圖、表的形式進行標準化展示，實現信息的可視化。通過基本的培訓，運營者即可通過標準的分析方法解決常見問題，提升任務處理效率。

基於可視化的用户數據，系統可以將已驗證的有效分析方法模塊化，如“流失用户分析”、“付費用户分析”、“用户行為分析”，幫助運營者定位當前用户存在的問題。

此外，對於常見問題，系統還可提供相應的指導建議，如針對即將流失的用户，可根據此前用户的活躍狀態建議運營採用不同的觸達策略；針對新用户，可根據用户的註冊渠道、註冊後的行為建議運營在觸達時採用不同的話術；針對活躍用户，可根據用户的活躍行為建議運營適時進行付費轉化。

精準定位用户是一個非常複雜的分析過程。大部分篩選條件都是基於靜態的用户數據形成，比如用户的消費金額、頻率等。而業務場景中對用户的理解和分析卻是動態的，產品經理幾乎不可能根據過去的數據變化趨勢將所有時間維度的特徵整合至篩選項。

即使簡單粗暴的將所有篩選條件加入系統，其內在邏輯對操作者而言也很難理解，用户體驗很差。

因此對於需要通過複雜篩選項組合分析的業務場景，可以將已經驗證有效的分析過程抽象成一個整體的召回細則作為一個選項供使用者篩選。

簡單講就是通過與業務團隊深入溝通，把業務的分析邏輯梳理成產品方案，整合成一個篩選項，操作者只需通過點擊選項即可完成整個分析過程得到可視化結果。

該邏輯的典型應用就是“用户分羣”，即基於某些維度，把目標人羣區分為不同的羣體。既可以按性別、年齡、地域的人口屬性劃分，也可以根據數據分析的結論區分，比如待激活用户、活躍用户、流失用户等維度。

不同行業也可以根據業務屬性劃分，比如教育行業可分為體驗用户羣、購買用户羣、復購用户羣，企業服務領域可根據客户的購買階段分為陌生客户、意向客户、潛在客户、簽約客户等等。

這裏需要注意的是，每種分羣邏輯之間必須互斥。如果一個用户被劃入“活躍用户羣”，則用户在同一時間週期內不可被劃入“流失用户羣”或其它用户羣。

除了系統層面的用户分羣，CRM系統也可以幫助每個運營者自定義“用户標籤”。與用户分羣不同，標籤是運營者基於自己對用户的主觀理解以及業務需要，人為標記的特徵標識。

標籤之間並不互斥，同一用户也可以被標記多個標籤。運營者在工作中標記的越精準，對效率的提升也就越高。產品經理也可以在調研中根據運營者添加的標籤特徵進行分析，完善用户畫像，或者將適合用於分羣的特徵抽象為分析選項。

業務層面，管理層對運營人員的行為分析對目標的達成也至關重要。基於產品的數字化閉環，針對運營人員的數據分析一般集中在任務的執行和記錄以及符合績效標準的用户數提升。

任務的執行記錄，可根據操作者的處理時長、記錄完整度、使用頻率等數據維度在一定程度上衡量人效。更重要的是運營觸達用户後，用户行為數據或付費轉化數據的提升。

產品經理可以根據業務實際情況，將此類數據整合成可視化的圖表供運營層管理者評估團隊整體及個體的工作現狀。

3. 觸達用户

站在用户視角，平台的觸達可分為用户主動發起和被動接受兩種。用户被動的接到營銷電話或微信好友申請體驗相對較差，除非命中有切實需求的用户，否則轉化率極低。

對於用户主動發起的互動，可分為兩類：

一種是使用或體驗產品的過程中遇到問題，需要向平台諮詢。該場景可通過智能Q&A將常見問題整理成結構化的客服消息自動回覆給用户，類似在淘寶購物時自動彈出的尺碼、發貨諮詢消息。此外也可通過交互式語音問答（IVR）幫助用户解決典型問題，類似中國移動的客服電話。

另一種主動發起的互動，在當前的教育、消費領域較為常見，也是近年十分火熱的私域流量運營模式。平台一般會通過提供專屬的服務或優惠政策，引導用户添加服務人員微信。建立好友關係後，再通過社羣、朋友圈、線上活動等運營形式提升用户活躍度，進而促成付費轉化。

提到私域流量運營，這部分產品迭代其實屬於CRM的範疇，但由於微信的接口限制，除非在操作系統層面Hack微信客户端（該操作存在較高的封禁風險）否則無法與內部系統打通。

直至去年企業微信3.0版本陸續開放客户聯繫、客户朋友圈等相關API後，將企業微信與內部系統打通幾乎成了私域流量運營的標準配置。自此企業微信便可作為CRM的移動端工作站，幫助企業沉澱用户關係。

關於企業微信和私域流量運營，是另一個大話題，這裏不做更多討論。

綜合來看，關於觸達用户，用户主動發起的互動對沉澱用户關係具備更高的價值，在CRM系統日漸完善的基礎上，如何讓目標用户主動與產品產生連接以及後續一系列的價值交換行為，是值得產品經理用更多心力思考的問題。

四、激勵

對員工的正向激勵可以提升產出，這是個不言自明的道理。

如何在CRM系統中讓使用者獲得成就感、價值感也是值得產品經理思考的問題。相比核心的業務操作及分析，與員工激勵相關的功能往往排在靠後的優先級，但這並不影響產品經理去思考及規劃。近兩年的產品實踐中，以下幾點在激勵角度具備一定的參考價值。

1. 實時業績

業務產出的結果對員工的重要性不言而喻。如果能在系統中實時展示使用者的工作成效，對士氣的提升具有重要意義。

不論業務目標是收入增長還是用户行為數據增長，在運營人員的個人中心或更明顯的Dashboard上展示前，產品經理都需要跟運營決策者明確要展現的數字及計算邏輯是否符合業務層面的激勵原則，以及具體的更新頻率、有效時段、結算邏輯。

與此同時，還需考慮研發層面對業務數據的結算能做到多久的實時性，中間要經過哪些數據流轉節點以保證最終展現的數據與實際結算一致。綜合考慮業務及研發團隊的現狀，方可產出卓有成效的激勵方案。

2. 公告板

產品層面，公告板是一個邏輯極其簡單的功能，只需一個明顯的展示入口和一個內容編輯模塊即可完成整個流程。

業務層面，公告板起到了重要的信息同步作用。平台鼓勵什麼、反對什麼，業務層面的最新進展以及政策變動等重要信息，均可通過公告板實時發佈。

與業務團隊合作的產品經理，應當積極的瞭解業務動態，深入業務的各個環節去理解每個業務訴求。好的解決方案不一定非要做的多麼複雜以體現產品邏輯的縝密，而是要極盡簡潔。用程序的語言表達，則是要考量需求是做成一個“類”還是“實例”。

拿公告板舉例，業務的訴求可能是做一個業績公告或是排期同步的功能。產品經理應該注意到這是業務人員從“實例”層面提出的解決方案，背後真實的需求是解決多人協作時的信息同步。

此時需要儘可能從“類”的層面抽象出一個可滿足所有此類場景的產品方案，而不是簡單跟隨業務的想法機械的落地方案。

分配權重

對於應用“自動召回邏輯”分配任務的CRM系統，如果業務層面對使用者有相應的激勵政策，則可在運營人員的召回邏輯，以及對召回用户和運營人員進行匹配的邏輯中根據激勵政策加入相應業務邏輯。

比如對於業績超過均線的運營人員分配更高比例的優質用户，對業績水平較差的運營人員分配更簡單的任務。通過對分配權重的調整，能夠讓運營人員更明顯的感知到自身行為產生的結果，幫助整體業務更好地進行優勝劣汰。

五、架構

如果把做產品類比為在虛擬的比特世界中蓋一座大廈，架構則是動工之前必備的圖紙。對於系統的非功能性特徵，如擴展性、複用性、QPS、TPS等，一般由研發團隊進行設計和迭代。

產品經理在其中的角色更多是結合當前團隊現狀以及業務未來的發展預期綜合考量，提出在業務發展各個階段中都能具備統一規範且足夠靈活，可擴展、可複用的產品方案。

做產品是個熵增的過程。隨着用户規模、業務規模的擴張，必然引入一系列新場景、新需求，產品複雜度也隨之提升。

從這個角度，架構其實就是基於業務結構定規則做限制。正因如此，架構沒有對錯之分，也沒有一套架構能適用所有業務場景，產品經理只能在迭代中不斷打磨提升。

首先，架構最重要的就是貼合業務。

這是一個從整體到部分的過程。只有明確公司對用户提供的服務是什麼，業務如何開展並規模化，定下最上層的戰略之後，產品的邊界才得以劃分，這個基本上一旦確定就很難更改。

接着就是基於整體規劃，給每個部分劃分解決方案，定義其核心功能以及各部分之間的關聯關係，形成最終的產品結構圖，並隨着業務的發展同步迭代。

系統落地層面，產品經理首先要基於組織架構定義合理的權限管理機制。最簡單粗暴的方法，是直接將讀寫權限授權給用户。這裏引入的問題是所有用户的權限變更均需管理員手動變更，且不支持多層級的權限管理。

因此在系統實踐中，引入了“角色”概念，即在用户集合與權限集合之間建立一個角色集合，每一種角色對應一組相應的權限。一旦用户被分配了適當的角色後，該用户就擁有此角色的所有操作權限，這就是權限控制理論中經典的基於角色的訪問控制（RBAC）。

在更復雜的使用場景中，如果把角色視為用户的一種屬性，就可以添加更多的用户屬性，通過對屬性的策略調整控制用户的權限，即基於屬性的訪問控制（ABAC）。

以上的權限管理方法，幾乎可以滿足目前所有公司對於權限管控的基本需求。感興趣的朋友可以另行深入研究。

確定權限管理機制後，產品經理需要對權限所控制的每個業務模塊進行抽象歸類，將業務場景高度重合的功能模塊化，集合在統一入口，在產品層面實現功能的高度聚合，儘可能降低模塊之間的複雜關聯，用程序的語言描述即——高內聚低耦合。

這個過程也可以稱之為組件化，本文僅闡述了CRM系統中最核心的流程，在實際業務中，系統還可能包括營銷管理、訂單管理、流程管理、知識庫等眾多子系統，一個功能點的改動可能牽涉多個子系統的修改，不利於產品快速交付。

因此產品經理需要儘可能將長期穩定使用的功能切分成子系統，在子系統內按功能點再進行切分。

比如對於具備優惠券、折扣減免等營銷功能的CRM系統，就可以將優惠折扣的屬性配置集中在營銷管理這一子系統中，把具體的發放流程添加至上文描述的“任務”中，運營者只需在任務中完成優惠發放，無需在營銷管理中進行復雜設置，後續關於營銷工具的迭代也更利於研發快速交付。

組件化帶來的另一個問題是定製化，即為不同的人提供不同的產品。

如果能為每個使用系統的用户提供定製化的產品必然能提高人效，然而在成本層面考慮並不現實，因此可以考慮通過配置化的方式，讓用户可以通過配置來選擇符合個性化需求的插件解決問題。

配置化是CMS（內容管理系統）的核心思想。具備配置化功能的系統，新功能的上線及老功能的更新不需額外開發工作，客户端發版後，系統管理員僅需簡單的配置即可實現。CRM系統也可以借鑑這種思路，將主體結構和功能細節變動相對不頻繁的產品模塊迭代成可靈活配置的組件供用户使用。

以上，即是近兩年產品工作中關於CRM產品方法論的系統總結。希望可以給從事相關工作的產品經理們提供一些參考。

一個系統是否好用、有效，最終都取決於團隊。希望產品經理們也能夠從整體的視角來迭代產品，協力打造一個具備高執行力、積極向上、創新思維的團隊，共同成長。

#專欄作家#

柳大叔，人人都是產品經理專欄作家。一個自由職業的產品經理，正在平坦的道路上曲折前行。專注企業服務領域的產品規劃、UX、用户研究及數據分析。座標帝都，歡迎交流。

本文原創發佈於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基於CC0協議