CRM是一個經久不衰的話題，對於它也有眾多討論。產品經理在工作當中也時常會碰到，但是CRM的真面目你真的瞭解嗎？本文從七個角度對CRM知識，並對其在工作中的實際應用展開分析，希望可以幫到對CRM有疑惑的童鞋。
CRM這個話題很古老，圈子裏關於CRM的分享也很多。有從“權限設計角度”講的、有從“線索-客户-商機”設計角度講的、有從“數據報表”角度講的，有從運營角度講的、有從銷售角度講的……
這些分享都很不錯，可以快速建立起知識體系，但總是覺得這些分享多是從已實現的角度做個結論性的分享、缺少從底層原理的剖析、以及為什麼要這樣做的探討？
我們大家會有一個普遍的感覺是，這些文章讀起來很爽，但要再達到一個高度，或者説自己下手設計或運用CRM的過程中，因不清楚底層的基本原理，機械的理解會導致如下兩個問題：
產品經理應該充分理解、充分提前預見、並在產品層面梳理出合理的解決方案，幫助團隊化解研發風險、幫助企業提升研發效能、幫助運營部門靈活高效運用落地的，但因淺嘗輒止、囫圇吞棗、機械理解、以貓畫虎，不清楚底層原理，給團隊挖坑多。
看文章會導致我們機械的照搬市面上千篇一律CRM設計套路，而忽視了最本源的問題“我們的業務背景是什麼？我們的業務生態是什麼？我們的CRM訴求是什麼？我們的CRM能否與現有的業務系統做融合創新，圍繞我們的業務場景及核心用户在產品設計層面有新的產品策略、架構設計出來？否則，食之無味，仍之可惜！
本篇分享是基於我們SaaS平台建設中因業務需要在CRM方向的產品設計、研發建設及系統落地中踩過的坑以及持續迭代中的業務思考和產品處理策略的覆盤總結，進而幫助大家達到：
澄清CRM的相關術語概念、底層原理，概念理清了，原理明白了，我們的知識圖譜就建立起來，知識圖譜有了，我們對CRM的很多未知和疑慮也就蕩然無存了。
掌握CRM的引入策略、建設路線、架構設計、迭代建設策略等。結合一些具有代表意義的實踐case，縱向上從產品設計、研發建設兩個角度從上往下看；橫向上從權限設計、CRM系統設計、數據中心設計、績效報表體系設計、ERP-OA審批體系設計、CallCenter系統設計、銷售單兵作戰工具設計等多維度平視來看，幫助大家在CRM設計、研發建設中少走彎路或不走彎路。
用好CRM這個神器，不把CRM當做花瓶，而是真正將市場團隊、運營團隊、客服團隊、銷售團隊充分調度起來。以CRM工具為載體，將公司業績目標自上而下分解，政策向下落地，數據向上彙總；通過活動投放、線索採集、線索清洗、銷售攻城、後端履約交付、客服受理化解風險等節點將組織內部各作戰單元串起來、跑起來；人效可視化，通過數據説話，來找出業務開拓的瓶頸點、逆向挖掘瓶頸原因及疏解之策。
閲讀對象：打算引入CRM的決策者、打算開發CRM、打算重構CRM、正在開發但一知半解的產品經理。
一、 CRM的價值我們真的瞭解麼？
閲讀對象：打算引入CRM的決策者。
CRM如同空管指揮系統，幫助空勤人員誰負責哪條航道，負責人藉助系統識別哪個飛機可以起飛、哪個飛機可以降落，飛機降落後及時通報地勤系統做好接駁保障等。
對於沒有賬户體系的非互聯網企業來講，CRM的核心價值不僅作為一個武器幫助銷售拿下客户，也能幫助打造標準化作業流程、企業優化運營成本、構建企業數據中心，為企業搭建一個軍事情報指揮系統。
對於有賬户體系的企業來説，CRM作為企業數據中心的功能延伸，為銷售人效提供增加動力。
1.1 採集-清洗線索、識別-挖掘潛在客户
對採集的線索進行快速清洗，提取有價值客户。
方便每一個銷售機會的跟進情況，快速制定客户的跟進策略。
1.2 構建非對稱壓力銷售武器：情報壁壘 專業知識壁壘
基於業務體系沉澱的用户數據，系統為每個用户建立全維度檔案——CRM系統為企業建立了一個完整的客户信息共享數據庫。
銷售人員基於自己的專業知識和上述客户情報信息的全量掌握，為銷售構建非對稱銷售武器。
1.3 銷售業績直觀化、實時化
CRM系統能夠自動生成銷售報表，使銷售業績更直觀的展示出來。
CRM系統與銷售佣金管理相連接，可以清晰地、準確地、即時地掌控人效，調整銷售結構域方向，在這一方面，CRM系統的價值就是能實現銷售人員企業之間的雙贏。
1.4 銷售流程規範化、簡明化
CRM系統具有促進銷售流程規範、整合、優化的價值。
實施CRM系統能夠改善企業的銷售流程，加強對潛在客户的機會管理，讓銷售人員更加有針對性地把握銷售業務的進展與銷售策略。
CRM系統能夠簡捷地預測銷售業績，評估企業績效，識別出現銷售業務中有的問題和未來的趨勢，通過這一功能，CRM系統體現出了提升企業的盈利能力的價值，為銷售的成功提供了有力保障。
1.5 數據集成、人效比對、精細管理、成本優化、精細
CRM與企業的數據中心、ERP、第三方SEM系統無縫集成，實時數據交換，通過分析客户來源、客户貢獻來比對渠道成本，優化投放方向、優化運營方向、尋找最優合作伙伴和最優運營策略。
CRM與ERP數據協同，將銷售、庫存、客服、退貨等綜合起來管理，降低了經營成本，提高企業的經濟效益。
CRM系統的價值概括起來就是：
CRM系統能夠為企業構建一整套以客户為中心的有關客户、銷售、服務與支持信息的數據庫，幫助企業優化管理渠道和前線業務流程，比如，市場營銷、銷售、產品的服務與支持、呼叫中心等。
CRM系統還能深層次分析和挖掘最有價值的客户、新的市場和潛在的客户，創造業務良機，提升客户忠信度，提升企業銷售效益。
二、CRM業務知識解構、產品架構設計策略 2.1 CRM必須理清知識點1：市場、運營、電銷、外呼、銷售的邏輯關係
不同團隊、不同行業有不同的組織架構，對於大型企業來講，泛業務團隊有如下幾個兵種，即“市場團隊”、“運營團隊”、“電銷團隊”、“網銷團隊”、“銷售團隊”、“售後客服團隊”。
市場團隊：
工作邊界：以投放廣告、採集線索為主攻方向，譬如SEM、硬廣投放、地推活動、會銷等。
管理重心：活動成本、ROI轉化率、線索質量。
運營團隊：
工作邊界：設計運營策略激活休眠用户、完成新用户轉化、提升老用户客單價及復購率等。
管理重心：轉化率、客單價、復購率。
電銷團隊：
工作邊界：對市場、運營交辦的外呼任務進行地毯式外呼，過濾無效線索、提取有價值線索、誘導激發客户的需求意向、直接成交或移交給銷售團隊進行線下深度解除。
管理重心：撥打量、接通率、轉化率、客户評價等。
銷售團隊：
工作邊界：基於系統數據、專業知識通過電話、拜訪、邀約、現場演示等方式對線索或意向客户進行銷售推進，挖掘商機，把客户從意向帶到成交階段。
管理重心：跟進量、邀約量、簽單量、邀約率、簽約率、回款率。
客服團隊：
工作邊界：接聽客户呼入電話，受理客户訴求，視情況轉給銷售或售後。
管理重心：接聽量、用户評價、工單量、工單閉環量。
我們可以用個例子來描述上面幾個團隊的協作關係。
市場團隊類似宣傳部，執行的是心理戰，進行搖旗吶喊贊人氣、蓄客；
電銷團隊類似轟炸機，執行的地毯式轟炸任務，為地面部隊進場打掃戰場；
銷售團隊類似特種兵，執行的巷戰，一個敵人、一個街頭、一個陣地的定製攻擊；
運營團隊類似戰後管理，執行的繁榮建設，通過規則玩法將人民馴化、安居樂業、生態經濟繁榮。
現實中，一般有如下幾種組合：
小型團隊：銷售團隊
中小型團隊：電銷團隊 銷售團隊
中小型團隊：市場團隊 銷售團隊
中型團隊：市場團隊 運營團隊 銷售團隊
中型團隊：網銷團隊 電銷團隊 銷售團隊
中大型團隊：市場團隊 運營團隊 網銷團隊 銷售團隊
大型團隊：市場團隊 運營團隊 網銷團隊 電銷團隊 銷售團隊
針對不同的角色，不同的使用場景，CRM平台分別提供不同的工具——某些工具某些程度上可以不計入CRM，譬如我們平台的訂單工具、日程工具、消息工具、數據報表工具，這些工具是在CRM項目立項前已存在的，只不過是後期CRM項目立項時，進行了系統整合。
由於CRM系統主要服務銷售，我們的CRM設計重心圍繞“銷售管理”、“銷售執行”兩條線進行。基於銷售轉化漏斗，我們在不同的節點開發了不同的工具矩陣來服務“銷售執行”、“銷售管理”：
2.2 CRM必須理清知識點2：用户、客户的邏輯關係
互聯網講用户，CRM講客户，運營講用户，銷售講客户，不同場景有不同的叫法有什麼特殊的考慮呢？如果我們沒有系統，直接買個CRM系統，很好辦，用户，客户無所謂，CRM通吃。如果我們是一家互聯網公司，突然某天老闆説了，我們要建一個CRM系統，如果不深入吃透這兩個概念，我們會踩不少坑。
譬如：某個用户是系統已有的用户，又被市場團隊外採到，CRM系統如果未考慮與系統的用户融合的話，銷售在推進中就很容易被用户説：“你們家有毛病，我已是你們會員了，還老給我打電話推銷入會？”
處於閲讀體驗考慮，下面用表格方式向大家呈現：
2.2.3 產品設計應對策略
策略1：CRM的客户表增加用户標識，當是用户時，在CRM系統中呈現用户在平台的必要行為數據；
策略2：用户數據自動實時向CRM數據表同步；
策略3：用户表向CRM表做自動同步時，如果命中CRM已有客户時，做自動綁定；
策略4：外採線索，手動單條錄入客户時，如果命中用户表，做數據自動提取；
策略5：外採線索，手動單條錄入客户時，如果命中用户已被其它銷售佔用，提醒禁止錄入；
策略6：外採線索，手動單條錄入客户時，如果命中用户未被其它銷售佔用，提醒移入自己名下；
策略7：外採線索，批量導入客户時，如果命中用户，強制跳過；
策略8：外採線索，百度等SEM通過API自動同步數據時，如果命中用户，強制跳過；
2.3 CRM必須理清知識點3：線索、商機、客户的邏輯關係
首先用我總結的一個表來把幾組概念放到一起，方便大家有個整體盤感。
熟背上表是否代表我們完全理解“線索、商機、客户、合同”的關係了呢？不，尤其是作為產品經理的我們，還必須掌握如下幾個背景知識點：
其一就是公司的組織架構中是否有運營、銷售的強分工概念。
其二就是銷售業務鏈路是否很複雜，有沒有必要對“線索、商機、客户”多節點細化管理。
簡易業務場景中，“線索、商機、客户”三組概念可以合併到“客户”概念中，“合同、訂單”可以合併到“訂單”概念中。用一個概念管理的好處是：培訓成本低、操作成本低、市場節奏快、管理成本低。
複雜業務場景中，組織分工明確的場景中，就需要精細化管理了，通過精細化管理分別考核不同組織的戰績，各個組織在專業方向上猛攻，通過團隊協同拿結果。
針對這種情況，我們在CRM的架構設計時，可以通過如下策略來滿足不同的業務場景：
策略1：線索和商機是選配，可以啓用也可以不啓用——走下述策略2、策略3；
策略2：“線索-客户-商機”三者之間“互掛”——穿透管理設計策略；
策略3：“合同”和“訂單”進行“互掛”——穿透管理設計策略；
策略4：訂單複用“工單”的OA任務流引擎。
其三就是我們需要了解“線索、商機、客户”底層對應的業務原理。
業務開發中：營銷部門去發現、尋找、吸引敵人，銷售部門負責殲滅敵人。通俗點講就是營銷部門負責找客户，銷售部門負責打單拿下客户。
大多數的公司沒有對線索做細分，把只要通過各種渠道進來的線索統統歸納到一起，然後再按既定規則分配給銷售去處理，在一定的銷售週期內再去考核銷售的轉化效率。這種考核的方式最大問題是鬍子眉毛一把抓，很難從轉化率層面發現問題的根本。銷售和營銷會扯皮，銷售老大説線索質量太差，營銷老大説銷售執行力差。
如果我們把線索和商機拆的更細，通過更小粒度的定義來做精細化管理，這個矛盾就會小很多，人效也會更優，具體如下：
2.3.1 線索量
所謂線索要滿足幾個要素，比如對象、聯繫方式、需求屬性、線索來源等。從銷售角度，希望把線索分成如下幾類：
2.3.2 商機量
所謂商機要滿足幾個要素，比如剛性需求、時間、預算、負責人等。
從銷售的角度希望把商機分成兩大類，一類叫做方案類商機，一類叫做投標類商機。
2.3.3 轉化率
如果説線索決定銷售具體動作，那麼商機重點就要考慮成功率和資源投入情況了。
2.3.3.1 線索—商機轉化率
由於前面把線索做出了細分，不同類線索轉化時長以及時效性有明顯的趨勢規律，我們可以通過“線索—商機轉化率”來確定線索的質量、評判市場部門的ROI。
2.3.3.2 商機—訂單轉化率
這個指標比“線索-訂單轉化率”更能科學的反饋銷售的執行能力和人效價值。
2.4 CRM必須理清知識點4：合同、訂單、工單的邏輯關係
老規矩，依舊用我總結的一個表來把幾組概念放到一起，方便大家有個整體盤感。
這三組概念比較簡單，不化過多筆墨累述。只是，我們在產品架構設計時，需要充分清楚如下邏輯關係鏈，否則會掉坑裏：
一個訂單可以有多個合同、一個合同也可以有多個訂單——互掛設計理念；
合同有周期概念，合同到期會觸發後續跟進，譬如與消息系統互通；
如果有合同，需要有配套的合同影像管理，否則將來合同模塊意義不大；
2.5 CRM必須理清知識點5：聯繫人、聯繫方式的邏輯關係
依舊老規矩，用我總結的一個表來把2組概念放到一起，方便大家有個整體盤感。
這2組概念比較簡單，不化過多筆墨累述。只是，我們在產品架構設計時，需要充分清楚如下邏輯關係鏈：
一個客户可以有多個聯繫人；
一個聯繫人可以出現在多個客户名下；
聯繫人的名字、電話均允許重複——系統提供彼此的穿透透視鏈條；
不同客户的主備聯繫方式可以重複，系統提供查重、提醒功能；
人名、電話、身份證號均不可作為主鍵進行邏輯傳導，而要用“表id”進行邏輯穿透；
2.5.1 C端客户多聯繫方式產品設計邏輯、字段策略如下：
2.5.2 C端客户添加聯繫方式產品設計邏輯、字段策略如下：
2.5.3 B端客户添加聯繫方式產品設計邏輯、字段策略如下：
2.5.4 以用户為中心的聯繫人穿透產品邏輯、字段策略如下：
2.5.5 以聯繫人為中心的列表總覽產品邏輯、字段策略如下：
大家可以看出同一聯繫人可以重複出現，只是掛靠客户不同。
三、超大複雜組織權限的產品架構設計策略
由於我們的CRM系統是在我們SaaS平台基礎上開發建設，故我們的CRM系統在權限這塊基本無建設壓力，下面就我們的SaaS系統的權限架構設計同大家分享一下。
在分享之前，大家先看如下幾個場景，通過如下幾個場景的業務需求將大家帶入“高複雜權限架構設計”的解構之策、破解之道：
上面的問題看似很嚇人，實則紙老虎。我們通過抽象解構、上述問題就很簡單了，説明如下：
3.1 橫向解構
入口層：也即頁面權限，能否進入這個頁面；
操作層：也即“查看權“、”操作權”；
邊界層：也即可看可操作的數據邊界。
3.2 縱向解構
脱敏層：某些元素對我脱敏，對他不脱敏；某些元素對他脱敏，對我不脱敏；
審批層：某些業務鏈路需要我審批，某些業務鏈路不需要我審批；
時序層：某些數據某時期能看，過了某時期我不能看了。
3.3 解決方案——引入角色概念
角色，控制頁面入口，擁有該角色，也即擁有頁面的門票進入權；
角色，控制職責，擁有該角色，即擁某個業務鏈路的審批權；
角色，一個人可以有擁有多個角色；
員工繼承職位上的所有角色，職位上的角色從部門選，部門上的角色從角色池選；
一個員工可以出現在多個組織中，一個員工的權限=∑組織數據邊界 ∑角色入口邊界。
3.4 實務採坑及產品的打怪升級策略
坑1：權限體系規劃中總部的職能崗未掛入虛擬公司與實務中職能崗也做單子的數據統計漏洞。
產品解決策略：將歷史數據統一簽入到新設立的總部虛擬公司中。
坑2：CRM模塊的權限管控體系是基於我們的SaaS-ERP平台，而SaaS平台的數據邊界是基於組織管理，後期公司成立事業部，出現A公司的運營部同步管理B公司的CRM，以及員工A同時管理B,C兩個團隊。後期權限升級為支持基於員工的跨組織數據邊界復權，但當某組織下面新增子部門、子團隊時，已復權的員工看不到新增子部門子團隊的數據，必須手動再次賦權。
產品解決策略：創建子公司、部門、團隊時自動觸發復權引擎進行復權更新。
坑3：前面提到，我們的脱敏場景涉及，早期我們通過一個角色編碼來控制，是否可見敏感信息，實務中不同崗位，訂單不同階段對敏感信息的控制是不同的，也即會有X*Y*Z種組合。
產品解決策略：我們通過擴增“脱敏角色編碼” “業務場景調用脱敏API”來快捷響應業務多變的需求。
坑4：當我們用上述方案時，隨着時間推移，人員調崗等，我們不清楚權限的分佈，不清楚某個角色都配給哪些人力。
產品解決策略：角色列表增加逆向查詢掛靠員工、強制解除角色、恢復默認角色。
四、數據中心-CRM報表-聯動作業產品架構設計策略 4.1 數據中心 VS CRM
以CRM工具為載體，將公司業績目標自上而下分解，政策有上向下落地，數據有下向上彙總是銷售管理的核心原則。一個好的CRM不光需要有業績報表、業績漏斗，還需要將業務體系的數據與CRM平台打通，將隔離的數據封裝為生產力工具，形成業務閉環。
數據中心的建設圍繞“泛運營”設計，強調規律、趨勢提取及策略設計和鏈路優化，側重宏觀轉化。
CRM的建設重心是圍繞“泛銷售”進行，強調逐一分層推進，側重微觀攻取。兩個團隊從兩個方向對用户進行圍剿，兩個團隊的協同關係可通過下圖來理解：
技術建設上，如果已有數據中心，那我們的CRM系統的建設可以做的更接地氣、更深入，而非像傳統CRM那樣只是單純的客户基本信息、訂單信息、線索質量、轉化率、業績考核，譬如我們的系統基於我們的數據中心，在CRM系統的建設山做了如下創新：
客户全情報信息：風險偏好、投資偏好、投資規律等客户交易行為數據、大數據徵信數據等；
業績設計更細膩：成單率與後期的壞賬率、逾期率掛靠，為“虛假業績”上緊箍咒；
人效分析更細膩：成單率與財務成本掛靠，客户的投資行為與每次交易的紅包成本聯動分析，透視員工開發、維繫客户的成本控制能力。
4.2 CRM業績設置系統
業績設置的產品設計，只要從如下幾個維度下手考慮，基本可以滿足所有業務場景：
設計原則1：組織鏈條自上而下分解目標；
設計原則2：時間鏈條：先年再季度再月度，最小到周度的目標分解：
設計原則3：變更修正冗餘考慮
設計原則4：修正審批制；
設計原則5：“實際-參照-完成度”對比查閲模式；
設計原則6：4大指標：成本-單量-規模-毛利指標；
設計原則7：3大參考：縱向歷史參考、橫向公司參考、內部同級參考；
篇幅原因：此處不展開講解，回頭針對業績設置單獨詳細行文與大家分享。
4.3 CRM業績報銷系統
有了業績設置，就需要對銷售的業績進行統計和告知，就需要對應的業績查看模塊，也即我們通常所説的銷售漏斗。大家可能會有疑問，上面的業績設置模塊中雖然已有業績查看，為什麼還需要業績查看模塊呢？
前者是給銷售看的，這裏是給銷售管理看的，側重點不一樣。如下為我們的”CRM-數據中心”業務聯動報表設計思想及可視化界面：
限於篇幅原因且圈裏CRM分享文章對此都有詳盡介紹，此處就不再多費筆墨。下面就我們的業績報表創新中踩到的一些坑抽之一二與大家分享一下，一個優秀的產品經理應該具備哪些嚴格的邏輯思維？如有時間，我將單開一篇數據報表方面的總結與大家分享我們在這方面的一些設計思想及實踐經驗。
分享點1：漏斗轉化率=A/B，當涉及客户重新分配時，邏輯設計策略分享：
場景1：銷售同一個月內在不同團隊之間流轉，如何記錄業績？
邏輯策略：以日為單位進行CRM工作數據落庫，以此來提取月度、季度、年度數據。
場景2：銷售管理團隊將客户甲從銷售A轉移給銷售B時，A的客户是減少還是不減少呢？團隊呢？
原則1：看轉移原因，如果是跟進無效，A的客户不減；如果是非跟進無效，A的客户要減，無論如何B的客户都要增加；
原則2：如果A和B在同一個團隊，團隊內的客户基數不減少，否則也看原因，見原則1；
分享點2：漏斗轉化率之場景深挖、業務吃透、概念萃取、知識解構的設計策略分享：
我們通過如下幾組概念來再次看下產品經理在“場景深挖”、“業務吃透”、“概念萃取”、“知識解構”方面的能力要求，如果我們概念都弄不清，在數據報表設計的源頭上就直接錯了，後面再想改就傷筋動骨：
靜態邀約數：統計週期內統計對象截止統計日末的邀約記錄數。
動態邀約數：統計週期內統計對象截止今日的邀約記錄數。
靜態邀約率：統計週期內統計對象截止統計日末的邀約率。邀約率=靜態邀約數/客户數。
動態邀約率：統計週期內統計對象截止今日的邀約率。邀約率=動態邀約數/客户數。
靜態簽約數：統計週期內統計對象截止統計日末簽約記錄數。
動態簽約數：統計週期內統計對象 截止今日的簽約記錄數。
相對靜態簽約率：統計週期內統計對象截止統計日末相對靜態簽約率。簽約率=靜態簽約數/靜態邀約數。
相對動態簽約率：統計週期內統計對象截止今日相對靜態簽約率。簽約率=動態簽約數/靜態邀約數。
絕對靜態簽約率：統計週期內統計對象截止統計日末絕對靜態簽約率。簽約率=靜態簽約數/客户數。
絕對動態簽約率：統計週期內統計對象截止今日相對靜態簽約率。簽約率=動態簽約數/客户數。
有了上述概念，我們是否很容易的回答如下問題：某一統計週期內的邀約轉化率如何計算？
場景1：統計週期內新增客户在統計週期內完成轉化；
場景2：統計週期內累計轉化量/週期內客户總量；
五、超大複雜組織業績提成系統：產品架構設計策略
提成系統屬於業績提成模塊的子場景，但如果想做好，十分考驗產品經理的功底。
由於我們的業務涉及理財團隊、貸款團隊、外聯團隊、用户邀請體系等不同返傭結算場景。同時貸款和理財兩個業務場景不像傳統行業譬如賣車賣樓，一單一提成這麼簡單，而是隨借款投資的期數動態聯動，由此會把提成系統的問題的複雜度指數倍放大，如果產品經理不深入瞭解業務，業務解構能力不強、邏輯思維不紮實，就會給技術團隊挖大坑。
5.1 業務場景解構
線上業績實時產生、線下業績非實時產生；
我們的業務是貸款、理財場景，比傳統行業的提成規則複雜——每筆訂單的提成不是一次性發放，而是隨用户的貸款期限/理財期限，按月計提、按月發放，如果用户提前還款或提前退出理財，提成系統需要終止；
員工離職，原客户交給新客户經理，提成計算規則如何來？
某天領導一拍腦袋，提成規則要變化，系統如何靈活應對？
某個業務違規，原計劃的提成要即刻終止，如何應對？
業務有4大類團隊，分別是銷售團隊、電銷團隊、集團全員返傭體系、外聯客户返傭體系，這4套體系的提成規則都不一樣？
處於避税考慮，提成既有線下發放，又有線上發放，系統該如何支持？
公司層面，希望提成能在體系內循環，走線上發放如何與體系內的理財業務聯動且員工不反感？
員工提成生效後、團隊提成、公司提成都生效後，當發現某筆業務違規時，整鏈條的提成調整策略及產品架構解決方案是什麼？
限於篇幅原因，此處不再累述，回頭單獨整理向大家分享。
5.2 業務需求抽象
普通員工：只享受自己客户的提成；
團隊負責人：享受自己直接的客户提成，以及該團隊下所有所有客户的提成；
部門負責人：享受自己直接的客户提成，以及該部門下所有所有客户的提成；
公司負責人：享受自己直接的客户提成，以及該公司下所有所有客户的提成獎；
外聯團隊自己開發的客户，返傭走“點差模式”，點差有外聯經紀人自行加點，返傭分一次性返傭和動態按期資產淨值返傭；
外聯團隊邀請的一度下線代理人，返傭走內部團隊負責人的團提模式，團提係數單獨設定，支持一人一系數；
平台用户邀請的一度客户，返傭走平台邀請模式：固定金額法、業績係數法，具體規則有運營團隊隨市場變化設定。
相關產品設計底稿：
六、SCRM-銷售單兵-移動作戰平台：產品架構設計策略
基於我們的行業特點，考慮到我們的銷售以外勤、串同行、線下作業為主，我們在外勤銷售開發了三個小程序矩陣，分別是“移動CRM”、“喜客小站”、“喜客電子名片”。
“喜客小站”電子名片工具主要覆蓋如下四個場景：內容、獲客、數據、客户管理，解決銷售朋友圈後的流量閉環和精細化經營問題。至此我們為銷售提供瞭如下單兵套裝：
高質量的線索：帶有雷達探針的市場活動 CallCenter清洗數據；
全情報雷達：基於數據中心的客户全維度信息提取及用户畫像；
轉化推進器：CRM跟進管理工具，如跟進工具、提醒工具、拜訪工具、知識庫工具、合同工具等；
私域流量工具：內容生產 朋友圈安裝雷達 數據魔方 CRM互通；
6.1 在系統架構設計上，我們做了如下兩個策略
策略1：概念解構、鏈路梳理
業務梳理1：我們的業務既有理財又有貸款，既有線上理財、又有線下理財，三者之間存在交差轉化場景，並且這種交差轉化是通過銷售撮合完成的。而我們的銷售受限與公司的管理要求，必須在CRM系統上完成客户的跟進維護，業績設置、業績透視及提成結算，而銷售自己又用自己的朋友圈做產品推廣和知識普及。
我們可以從上述業務背景中提取出三組概念：用户、客户、粉絲概念。
通過萃取這些底層概念，盤活銷售私域流量的方法就非常清晰了：即我們如果想做客户，必須擴大我們的用户，擴大用户有兩個方向：一是存量用户的行為識別，而是增量用户的擴大。
策略2：SAAS架構
如果用户的登錄手機號是SaaS內部在職員工，系統自動將其路由為SaaS-CRM平台的權限，產生的數據進入組織內循環，一旦離職，數據留給組織。
如果登錄賬號是自然人，系統自動為其開通自然人賬户，如果某天該用户進入某個組織上班，而該組織恰好也用了我們的SaaS系統的CRM功能，基於時間維度，歷史數據依舊歸私有，新發生數據看用户走哪個路由邏輯。
策略3：工具矩陣
電子名片工具可以與CRM獨立使用，也可以合併使用，數據互通依賴客户授權手機號做自動匹配，通過自帶“SNS層面的數據魔方”，方便銷售對私域流量進行精細化經營，並最終將客户數據及客户轉化關係推進到“傳統CRM”概念層級管理。
6.2 移動CRM工具
部分場景：
6.3 電子名片、內容工具、數據魔方
七、SaaS平台下的CRM柔性開發、實踐覆盤
我們不是專業的CRM廠商，CRM系統並非我們的主業，我們的CRM平台建設是在我們的理財平台和SaaS-ERP信貸審批平台建設中因業務需要而設的一個分支。
建設之初並未將其提升到戰略角度，投入重兵力建設，而是根據業務需要，以小團隊、敏捷式的策略，進行分段梯度建設。
與專業CRM廠商相比，在易用性方面、在配置擴展方面又不少需要改進地方，但在業務的理解、CRM系統與ERP、OA、數據中心的深度整合上，我們有自己的系統設計和考慮，並且這些考慮和解決方案都很接地氣，是CRM系統從千篇一律到專業賦能進化的一種產品致敬！
7.1 建設歷程
階段1：數據中心：用户數據、業務數據、紅包數據、交易數據等業務報表等；
階段2：貸款端CRM：客户管理-跟進管理-公海-轉移等；
階段3：CRM-CallCenter：新增坐席設計、接入第三方CallCenter、來電彈屏、羣呼配套工具等；
階段4：CRM-業績報表：業績設置-業績報表-提成審批等；
階段5：理財端CRM：與貸款業務場景不同，相關詞典庫不一致、客户用户業務打通等；
階段6：移動端CRM：移動平台、日程管理、任務管理、消息管理等；
階段7：銷售私域流量工具：電子名片工具、數據魔方等。
7.2 覆盤之缺點
大家都未做過CRM，除了缺經驗外，我們的CRM承載的期望和支撐的業務場景缺非常龐大，整個項目全憑產品的底層硬功夫支撐，過程中產品團隊吃苦很大，當然也採了不少坑。
我們的CRM非一般的複雜，不少場景雖然想透了，策略也有了，但研發資源拿不出，方案被迫做縮減，產品前期做了不少妥協，有時候很無奈，時間和資源不允許，只能做方案瘦身——不過我很享受這個過程，B端業務和C端業務不一樣，考慮全的瘦身和不考慮的簡化完全是兩個概念。
早期版本中未將客户狀態與商機分拆，導致客户在循環業務體系下的狀態處理比較被動。
由於缺乏經驗，未能在一開始在產品架構層面規劃客户場景以及與之相配套的“狀態詞典庫”、“產品詞典庫”、“來源詞典庫”、“等級詞典庫”等相關詞典的自動化配置。
7.3 覆盤之優點
相比市面上可花錢購買的CRM，我們的CRM除了在交互上弱以外，實用性和業務支持能力更強。
相比市面上可花錢購買的CRM，公司的數據更安全。
敏捷開發，效率高，成本低，由於我們底層搭的好，很多模塊是可以服用的，如：權限模塊、訂單模塊、回款模塊、任務管理模塊、消息通知模塊等。
能夠快速滿足業務需求、每個版本大概投入3人，2周開發、1周測試，6、7期時投入前端開發工程師。
副產物複用，如：日程管理、績效考核表、成本分析表、私域流量工具、列表定製、搜素定製等新交互引入。
人才鍛鍊和知識沉澱及技能提升——可能我們的交互很low，但我們的產品業務邏輯梳理、深層問題剖析、概念解構萃取、邏輯策略設計、產品架構處理、敏捷迭代打法等一系列想法和知識體系得到實踐的正向檢驗和有效提升。
最後向大家分享一下我們平台的CRM全系知識圖譜，圖片太大，只能單獨下載。
鏈接:https://pan.baidu.com/s/1GC27ZJNVZxEuNnZau2Hcqw 密碼:xvv8