很多時(shí)候，我們可以從一些需求中深挖出不一樣的東西。這篇文章里，作者講述了自己在 CRM 領(lǐng)域中遇到的一個(gè)優(yōu)化需求，一起來(lái)看看本文所延伸的系統(tǒng)功能思考。
前段時(shí)間 CRM 關(guān)于客戶申領(lǐng)遇到了一個(gè)優(yōu)化需求。希望申請(qǐng)后審核通過(guò)的可以直接變成保護(hù)狀態(tài)（在待營(yíng)銷中的客戶）。
前情概述：
如正常的 CRM 系統(tǒng)規(guī)則，客戶在一定時(shí)間內(nèi)沒(méi)有進(jìn)展是會(huì)掉入公海的。
在新制度出來(lái)前是沒(méi)有客戶等級(jí)這個(gè)概念，于是營(yíng)銷可以任意申領(lǐng)客戶。
新制度出來(lái)后，公司根據(jù)類型和規(guī)模劃分了等級(jí)，針對(duì)已經(jīng)保護(hù)中的客戶是不受新制度約束，如果掉入公海或者新建一個(gè)新的客戶是要受新制度的約束。
如果營(yíng)銷沒(méi)權(quán)限去保護(hù)就要走申領(lǐng)這一步操作，需要相關(guān)管理人員進(jìn)行審核，通過(guò)后才能保護(hù)繼而營(yíng)銷。
之前因?yàn)橹贫认嚓P(guān)的功能都在另一套管理系統(tǒng)，而客戶相關(guān)的在 CRM 系統(tǒng)，分屬不同的產(chǎn)品管理。因此在最終方案上有瑕疵，各做各的，只是最后把數(shù)據(jù)同步了。
那么就出現(xiàn)了一個(gè)問(wèn)題，營(yíng)銷從公海中想要申領(lǐng)這個(gè)客戶，但是呢提示沒(méi)有權(quán)限，需要去管理系統(tǒng)中申請(qǐng)客戶資源，等營(yíng)銷去管理系統(tǒng)申請(qǐng)客戶資源之后，由相關(guān)人員進(jìn)行審核，通過(guò)后，營(yíng)銷需要再次去公海進(jìn)行申領(lǐng)。因此全部流程只是做了資格權(quán)限的申請(qǐng)而已，不是客戶的直接申領(lǐng)。顯然這中間就多余了操作步驟。
現(xiàn)在系統(tǒng)歸到了一位產(chǎn)品手中，為了解決上述問(wèn)題，我們展開(kāi)了討論，如何去解決這個(gè)問(wèn)題。
從上述描述來(lái)看我們可以看到營(yíng)銷在 CRM 中申請(qǐng)客戶，但是只是告知了沒(méi)有權(quán)限，之后再無(wú)下文，這是斷檔 1。
營(yíng)銷去管理系統(tǒng)申請(qǐng)并審核通過(guò)后，也只是獲取了資格，沒(méi)有形成有效的保護(hù)，這是斷檔 2。
這中間其實(shí)還引申了另一個(gè)問(wèn)題，我們申請(qǐng)的這個(gè)客戶之后是這個(gè)客戶的全部條線產(chǎn)品還是單一條線產(chǎn)品還是單個(gè)產(chǎn)品，這個(gè)我們放后面說(shuō)。
既然現(xiàn)在是一個(gè)產(chǎn)品來(lái)負(fù)責(zé)了，那么我們可以將系統(tǒng)歸集起來(lái)，因此這里又引申出兩個(gè)問(wèn)題。
營(yíng)銷申請(qǐng)是在哪申請(qǐng)（CRM 還是管理系統(tǒng)）？
審核是在哪里審核（CRM 還是管理系統(tǒng)）？這里還有一個(gè)小問(wèn)題，審核的人和層級(jí)是否可變，是否需作配置？
帶著這些問(wèn)題，我們按照優(yōu)先級(jí)來(lái)規(guī)劃下項(xiàng)目的迭代版本。
因?yàn)檎w的功能已經(jīng)有了，只是如何把這些功能串起來(lái)，不做的話，人工操作會(huì)多一些，而人會(huì)有遺忘，操作越多，涉及系統(tǒng)越多會(huì)出現(xiàn)變數(shù)。
因此最優(yōu)先解決的是斷檔 2 中的問(wèn)題，因?yàn)闋I(yíng)銷去公海申請(qǐng)客戶，發(fā)現(xiàn)沒(méi)權(quán)限，知道要去哪里申請(qǐng)了，就去了，但是申請(qǐng)通過(guò)之后，可能沒(méi)來(lái)得及再次領(lǐng)出來(lái)，就被被人領(lǐng)走了，這就比較麻煩了。
因此我們的步驟 1 是審核通過(guò)后自動(dòng)將公海中的客戶轉(zhuǎn)為營(yíng)銷保護(hù)。那么這個(gè)客戶有多產(chǎn)品線多產(chǎn)品呢，是否全部保護(hù)？這個(gè)我們后面來(lái)講。
緊接著我們?cè)賮?lái)處理斷檔 1 的問(wèn)題，于是就有了步驟 2。步驟 2 要做的是當(dāng)營(yíng)銷去公海申請(qǐng)客戶的時(shí)候，提示沒(méi)有權(quán)限，順便詢問(wèn)是否申請(qǐng)，如果營(yíng)銷選擇申請(qǐng)的話，自動(dòng)在管理系統(tǒng)生成一天客戶申請(qǐng)的記錄，等待審核即可。
好，到了這里我們營(yíng)銷跨系統(tǒng)去申領(lǐng)客戶的動(dòng)作都給解決了，那么我們就要來(lái)解決審核到底在那個(gè)系統(tǒng)進(jìn)行。因?yàn)椴襟E 2 中已經(jīng)解決了申請(qǐng)?jiān)谠?CRM 自動(dòng)創(chuàng)建申請(qǐng)記錄。
這個(gè)我們就要看審核人是誰(shuí)，他們經(jīng)常使用什么系統(tǒng)進(jìn)行操作，于是又牽扯到了配置問(wèn)題。
那么步驟 3 就是我們的審核配置，因?yàn)榭蛻魰?huì)跨條線，而每條條線的負(fù)責(zé)人是不一樣的，除非是由公司的統(tǒng)一部門來(lái)審核，比如說(shuō)董事長(zhǎng)之類的，一般會(huì)下放到各條線負(fù)責(zé)人，畢竟他們懂自己條線的業(yè)務(wù)及知道目前處于什么情況是否可以由該營(yíng)銷人員進(jìn)行營(yíng)銷。
這里面就涉及到了我們申請(qǐng)客戶保護(hù)的范圍是什么？是全部（只要申請(qǐng)一次這個(gè)客戶，所有條線產(chǎn)品都可以申領(lǐng)）？是條線（通過(guò)后營(yíng)銷只能申領(lǐng)這條線下的產(chǎn)品）？還是產(chǎn)品（每次申領(lǐng)都是要申請(qǐng)審核的）？
那么這個(gè)問(wèn)題還是回歸到業(yè)務(wù)問(wèn)題，只是我們不能只聽(tīng)他們的，我們需要告知每種形式的優(yōu)勢(shì)和弊端。
第一種，全部的。那么這里面的優(yōu)勢(shì)顯然是一次操作眾生收益，不需要頻繁操作了；弊端也顯而易見(jiàn)，有些不該營(yíng)銷人員營(yíng)銷的就不好控制，以及如果是全部的話，那么由各業(yè)務(wù)線負(fù)責(zé)人審核這件事顯然也不合適，會(huì)起沖突。
第二種，條線范圍內(nèi)，這個(gè)是比較折中的，條線本不多，而且各自負(fù)責(zé)人都有，且對(duì)營(yíng)銷比較了解。弊端則是如果產(chǎn)品多，好的條線的營(yíng)銷都想去，也會(huì)出現(xiàn)大包大攬的現(xiàn)象，這樣就造成資源的浪費(fèi)了。
第三種，產(chǎn)品級(jí)，這是比較嚴(yán)謹(jǐn)?shù)模阋N售什么產(chǎn)品就申請(qǐng)什么產(chǎn)品，好管控，缺點(diǎn)在于每個(gè)產(chǎn)品都申請(qǐng)可能比較頻繁。
那么就要分析當(dāng)前營(yíng)銷的產(chǎn)品及每個(gè)客戶會(huì)用到的產(chǎn)品數(shù)量多寡來(lái)決定采用哪種方案。從當(dāng)前情況來(lái)看的話，采用第三種比較合適，首先每個(gè)客戶購(gòu)買的產(chǎn)品不多且固定，其次在申請(qǐng)的時(shí)候可以批量申請(qǐng)，不是一個(gè)個(gè)申請(qǐng)。這樣就能達(dá)到當(dāng)前階段最優(yōu)效果了。
當(dāng)然也有人說(shuō)，那么我以后變了呢？
如果變化不是很頻繁，幾年變一次的，直接硬編碼。如果想要做得更靈活多變的，那么做個(gè)配置，申領(lǐng)后是控制全部還是條線還是產(chǎn)品，這樣只需要把配置切換下即可，順便更改下審核人員，因?yàn)閺漠a(chǎn)品或條線切換到全部的時(shí)候，如果審核人員沒(méi)切換回來(lái)那么就需要默認(rèn)一個(gè)審核人或者只要申請(qǐng)的相關(guān)條線的負(fù)責(zé)人任意一個(gè)審核都行，這些都基于業(yè)務(wù)，我們提供參考建議。
最后一步就要確定操作放在哪個(gè)系統(tǒng)。那么這個(gè)其實(shí)是需要看操作人的，他們習(xí)慣在哪個(gè)系統(tǒng)中，不是說(shuō)這個(gè)功能是 CRM 相關(guān)的，就一定放在 CRM 中，如果審核人之前不需要使用 CRM 系統(tǒng)，那么勢(shì)必還會(huì)要給他配置權(quán)限以及審核人員出現(xiàn)系統(tǒng)來(lái)回切換的問(wèn)題。
當(dāng)我們分析到這里的時(shí)候，我們其實(shí)把版本迭代的順序都理順了，那么接下來(lái)我們?nèi)绾巫觯涂礃I(yè)務(wù)方的建議是否全套做還是按部就班以及看研發(fā)時(shí)間，來(lái)決定最終使用哪種方案來(lái)完成這部分的優(yōu)化功能。
在分析一個(gè)功能的時(shí)候，需要把這個(gè)功能的范圍放大了看，放在整個(gè)流程鏈路中去看他處于什么位置，會(huì)對(duì)這條鏈路有什么影響，還可以再放寬到整個(gè)系統(tǒng)中去看，這個(gè)對(duì)整個(gè)系統(tǒng)的影響，在不斷放大的過(guò)程中，我們會(huì)發(fā)現(xiàn)不一樣的問(wèn)題，這也是我們經(jīng)常做完了這個(gè)需求發(fā)現(xiàn)其他地方出問(wèn)題了。因?yàn)槲覀冎豢吹搅诉@塊內(nèi)容，沒(méi)有放大去思考。
就像歷史事件，我們?cè)诳吹臅r(shí)候，只知道這個(gè)時(shí)候發(fā)生了什么，沒(méi)有去看為什么偏偏在這個(gè)時(shí)候發(fā)生了?；蛘咧皇窃谶@個(gè)時(shí)候爆發(fā)了開(kāi)來(lái)而不是開(kāi)始。比如打車、外賣等行業(yè)的崛起，其實(shí)是在移動(dòng)互聯(lián)網(wǎng)興起的時(shí)候起來(lái)的，那么移動(dòng)互聯(lián)網(wǎng)又是在智能機(jī)普及的時(shí)候興起的，再加上 3G 的推廣，才會(huì)有這些行業(yè)的興起。
不存在沒(méi)來(lái)由的需求，放大了看會(huì)發(fā)現(xiàn)不一樣的東西，有助于我們?nèi)ネ诰蛐枨?，做好產(chǎn)品。
