自畢業到現在，在呼叫中心這個行當滾打了那么多年，不能說是見識了多少風風雨雨，但是經歷形形色色的客戶倒是事實，特別是外包業務的呼叫中心，更是如此，你能碰到的客戶可能是一個長期的客戶：一做就是幾年；要不就是短期的：1－2個月就搞定的。于是對于不同的客戶以及不同的客戶需求，就有著很多中實現方案了。以下，我就幾點系統開發和規劃方面的經驗與大家一起分享以下。

市場調研項目：

這種項目應該說是比較簡單的項目，只要打出電話去，聯系客戶，收集要的資料，保存呼叫結果，就可以了，這種項目一般情況都是比較短期的，除非有些特別的客戶，例如咨詢公司、數據公司等。

技術標準：

數據的準確性——這點應該是市場調研公司的注意的關鍵地方，很多公司要求給的數據有長度的限制，字節的限制，選項的相互邏輯性的控制等，以確保數據的準確性，而且這個也將成為KPI來處理。

數據的可重復利用——一般情況來說，市場調研的標準是數據的準確性，要求提供多少份合格的數據就可以了，但是有時候會出現數據量不夠或很差的情況，大的咨詢公司可能還要求給出更詳細的數據使用情況報表，因此這點也是技術上要考慮到的。

數據的真實性——這點要就要求而言，不同的公司仍然有不同的要求，但是我相信如果沒有錄音系統，那么這點對與技術而言就沒有什么意義了。

可變性——這點一定要注意，不要給自己找麻煩，因為這樣的客戶，往往會在不同的時候給出不同的變化，如果是短期的，可能不會，但是如果是中期或是長期的話，一定會發生這樣的情況。

實現方案：

一個數據庫就可以了，但是就情況來說，不是什么都用一個數據庫，如果是很簡單的甚至給個Excel就可以滿足要求了，如果是大的或是要求復雜的公司，那么建立一個系統是個很好的方法，利人利己。

方案1.

短期項目，要求不高，收集的資料沒有特定的邏輯或是邏輯相當簡單，AGENT數量不多：建議使用EXCEL來作，只要一個TEAM LEADER來分配數據，每天收集成功的數據，進行數據篩選就可以了。一般不需要工程師的支持，如果需要的話，也就是給個好用點的EXCEL模板。

方案2.

中期項目，要求不高，但是問卷的內容存在變化，存在簡單邏輯，建議使用.NET技術開發，更新也好，發布也好很方便，但是需要數據庫的支持，因此需要有一個數據庫開發工程師，一個.NET開發工程師。

方案3.

中長期項目，要求很高，既需要字段的長度，又需要字段內的內容不存在全角或是特別字符，又要求符合邏輯，一定使用數據庫支持，同時前端建議使用DELPHI或是C++開發可以很好的控制字段內容和邏輯，為什么不建議使用VB那？因為VB的字段長度控制存在問題。需要一個數據庫開發工程師，一個前端開發工程師；

（注明，以上的方案中，都假設有現成的CTI支持，因為不同的公司有自己不同的CTI，不同的排隊機也有不同的CTI，可能有直接提供OCX控件的，當然也可能只是給了個2次開發的DLL）

電話銷售：

項目的目的很簡單，能很好的聯系客戶，進行銷售，成功的訂單量是最主要的目的了，于是對于系統的要求也就是“信息”——其中包括了FAQ,相應的新的優惠措施等，但是這些都可以在TEAM LEADER的BRIEFING中得到信息，但是畢竟一開始的時候這些東西是十分重要的，在對于一些大的客戶的電話銷售的項目中，還要注意真個系統的開發盡量降低流程的關節，能夠一個人一通電話結束就最好。

技術標準：

流程簡潔——一般的電話銷售都認為流程很簡單，其實必定存在不可確定的因素：例如上門送貨后失敗了，用戶沒有來，用戶反悔了等，這些情況必然會引起后續流程的出現，這些流程的出現將導致2個嚴重的問題：1，報表，一天和一天的報表是固定的，如果有退單的情況出現，那么對于前一天的報表就存在問題，那么就需要表明，或是用別的方式將實際數字和情況表示出來，雖然這些是營運要考慮的問題，但是作為IT，他們一定會來和你說“我只要一個準確的報表，不關你用什么辦法”，于是就把壓力轉交到你這里了，所以在一開始的設計時候就要考慮到這點。

質檢——這點和上面的不同，因為這次的質量檢測指的是對必須信息的必要性的檢查，因為這樣做可以提高訂單的準確性。

預約數據的控制——不要引起客戶的反感，所以對于預約的數據或是BUSY NO ANWSER的數據都要做次數的控制。

實施方案：

方案：

一般電話銷售存在以下幾個步驟：

A． 數據的提取，進行電話銷售；

B． 銷售成功，成功訂單；銷售不成功，決定是否有機會再做銷售；預約；

C． 核實訂單，決定上門的時間和地點；

D． 上門的結果反饋；

E． 成功：標記成功，失敗：表明原因，有銷售人員決定是否可以再跟進；

這個項目的實現沒有什么技術上的限制，可以用你喜歡的技術，根據開發時間的長短來決定，但是還是建議使用B/S方式，一定要注意狀態的明確，時間和人也一定要明確。一個數據庫開發工程師，2－3個開發工程師。

客戶服務：

這個應該是INBOUND的業務了，沒有固定的標準，因為可能客戶有了他們自己已經很成熟的CRM系統，你要做的就是給他們一個CTI就可以了，讓他們可以打電話接電話，然后給他們像CMS這樣的報表就可以了，當然，也可能從頭到尾的CRM都要你來開發，這樣的項目我是比較喜歡的，比較有挑戰性，一般就不是2－3個工程師能完成的任務了，如果時間緊迫的話，那么就需要更好的控制了。

技術標準：

IVR——一個少不了的INBOUND東西，沒有語音流程就沒有好的客服了，能讓用戶在IVR里面結束他們的問題就最好了，那么就可以降低AGENT的工作量，那么IVR的設計就盡量簡潔明了，不要多而繁瑣的IVR，因為可能客戶還會問你要IVR報表來考核你。

完善的CASE系統——對于客戶服務來說，CASE系統是少不了的，用戶的每一通電話都將是一個CASE，所以CASE的分類，CASE的解決方案是你在開發的時候要考慮到的，而且這點東西一定在不斷的增加當中的，你可以用數據庫來保存，但是我的已經是用個文本文件來保存更好，因為這樣起碼可以降低不必要的數據庫請求，因為CASE庫是很龐大的，在上面做的東西很多的。而且CASE的狀態的變化也是可能會變的。

復雜的DSS——對于客戶服務而言，營運部門一定會問IT要數據分析的很多報表了，這點你要做好思想準備，CASE的分類，解決方案的分類那是一個不可能缺少的東西，每天的，每周的，每月的報表也是，所以你要建立一個CONTACT HISTORY來保存CASE在每天的結果，那么無論是天還是周還是月的話，報表是不會錯的，否則只留一個狀態，你就哭去吧。

速度——有的公司要求ACHT的時間有控制的，因此慢的很的系統建議你不要用，用的話，責任就都是你的了，營運會把ACHT的原因進行詳細分析，然后，如果存在一點點系統的延時引起的ACHT長度增加的話，那么你的責任就大了，所以，建議不要用J2EE，那個東西在人少的時候還可以（10－20個），如果（50）那么就慢死你了，然后系統開銷又大，老板的錢不會隨便花的。

錄音——請保證你的錄音一定有。

實現方案：

J2EE方案：開銷大的方案，除非出于客戶的需求和你有很強的技術人員，否則建議不用這個方案；但是他的好處呢，可以移植，作個完整的，以后還可以出去賣，一個很不錯的第三產業；

.NET方案：強烈內部推薦的方案，速度快，懂的人多，系統開銷小，維護方便多了；

以上都是一點點我的經驗啦，由于邊幅的問題，很不具體，如果你是IT的或是對我們的IT很敢興趣或是有什么好的經驗或問題都可以發郵件來聯系我，哈哈。

無聊的時候寫寫文章也不錯。學習還是硬道理….

www.51callcenter.com注:

作者聯系方式:netis_sun@hotmail.com

呼叫中心行業資訊網