本文筆者将通過分析Salesforce的設計邏輯和思路，從其中總結出CRM系統的設計邏輯，以及在設計中應該注意的一些問題。

最近由于工作所需，為公司的銷售團隊設計了一套内部使用的CRM銷售管理系統。

為了設計好該類型的産品，特地去研究并分析了該領域的巨頭産品——Salesforce，通過分析該産品的設計邏輯和思路，對自己的産品産生一起啟發和思考，并且在實際設計過程中面臨的一些問題也同時分享出來，以期給大家一些啟發。

為什麼是Salesforce

對B端産品接觸較少的人可能對Salesforce不太了解，但是隻要涉及到B端，一定會提到Salesforce這個B端領域的巨頭，特别是國内的B端産品或多或少都收到Salesforce的影響。

根據互聯網女皇瑪麗·米克爾最新發布的2019年互聯網趨勢報告：Salesforce公司以1250億美元市值牢牢占據B端領域市值第一的地位，并且在全球互聯網企業市值中排名第11位，力壓我們熟知的Uber、Booking、美團、百度等公司。

是什麼支撐起了Salesforce如此高的市值？

抱着研究和為自己産品找想法的目的，試用了Salesforce的免費試用版，順便說一句Salesforce提供長達30天的免費試用期，并且開放所有的功能，足以看出Salesforce的自信和開放程度。

Salesforce總體的設計邏輯

由于Salesforce已經是一個非常完整的生态，涉及到企業的方方面面，因此本文隻分析Salesforce的CRM，及銷售管理系統。Salesforce整個産品的設計是任務和目标導向的，從主頁的設計就可以看出，Salesforce在分析公司時，采用如下的公式：

業務流=目标 任務

先制定整體的業績目标，然後目标通過時間段拆解成每個階段甚至每天的任務，任務則可以拆解成具體的客戶，而客戶又來源于漏鬥：潛在客戶→業務機會→聯系人→客戶。

如下圖所示：

通過這種方式，Salesforce将不同公司的銷售業務都抽象出共通的模型，從而設計更加通用的形式。不得不說，Salesforce對業務的拆解比國内大多數同類型公司更加細緻和用心。

從菜單導航看Salesforce對銷售進程的理解

首先看菜單欄，和一般同類型的産品相比，采用比較少見的橫向菜單布局，從視覺上對用戶更加友好。

并且，每個模塊下拉菜單都隻有新建或者曆史記錄兩欄。對比國内的CRM産品會在下拉菜單中加入很多子欄目，Salesforce設計更加簡潔，盡量把功能都放在一個頁面裡，通過合理的布局讓用戶減少點擊的操作步驟。并且，當用戶習慣了該産品之後，會發現想要新增内容會非常方便快捷。因為新增對于銷售是一個比較高頻的需求，不管是新增客戶還是任務等。

從菜單導航設置來看，Salesforce對整個銷售的各個進程考慮的非常全面。

從客戶設置就可以看出，Salesforce将客戶分成客戶、聯系人、潛在客戶。

從功能設計可以看出，三者的區别是：客戶是已經确定有交易關系的主體，而一個客戶會對應多個聯系人——即一家公司會派出多個員工和其他公司接觸。比如會從一般的業務人員到部門領導甚至到公司高管，Salesforce充分考慮到現實商業接觸中多層級的接觸模式，因此這方面考慮的還是非常細緻的。

如下圖所示：

潛在客戶則是和公司沒有确定正式的合作關系，但是已經有初步接觸有發展成客戶前景的其他公司。

由于公司剛接觸的時候往往隻會派一個人進行初步接觸，所以這裡沒有設計多個聯系人情況。當和潛在用戶接觸時，Salesforce對該類型事件主要抽象成兩個模塊：進程狀态和任務事件，這也符合絕大多數公司做市場時候的需求。

Salesforce提供儀表闆的功能來監控業務指标和分析銷售進程，這也是國内CRM産品比較少使用的形式。

在儀表闆中，Salesforce關注的數據指标主要包括：每個階段的銷售額；salesforce定義的銷售階段包括：qualification（可以理解成接觸階段）、need analysis（評估階段）、negotiation（協議階段）、closed won和closed fail（交易成功和交易失敗），以及交易成功和交易失敗的客戶來源和具體客戶。可以看到，也是以完成業績目标為導向，來分析完成和失敗的原因。

總結

總結一下：Salesforce在設計CRM産品時，首先從大的維度定義産品要實現的目的，在這裡就是完成業績目标，然後通過将目标拆成每階段的任務——就是獲得足夠多的客戶數量。

而客戶則來源于層層的轉化，通過這種方式，産品的邏輯和架構逐漸清晰，也為接下來設計自己的産品提供了思路。

設計自己的CRM産品

1. 如何分析并找到核心需求？

既然分析完了Salesforce産品，為什麼要先分析需求？

首先，上述的Salesforce産品，是分析了大量公司真實的業務需求，包括其他産品的思路，從而提煉出最核心的需求設計成這種形式。因此，設計産品的核心還是要從需求出發，分析并找到核心的需求，才能找到真正的高效的業務流轉方式。

B端産品需要和大量的一線業務人員溝通需求，确定他們的痛點和難點，而由于這些業務人員大多是從自己的視角出發，一碰到問題就容易産生新的想法，因此這種需求往往是“拍腦袋的”。

而作為産品經理，需要根據業務人員所說的需求抽絲剝繭，找到需求的共同點，從而提煉出核心需求。B端産品面臨的難點往往是定制化和通用性的取舍，一方面是要根據業務人員的實際需求設計産品，另一方面則需要抽象出通用和共同的東西，形成一定的通用性組件，從而實現産品的良好的可拓展性。

這裡推薦需求分析的PSP方法：即P（Person，角色）、S（Scenes，場景）、P（Paths，路徑），下面通過一條具體的需求來說明如何進行分析。

首先，這條需求非常不明确，主要體現在沒有說明如何錄入和查看哪些信息，這時候就需要和一線業務人員進一步明确，查看的是哪些客戶信息。

當明确完之後，需要确定錄入的方式是通過手動錄入，還是其他接口來自己導入，後續和小李溝通細化發現是通過上一步篩選出來的用戶。因此，可以通過對接上一步産品的數據庫，來實現數據的自動導入，并且增加手動錄入和修改的功能，防止數據有錯誤。

因此，該需求的核心點是：快速确定客戶信息，因此通過自動導入比手工錄入和批量錄入都更能解決問題。

同時，通過PSP方法，需要明确不同角色的使用場景和路徑。在該需求中，主要涉及到管理員、銷售兩種角色，錄入功能應該隻針對銷售，因為他們是距離客戶最近的人員，第一時間會了解到客戶的新的信息。而修改功能應該隻針對管理員，因為他們負責管理銷售，因此他們有權修改客戶的進程等相關信息。

2. 設計産品的過程中需要注意的三個問題

在确定完核心需求并确定了産品的基本架構和框架之後，接下來再具體設計過程中還需要時刻注意以下幾個問題，從而設計的産品有更大的合理性和可拓展性。

1）數據從哪裡來，到哪裡去？

乍一看很像哲學家蘇格拉底所說的“從哪裡來，到哪裡去”的哲學問題，但是這其實也是設計該類型産品的一個底層邏輯。

C端的産品數據是明确的來自用戶，而B端産品的數據往往來源于其他和系統和産品的傳輸，因此明确清楚系統的數據從哪裡來，以及如何流轉是設計該産品的第一步也是最基礎的一步。

拿自己設計的系統為例：由于本系統是針對客戶設計的銷售管理系統，因此最重要的客戶數據來自于H5和小程序收集的客戶信息，包括客戶自己填寫的手機号和其他基本資料。

因此，首先要和技術确定開發相關的接口去接收和傳遞數據到系統中。當數據進入到系統中後，要确定數據的流轉規則，也就是先後順序和對應關系，本系統采用的是三級分配的原則，也就是數據到最終的銷售和經過三層的分配，如下所示：

這種分配方式确實不夠快速簡潔，但是好處有一下兩點：

1. 方便組織管理以及職級分工，每個角色都有自己明确的數據邊界和範圍。
2. 方便客戶數據和銷售的1對多匹配。不同公司對客戶的跟進有不同的規則，比如有些公司規定是1個客戶對應1個固定銷售，單獨負責整個流程的轉化，而很多公司往往是1個客戶對應多個銷售，也就是當1個銷售轉化不順時往往會換一個銷售跟進，因此，這樣設計有利于客戶對應銷售的快速調整。

2）權限角色問題

權限與角色往往是該類型産品的一個重點，不過在設計權限角色之前，首先需要确定：權限角色實現的目标是什麼？

本質上來說，設計權限角色是為了讓不同的角色有不同的功能權限和數據權限，而兩者的區别如下所示：

因此，确定好不同角色對應的功能權限和數據權限後，會對不同角色的菜單設計和頁面設計産生影響。

舉例來說，上圖中的角色1是偏管理員的角色，因此展示給他的菜單欄包括了人員配置的功能，而其他角色就不應該展示該功能，如下圖所示：

（角色1）

（其他角色）

3）哪些部分應該模塊化？

最後，在具體設計功能時，需要考慮如何把關聯性較強的功能或需求放在一起，從而實現系統的模塊化，達到“松散耦合”：各模塊内部的功能緊密聯系，同時各模塊直接既有一定的關聯又保證一定的獨立性，從而有利于未來系統的擴展。

拿自己做的系統舉例：

在做的過程中碰到的一個問題是：數據統計功能應該放到各個模塊中，還是單獨用一個模塊整體展示？

因為很多模塊都有數據統計的需求，并且統計的時間維度和字段都有不同，因此比較糾結到底采用什麼形式。最後，還是從系統可拓展性的角度，把數據統計單獨做成一個模塊，方便未來在模塊展示更多的數據分析相關功能。而對于不同模塊的數據統計如何統一？

這需要對整個業務抽象出更底層的信息，找到最關注的幾個數據指标，最後進行整合，整合前如下圖所示，數據指标較多并且比較零散。

整合之後，把總體數據和時間維度的數據通過一個時間篩選器進行篩選，使得數據的靈活性大大增加，更加聚焦于核心指标，如下圖所示：

最後，整個系統的模塊大緻是如下形式，便于後期更加靈活的拓展。

本文由 @woer 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部