CRM專案事件提醒機制實施要點分析（轉）

http://cio.it168.com/a2011/0417/1178/000001178985.shtml
事件提醒作業是CRM系統中一個不可或缺的內容。簡單的說，事件提醒就是要求系統在某個特定的時間提醒某個使用者需要做哪些事情。這說起來容易，要做 得好還是有一定的難度。如下圖所示，是一個線上CRM系統事件提醒的設定頁面。筆者現在就以這個系統為例，談談事件提醒的管理要點。

▲CRM專案事件提醒機制
 

　　一、確定事件的負責人

　 　對於一個事件，首先需要確定的是負責人。注意這裡的負責人並不一定指的是建立這個事件的本人，也可以指其他使用者。如現在你是銷售經理。需要將一個客戶回 訪的任務指派給某個業務員（讓業務員在2月30日去拜訪某個客戶）。那麼銷售經理就希望系統在2月29日能夠提醒自己，並同時提醒業務員。在這種情況下， 可以在這裡同時選擇多個負責人，如銷售經理和這個業務員。如此的話，在觸發條件滿足時系統會自動將這個提醒資訊傳送給這兩個負責人，提醒他們該做什麼事 情。

　　相關使用者的資訊要預先在系統中輸入。然後根據需要在這裡可以選擇使用者資訊。可以根據需要，同時選擇多個使用者。

　　二、確定事件的優先順序別

　 　通常情況下，企業會對客戶進行分級管理。如會將客戶分為ABC三類。其中A類客戶是企業的優質客戶。那麼在事件的管理上，也可以將事件分為低、普通、高 等多個類別。跟A類客戶相關的事件往往優先順序別比較高。這裡的優先順序別對於事件的觸發沒有實際的影響。如現在使用者有三個事件都是在2月25日10點開始提 醒的。系統並不是指提醒優先順序別高的事件，而是會同時提醒三個事件。只是在提醒的列表中，會列出這三個事件的優先順序別。以幫助使用者判斷該先做那件事情。

　 　也就是說，這裡的優先順序別只是提供一種參考的作用。系統並不會主動去判斷該做哪個級別的事情。不過在實際工作中，對於事件進行優先順序別的管理，效果還是 蠻明顯的。如有些職業經理人，就會將今天要做的事情全部羅列出來，並標明優先順序別。一上班，就開始從優先順序別高的事件開始做起。這種管理方式被很多管理學 者所推薦。CRM系統也將這種管理模式引入進來，以幫助使用者改善自己的工作效率。

　　三、時間設定

　　使用者需 要設定這個事件的開始時間與結束時間。如銷售經理指定某個業務員在3月5日去拜訪客戶。此時這個事件的開始時間就可能在3月4日，結束時間在3月6日。注 意這裡的時間設定，開始時間一般會早於事件本身要做的時間；而結束時間則又會晚於事件的結束事件。因為事件提醒，一般都是在事件開始之前進行提醒。否則的 話，就沒有提醒的必要。在事件完成之後，可能還需要有一個追蹤反饋的過程。為此常常將事件結束的時間往後延遲一段時間，如一個工作日。

　　 在時間設定時，這裡有一個細節需要注意，即是否允許將事件設定在非工作日。對於大部分使用者來說，非工作日並不在企業。此時讓系統設定在非工作日進行提醒， 沒有實際的用途。有時候反而會因為使用者的誤設定而沒有收到提醒。故使用者可以根據自己的實際情況，設定無法選擇非工作日的時間。系統管理員可以在系統基本信 息處設定工作日（可以設定雙休或者單休，也可以直接手工指定非工作日）。設定好之後，如果使用者選擇的時間是非工作日，就會提醒使用者。這個人性化的設計，還 是很有實用價值的。

　　四、選擇通知的方式

　　等到觸發條件滿足時，以什麼樣的方式來通知使用者呢？這個線上系 統中，可以使用SMS（系統的一個即時通訊工具）或者郵件（如果郵件系統與CRM系統進行整合的話）進行通知。如果採用即時通訊工具的話，則要求使用者時刻 開啟這個CRM系統。而如果採用郵件的話，也要求使用者開啟郵件服務。顯然這兩種方式，都要求使用者必須坐在電腦旁才能夠使用。

　　其他的一些CRM系統已經開始與移動商務整合。即可以將這些提醒資訊通過簡訊的方式傳送給手機使用者。如此的話，就可以讓CRM系統脫離主機的束縛，可以隨時隨地的接收到事件提醒資訊。條件成熟的企業，可以考慮將移動商務系統與CRM專案進行整合。其實整合的方式也很簡單，有些CRM系統甚至自帶有這種模組。

　　這也提醒專案管理員，在CRM系統選型時，要考慮這種整合的需要。如果確實需要使用移動商務平臺，那麼還不如選擇那種內嵌了移動商務功能的CRM系統。即將移動商務作為CRM系統的一個模組。模組化的移動商務功能可以給使用者帶來更多的體驗。如還可以通過手機終端來查詢CRM系統中的資訊以及簡單的操作等等。此時手機就不再是一個簡單的接受資訊的平臺。

　 　如果使用者在這裡採用了郵件通知，那就要確保郵件帳號的準確性。在設定使用者資訊時，可以同時設定這個使用者的郵箱資訊。筆者建議，在設定好之後，可以利用系 統的“郵件測試”功能來測試設定的準確性。如果設定無誤的話，那麼使用者的郵箱可以馬上收到一封測試郵件。在這裡筆者推薦使用一些比較穩定的郵箱伺服器。如果企業有自己的郵箱伺服器，那最好。

　　五、附件的管理

　　在事件提醒中，還可以根據需要新增附件資訊。不過筆者並不贊成。因為附件一般都比較大。如果在提醒時同時傳送附件資訊，可能會因為資訊量過大而影響系統的效能。為此對於附件，筆者有如下幾個建議。

　　一是儘量少用附件，而用連結的方式。如現在新建了一個銷售機會，使用者需要系統提醒自己後續的工作。此時使用者可以有兩個選擇。

　　一是將這個客戶的資訊以附件的形式進行傳送。使用者收到事件提醒後，可以直接開啟附件來檢視資訊。二是隻顯示一個連結的資訊。使用者收到事件提醒後，可以點選連結來檢視客戶資訊。

　　顯然採用附件的形式，會帶來更多的資料流量。而對於使用者來說，都需要有一個點選的動作，工作效率並不會因為附件的存在而改善多少。為此筆者建議，在事件提醒機制中，要儘量的少用附件，而更多的使用連結的形式。

　 　二是如果真的要使用附件，那麼需要根據所傳送的渠道有所區別。如採用郵件形式來傳送提醒時，可以讓系統在傳送郵件的同時附上附件。不過此時需要考慮安全 性問題。如郵件安全策略中是否允許接受附件、附件的內容是否會洩密等等。而如果採用移動商務平臺的話，筆者建立不採用附件。否則的話，使用者一個月下來的手 機通訊費用可不在少數，而且手機檢視資訊的速度也會明顯變慢。不過現在隨著3G手機網路的推廣，這種現象有了明顯的改善。故CRM系統要根據其所傳送所採 用的途徑，來判斷是否需要同時傳送附件。

　　三是附件大小的控制。在郵件系統中，一般對所能夠接受的附件大小都有限制，如不能夠大於20M等等。如果需要帶附件，那麼系統管理員就需要向郵件管理員確認其採用的附件大小的限制。所傳遞的附件不能夠大於這個限制。否則的話，使用者將無法正常收到這個提醒資訊。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7656893/viewspace-692814/，如需轉載，請註明出處，否則將追究法律責任。