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

CRM項目事件提醒機制實施要點分析 src="/files/uploadimg/20110418/1030170.jpg" width=500>

▲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等等。如果需要帶附件，那么系統管理員就需要向郵件管理員確認其采用的附件大小的限制。所傳遞的附件不能夠大于這個限制。否則的話，用戶將無法正常收到這個提醒信息。