中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

CRM是一個經久不衰的話題，對于它也有眾多討論。產品經理在工作當中也時常會碰到，但是CRM的真面目你真的了解嗎？本文從七個角度對CRM知識，并對其在工作中的實際應用展開分析，希望可以幫到對CRM有疑惑的童鞋。

CRM這個話題很古老，圈子里關于CRM的分享也很多。有從“權限設計角度”講的、有從“線索-客戶-商機”設計角度講的、有從“數據報表”角度講的，有從運營角度講的、有從銷售角度講的……

這些分享都很不錯，可以快速建立起知識體系，但總是覺得這些分享多是從已實現的角度做個結論性的分享、缺少從底層原理的剖析、以及為什么要這樣做的探討？

我們大家會有一個普遍的感覺是，這些文章讀起來很爽，但要再達到一個高度，或者說自己下手設計或運用CRM的過程中，因不清楚底層的基本原理，機械的理解會導致如下兩個問題：

1. 產品經理應該充分理解、充分提前預見、并在產品層面梳理出合理的解決方案，幫助團隊化解研發風險、幫助企業提升研發效能、幫助運營部門靈活高效運用落地的，但因淺嘗輒止、囫圇吞棗、機械理解、以貓畫虎，不清楚底層原理，給團隊挖坑多。
2. 看文章會導致我們機械的照搬市面上千篇一律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設計重心圍繞“銷售管理”、“銷售執行”兩條線進行?；阡N售轉化漏斗，我們在不同的節點開發了不同的工具矩陣來服務“銷售執行”、“銷售管理”：

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業績報銷系統

有了業績設置，就需要對銷售的業績進行統計和告知，就需要對應的業績查看模塊，也即我們通常所說的銷售漏斗。大家可能會有疑問，上面的業績設置模塊中雖然已有業績查看（圖4），為什么還需要業績查看模塊呢？

前者是給銷售看的，這里是給銷售管理看的，側重點不一樣。如下為我們的”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（理財場景/B端場景）：與貸款業務場景不同，相關詞典庫不一致、客戶用戶業務打通等；

階段6：移動端CRM：移動平臺、日程管理、任務管理、消息管理等；

階段7：銷售私域流量工具：電子名片工具、數據魔方等。

7.2 復盤之缺點

• 大家都未做過CRM，除了缺經驗外，我們的CRM承載的期望和支撐的業務場景缺非常龐大，整個項目全憑產品的底層硬功夫支撐，過程中產品團隊吃苦很大（成長很多），當然也采了不少坑。
• 我們的CRM非一般的復雜，不少場景雖然想透了，策略也有了，但研發資源拿不出，方案被迫做縮減，產品前期做了不少妥協，有時候很無奈，時間和資源不允許，只能做方案瘦身——不過我很享受這個過程，B端業務和C端業務不一樣，考慮全的瘦身和不考慮的簡化完全是兩個概念。
• 早期版本中未將客戶狀態與商機分拆，導致客戶在循環業務體系下的狀態處理比較被動。
• 由于缺乏經驗，未能在一開始在產品架構層面規劃客戶場景以及與之相配套的“狀態詞典庫”、“產品詞典庫”、“來源詞典庫”、“等級詞典庫”等相關詞典的自動化配置。

7.3 復盤之優點

• 相比市面上可花錢購買的CRM，我們的CRM除了在交互上弱以外，實用性和業務支持能力更強。
• 相比市面上可花錢購買的CRM，公司的數據更安全。
• 敏捷開發，效率高，成本低，由于我們底層搭的好，很多模塊是可以服用的，如：權限模塊、訂單模塊、回款模塊、任務管理模塊、消息通知模塊等。
• 能夠快速滿足業務需求、每個版本大概投入3人（PM-后端-測試），2周開發、1周測試，6、7期時投入前端開發工程師。
• 副產物復用，如：日程管理、績效考核表、成本分析表、私域流量工具（可脫離SaaS賬戶體系獨立使用）、列表定制、搜素定制等新交互引入。
• 人才鍛煉和知識沉淀及技能提升——可能我們的交互很low，但我們的產品業務邏輯梳理、深層問題剖析、概念解構萃取、邏輯策略設計、產品架構處理、敏捷迭代打法等一系列想法和知識體系得到實踐的正向檢驗和有效提升。

最后向大家分享一下我們平臺的CRM全系知識圖譜，圖片太大，只能單獨下載。

鏈接:https://pan.baidu.com/s/1GC27ZJNVZxEuNnZau2Hcqw 密碼:xvv8

作者：九天牧人，個人微信unifarm

本文由 @九天牧人 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議