整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
面向對象語言中 this 表示當前對象的一個引用。
但在 JavaScript 中 this 不是固定不變的，它會隨著執行環境的改變而改變。
在方法中，this 表示該方法所屬的對象。
如果單獨使用，this 表示全局對象。
在函數中，this 表示全局對象。
在函數中，在嚴格模式下，this 是未定義的(undefined)。
在事件中，this 表示接收事件的元素。
類似 call() 和 apply() 方法可以將 this 引用到任何對象。
在對象方法中， this 指向調用它所在方法的對象。
在上面一個實例中，this 表示 person 對象。
fullName 方法所屬的對象就是 person。
單獨使用 this，則它指向全局(Global)對象。
在瀏覽器中，window 就是該全局對象為 [object Window]:
如果單獨使用，this 也是指向全局(Global)對象。
在函數中，函數的所屬者默認綁定到 this 上。
在瀏覽器中，window 就是該全局對象為 [object Window]:
嚴格模式下函數是沒有綁定到 this 上，這時候 this 是 undefined。
在 HTML 事件句柄中，this 指向了接收事件的 HTML 元素：
下面實例中，this 是 person 對象，person 對象是函數的所有者：
* this.firstName 表示 this (person) 對象的 firstName 屬性。
在 JavaScript 中函數也是對象，對象則有方法，apply 和 call 就是函數對象的方法。這兩個方法異常強大，他們允許切換函數執行的上下文環境（context），即 this 綁定的對象。
在下面實例中，當我們使用 person2 作為參數來調用 person.fullName 方法時, this 將指向 person2, 即便它是 person的方法。
TML自學視頻教程（p20）:
2.3.3設置作者信息
在頁面的源代碼中，可以顯示頁面制作者的姓名及個人信息，這可以在源代碼中保留作者希望保留的信息。
語法格式：
<meta name="author" content="作者的姓名"在該語法中，name為屬性值，這里設置為author，也就是設置作者信息，在content中定義具體信息。
實例代碼：
<html>
<head>
<title>設置頁面描述</title>
<meta name="keyword" content="html,元信息，關鍵字">
<meta name="description" content="關于HTML的使用">
</head>
<body>
</body>
</html>在這一實例中，將作者姓名“王小力”添加到了網頁的源代碼中。
輯導語：CRM是什么？怎樣了解和制作CRM業務架構俯視圖？本篇文章從作者親身經歷出發，從CRM的概念到CRM業務架構俯視圖，再到CRM重構，全面完整地講述了CRM，希望能給大家幫助和啟發。推薦感興趣的朋友們閱讀。
進入到這篇文章的朋友，大概率應該都是CRM領域的相關工作者，以及對CRM感興趣的同學。
自本篇文章開始，我想基于我之前CRM系統的重構經驗，講下我理解的CRM系統，以及我理想的CRM營銷形態。
未來路很長，還需要繼續前進。
在大家剛接觸這個領域的時候，肯定會有這樣的問題：CRM到底是什么？ 為啥市面上很多CRM文章講的內容天差地別？
在我接觸的領域看來，CRM有兩個定義：
字面意思即客戶關系管理（Customer Relationship Management），起源于企業為了提高核心競爭力，保持與客戶的長期穩定關系，誕生了這個理念。
由1999年Gartner Group Inc公司提出。Gartner Group Inc在早些提出的ERP概念中，強調對供應鏈進行整體管理。
基于CRM理念誕生的業務承載系統，可以叫做CRM解決方案，這個概念意味著CRM不僅僅是一個單一的系統，而是多個系統的結合。
第二個定義也是大多數CRM產品同學的實際工作內容。不同的公司業務，系統的表現形式也會不同，這也是開頭提到為啥市面上介紹CRM文章的內容會天差地別。（有的公司CRM是個筐，什么都能往里裝……）
比如大型制造商，供應鏈的業務，CRM會側重于和ERP相關系統的聯動，關聯采購計劃，生產計劃等等；又比如k12線上教育的業務，CRM會更注重線上客戶的投放獲取，排課排班等；而換成酒店，就又變成房型調整偏好，早餐偏好之類。
在商業流程上，企業要走完一個“獲客-留存-轉化”的核心漏斗，這個漏斗也是CRM建立系統的根基。
但企業發展迭代的過程中，會逐步向兩頭擴展膨脹：
本文也是基于這個大的商業邏輯下展開，研究理想的CRM方案可以發展成什么樣。同時也跟大家限定一下討論范圍，我的工作經歷此前更集中在互聯網在線教育，所以CRM中的風格，會更接近在線教育的模式，其他行業如制造業，零售業的CRM，我暫時無法去還原到細節，所以本系列文章不會討論太偏實體行業的內容。
我是學地球物理出身，那么用我的思維方式，從一個新的視角帶領大家去觀察了解，以便從不同角度碰撞出更多的火花。
首先，從最高的高度看：
姑且定個高度值叫1000吧，這個高度看不清地面細節，只能看清地貌。可以看出一個CRM解決方案的理想態都包含了哪些大山峰。
最視覺中心的部分，叫CRM銷售域，這是銷售的核心工作場所，也就是日常工作中提到的CRM系統。圍繞CRM系統周邊的支持系統，我用比較淡的顏色弱化了，突出一個主次的關系。
我們先對高度1000的業務架構，有個比較宏觀完整的認識，然后就繼續下降高度。
高度500在下降到500的高度時，細節逐漸豐富，可以看清各個山峰上的地形地貌。也就是各個系統包含的具體功能。
我依次從左上角開始，順時針介紹：
（1） 大數據系統
作為大數據營銷方案的基礎設施，提供一些基礎的數據統計，挖掘，查詢，用戶標簽等一些數據層面的服務。
（2）HR系統
這里的HR就是和CRM銷售域聯動的，因為銷售也是員工，在CRM銷售域里的賬號都要和HR系統關聯，如果離職了，CRM這里也會不允許登陸。
（3）電商系統
銷售成單時必須用到的系統，可以給學員創建訂單，查詢商品信息，調整價格，讓學員支付。
（4）學習系統（或其他主業務系統）
此為只讀關系的系統，CRM并不會干預學員的學習過程，而是可以通過學習的行為，來知道學員的實際情況，作為后續復購時的話術參考。同時，學習系統里的學習數據可以作為大數據系統加工標簽使用。
（5） CRM營銷域
重點模塊，它承擔了獲客漏斗的開頭獲客部分，沒它也就沒后續。
營銷域不僅僅是有花錢的模塊，如SEM投放，信息流投放等。也有盡量不花錢的模塊（成本相對很低），如SEO，CMS相關內容主要的功能，就是負責把營銷獲客所用到的一系列支持，都集成在了這里。這里也是一個我的劃分，實際上公司里的投放系統是散列分布的。
「引申」：
SEO是搜索引擎優化，通過對自身內容三要素TKD的優化，T為內容標題Title，K為內容關鍵詞Keyword，D是Description。
因為搜索引擎想做頁面的排序，實際還是根據頁面內容渲染后的HTML來識別，靠的就是這三要素，讓搜索引擎把你的內容根據相關程度排到前面，獲得更多的曝光，達到引流目的。
SEM是競價廣告投放，在用戶主動搜索內容時，人找內容，搜索引擎根據關鍵詞相關程度，以及你投放的關鍵詞還有你和別人在此關鍵詞下的廣告出價，綜合得出一個排序，讓你獲得對應的曝光，引流。
信息流也是投放，但場景是內容找人，主動分發，根據你在對應平臺上的畫像標簽，推你對應標簽匹配度更高的廣告內容，促成曝光或者交易。
（6）外呼中心
銷售在給學員打電話的時候會用到，包含了線路，號碼資源，坐席等相關模塊。后面還會單獨介紹。
（7）在線對話系統
還記得在瀏覽某些網站的時候，有流氓的彈窗嗎？這個彈窗就是在線對話系統，通過這個在線對話，可以索要到客戶的線索，后面還會單獨介紹。
（8）短信平臺
銷售私人用的頻率較低，多數使用場景是大批量發送營銷短信，敏感交易觸發通知短信。包含了短信通道，短信模板，敏感詞管理。
（9）CRM客戶域
這個客戶域，其實算是業務迭代過程中的一個產物。如果一個公司起初沒有所謂的注冊功能，那么他們會收到電話就算做一個線索，也可以叫做名片。慢慢的公司從流量時代進入到用戶時代，需要在用戶主動注冊的情況下才能使用產品或者服務，這就產生了兩個集合：一個集合是未注冊只留咨的客戶，另一部分是留咨又注冊的用戶，兩個集合無法合并，這個客戶域就產生了。客戶域的誕生也是有好處的，可以進行客戶標記標簽，然后進行深度的個性化服務，精細化運營，深度推薦等。
（10）CRM銷售域
也就是解決方案中的核心部分，承擔了銷售工作的大多數能力如名片庫，商機庫，流轉規則，商機調度引擎，形成了線索分發的能力銷售工作臺，質檢工作臺，為銷售和質檢人員提供了各自高效工作的場所組織機構管理，角色管理，數據授權管理，為系統層面的用戶權限配置提供了基礎元數據管理，是體現在系統中的各個下拉菜單的選項，還有配置項等的管理外呼接口管理，就是方便和外呼系統聯動，快速響應外呼系統的調整。
以上就是高度500的系統介紹，接下來……
繼續下降到100：
下降到100，接近地面了，能看清具體地面上的道路鏈接。
為了釋義清楚又不至于細節迷了眼，我就簡單的把一些核心的邏輯用連線鏈接了。
在高度100的時候，其實就是接近業務運行動作的高度了，可以看到每個系統中各個模塊之間的交互關系，如何調用。
如果繼續下降到高度0，效果就是每個頁面具體做什么動作，填什么信息了，這里就不再贅述。
以上，就是我理想中的CRM解決方案，不僅僅局限于CRM系統，而這個理想的方案，在之后的產品設計里也比較順利的落地。具體落地結果我會放到下一篇文章去細講。
作為一篇鋪墊的文章，我也講下為什么會設計這種方案。
首次接觸CRM是一次工作交接，剛接觸的時候比較無知，并不知道這個系統有多么的重要，因為當時無研發維護，只有我一個產品，臨時借調了一個研發，產品留下的文檔也是簡單寫了兩句，所以產生了不重要的想法。
直到我開始慢慢接觸銷售業務，才知道公司層面的核心商業邏輯，對我的成長是很用幫助，苦不是問題，認知的收獲才重要。
當時公司層面的想法，是CRM系統已年久失修，銷售提的新需求無法滿足，老板的想法也無法落地，而且銷售又是公司營收貢獻的重要組成，所以就有了重構的念頭。
重構就是基于上面的俯視圖，從CRM銷售域開始重新設計，并在穩定之后逐層外展，重構外圍系統的秩序。
作為一個B端的業務系統，CRM重構的流程會相對復雜，需要經過比較長的調研與決策，有如下環節：
BOSS提出想法——業務系統現狀調研——業務核心領導調研——產品設計——BOSS評審——業務領導評審——（循環到產品設計）——研發——測試與上線——切換與實施
這個流程不是通用模板，但組織復雜點的公司都會走過這些環節。
BOSS看到CRM中有大量的商機被閑置，同時又有很多銷售囤積了巨量的商機等待自然孵化，同時又有很多銷管銷控的手段無法通過系統直接傳達，認為系統阻礙了業務發展，降低了產能，所以期望讓新的系統實現以下3個效果：
在這個大需求背景下對產品進行設計，接著就進入到了業務調研環節。
宏觀上，我并沒有只調研銷售，還調研了其他的部門，得到一個相對完整的業務流程框架，這個流程包含了不同的分工和角色。
在業務視角下，營銷流程是這樣的：
流程從前到后，依次如下的職能：
除以上羅列的這些職能，還有各個教研，項目等，充分了解各個業務職能的工作內容，立場，有利于更全面的了解業務現實。
至于業務調研方法，可以在網上搜索，資料很多。
不過有個點要強調：B端內部業務，并不是簡單用數據統計和問卷就能得出具體結論的，需要找到各條線的核心人員深度當面溝通，公司由人組成，人會有能力的區別，有價值觀和立場的區別，都需要在調研的時候深度感受，而且不能只是聽他們說什么，還要看他們真的做什么
在基本了解全面之后，就進入到了競品調研和產品設計。
B端的業務系統，網絡上很難找到資料，能找到的，也基本都是SaaS類的廠商。
在調研了市面上十幾家廠商之后（名字就不寫了，容易引戰），有這么幾個總結：
另外，B端的普遍心理，就是爹有媽有不如自己有！無論如何我都不能讓自己業務的部分受制于人，更何況是核心業務。
通過這些總結，以及業務訴求，我們最終決定自建。
作者：羅文正雄；公眾號：羅文正雄
本文由 @羅文正雄 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Pixabay，基于 CC0 協議
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
