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

很多時候，我們可以從一些需求中深挖出不一樣的東西。這篇文章里，作者講述了自己在CRM領(lǐng)域中遇到的一個優(yōu)化需求，一起來看看本文所延伸的系統(tǒng)功能思考。

前段時間CRM關(guān)于客戶申領(lǐng)遇到了一個優(yōu)化需求。希望申請后審核通過的可以直接變成保護(hù)狀態(tài)（在待營銷中的客戶）。

前情概述：

如正常的CRM系統(tǒng)規(guī)則，客戶在一定時間內(nèi)沒有進(jìn)展是會掉入公海的。

在新制度出來前是沒有客戶等級這個概念，于是營銷可以任意申領(lǐng)客戶。

新制度出來后，公司根據(jù)類型和規(guī)模劃分了等級，針對已經(jīng)保護(hù)中的客戶是不受新制度約束，如果掉入公海或者新建一個新的客戶是要受新制度的約束。

如果營銷沒權(quán)限去保護(hù)就要走申領(lǐng)這一步操作，需要相關(guān)管理人員進(jìn)行審核，通過后才能保護(hù)繼而營銷。

之前因?yàn)橹贫认嚓P(guān)的功能都在另一套管理系統(tǒng)，而客戶相關(guān)的在CRM系統(tǒng)，分屬不同的產(chǎn)品管理。因此在最終方案上有瑕疵，各做各的，只是最后把數(shù)據(jù)同步了。

那么就出現(xiàn)了一個問題，營銷從公海中想要申領(lǐng)這個客戶，但是呢提示沒有權(quán)限，需要去管理系統(tǒng)中申請客戶資源，等營銷去管理系統(tǒng)申請客戶資源之后，由相關(guān)人員進(jìn)行審核，通過后，營銷需要再次去公海進(jìn)行申領(lǐng)。因此全部流程只是做了資格權(quán)限的申請而已，不是客戶的直接申領(lǐng)。顯然這中間就多余了操作步驟。

現(xiàn)在系統(tǒng)歸到了一位產(chǎn)品手中，為了解決上述問題，我們展開了討論，如何去解決這個問題。

從上述描述來看我們可以看到營銷在CRM中申請客戶，但是只是告知了沒有權(quán)限，之后再無下文，這是斷檔1。

營銷去管理系統(tǒng)申請并審核通過后，也只是獲取了資格，沒有形成有效的保護(hù)，這是斷檔2。

這中間其實(shí)還引申了另一個問題，我們申請的這個客戶之后是這個客戶的全部條線產(chǎn)品還是單一條線產(chǎn)品還是單個產(chǎn)品，這個我們放后面說。

既然現(xiàn)在是一個產(chǎn)品來負(fù)責(zé)了，那么我們可以將系統(tǒng)歸集起來，因此這里又引申出兩個問題。

1. 營銷申請是在哪申請（CRM還是管理系統(tǒng)）？
2. 審核是在哪里審核（CRM還是管理系統(tǒng)）？這里還有一個小問題，審核的人和層級是否可變，是否需作配置？

帶著這些問題，我們按照優(yōu)先級來規(guī)劃下項(xiàng)目的迭代版本。

因?yàn)檎w的功能已經(jīng)有了，只是如何把這些功能串起來，不做的話，人工操作會多一些，而人會有遺忘，操作越多，涉及系統(tǒng)越多會出現(xiàn)變數(shù)。

因此最優(yōu)先解決的是斷檔2中的問題，因?yàn)闋I銷去公海申請客戶，發(fā)現(xiàn)沒權(quán)限，知道要去哪里申請了，就去了，但是申請通過之后，可能沒來得及再次領(lǐng)出來，就被被人領(lǐng)走了，這就比較麻煩了。

因此我們的步驟1是審核通過后自動將公海中的客戶轉(zhuǎn)為營銷保護(hù)。那么這個客戶有多產(chǎn)品線多產(chǎn)品呢，是否全部保護(hù)？這個我們后面來講。

緊接著我們再來處理斷檔1的問題，于是就有了步驟2。步驟2要做的是當(dāng)營銷去公海申請客戶的時候，提示沒有權(quán)限，順便詢問是否申請，如果營銷選擇申請的話，自動在管理系統(tǒng)生成一天客戶申請的記錄，等待審核即可。

好，到了這里我們營銷跨系統(tǒng)去申領(lǐng)客戶的動作都給解決了，那么我們就要來解決審核到底在那個系統(tǒng)進(jìn)行。因?yàn)椴襟E2中已經(jīng)解決了申請?jiān)谠贑RM自動創(chuàng)建申請記錄。

這個我們就要看審核人是誰，他們經(jīng)常使用什么系統(tǒng)進(jìn)行操作，于是又牽扯到了配置問題。

那么步驟3就是我們的審核配置，因?yàn)榭蛻魰鐥l線，而每條條線的負(fù)責(zé)人是不一樣的，除非是由公司的統(tǒng)一部門來審核，比如說董事長之類的，一般會下放到各條線負(fù)責(zé)人，畢竟他們懂自己條線的業(yè)務(wù)及知道目前處于什么情況是否可以由該營銷人員進(jìn)行營銷。

這里面就涉及到了我們申請客戶保護(hù)的范圍是什么？是全部（只要申請一次這個客戶，所有條線產(chǎn)品都可以申領(lǐng)）？是條線（通過后營銷只能申領(lǐng)這條線下的產(chǎn)品）？還是產(chǎn)品（每次申領(lǐng)都是要申請審核的）？

那么這個問題還是回歸到業(yè)務(wù)問題，只是我們不能只聽他們的，我們需要告知每種形式的優(yōu)勢和弊端。

第一種，全部的。那么這里面的優(yōu)勢顯然是一次操作眾生收益，不需要頻繁操作了；弊端也顯而易見，有些不該營銷人員營銷的就不好控制，以及如果是全部的話，那么由各業(yè)務(wù)線負(fù)責(zé)人審核這件事顯然也不合適，會起沖突。

第二種，條線范圍內(nèi)，這個是比較折中的，條線本不多，而且各自負(fù)責(zé)人都有，且對營銷比較了解。弊端則是如果產(chǎn)品多，好的條線的營銷都想去，也會出現(xiàn)大包大攬的現(xiàn)象，這樣就造成資源的浪費(fèi)了。

第三種，產(chǎn)品級，這是比較嚴(yán)謹(jǐn)?shù)?，你要銷售什么產(chǎn)品就申請什么產(chǎn)品，好管控，缺點(diǎn)在于每個產(chǎn)品都申請可能比較頻繁。

那么就要分析當(dāng)前營銷的產(chǎn)品及每個客戶會用到的產(chǎn)品數(shù)量多寡來決定采用哪種方案。從當(dāng)前情況來看的話，采用第三種比較合適，首先每個客戶購買的產(chǎn)品不多且固定，其次在申請的時候可以批量申請，不是一個個申請。這樣就能達(dá)到當(dāng)前階段最優(yōu)效果了。

當(dāng)然也有人說，那么我以后變了呢？

如果變化不是很頻繁，幾年變一次的，直接硬編碼。如果想要做得更靈活多變的，那么做個配置，申領(lǐng)后是控制全部還是條線還是產(chǎn)品，這樣只需要把配置切換下即可，順便更改下審核人員，因?yàn)閺漠a(chǎn)品或條線切換到全部的時候，如果審核人員沒切換回來那么就需要默認(rèn)一個審核人或者只要申請的相關(guān)條線的負(fù)責(zé)人任意一個審核都行，這些都基于業(yè)務(wù)，我們提供參考建議。

最后一步就要確定操作放在哪個系統(tǒng)。那么這個其實(shí)是需要看操作人的，他們習(xí)慣在哪個系統(tǒng)中，不是說這個功能是CRM相關(guān)的，就一定放在CRM中，如果審核人之前不需要使用CRM系統(tǒng)，那么勢必還會要給他配置權(quán)限以及審核人員出現(xiàn)系統(tǒng)來回切換的問題。

當(dāng)我們分析到這里的時候，我們其實(shí)把版本迭代的順序都理順了，那么接下來我們?nèi)绾巫?，就看業(yè)務(wù)方的建議是否全套做還是按部就班以及看研發(fā)時間，來決定最終使用哪種方案來完成這部分的優(yōu)化功能。

在分析一個功能的時候，需要把這個功能的范圍放大了看，放在整個流程鏈路中去看他處于什么位置，會對這條鏈路有什么影響，還可以再放寬到整個系統(tǒng)中去看，這個對整個系統(tǒng)的影響，在不斷放大的過程中，我們會發(fā)現(xiàn)不一樣的問題，這也是我們經(jīng)常做完了這個需求發(fā)現(xiàn)其他地方出問題了。因?yàn)槲覀冎豢吹搅诉@塊內(nèi)容，沒有放大去思考。

就像歷史事件，我們在看的時候，只知道這個時候發(fā)生了什么，沒有去看為什么偏偏在這個時候發(fā)生了?；蛘咧皇窃谶@個時候爆發(fā)了開來而不是開始。比如打車、外賣等行業(yè)的崛起，其實(shí)是在移動互聯(lián)網(wǎng)興起的時候起來的，那么移動互聯(lián)網(wǎng)又是在智能機(jī)普及的時候興起的，再加上3G的推廣，才會有這些行業(yè)的興起。

不存在沒來由的需求，放大了看會發(fā)現(xiàn)不一樣的東西，有助于我們?nèi)ネ诰蛐枨?，做好產(chǎn)品。

不正之處，請不吝指教！