對于呼叫中心而言，所有的系統大致可以分為4種，分別為： Inbound 系統， Outbound 系統， IVR系統，MIS系統；一個大型的呼叫中心一般都擁有以上四種系統,當然也有部分的小型或中型的呼叫中心只包含其中的幾項。 Inbound系統一般都和IVR系統有著密切的關系，但是AVAYA提供了另一種簡單的IVR實現，那就是VECTOR，但是如果要更加的靈活或是豐富的話，IVR系統是必不可少的部分，當然他的功能能做些什么，我將在以后慢慢說明。今天就Inbound系統做個比較詳細的分析和說明，以便于從事呼叫中心系統開發人員了解整個系統應該有的功能以及將來的發現方向，以下只是個人的觀點和做法，僅供參考。

我在這里指的Inbound系統不是傳統意義上的電話Inbound了，當然目前他仍舊是最為主流的媒體之一，目前就Inbound的手段可以分為：傳統的語音電話，傳真，EMAIL，SMS以及WEB CALL（這個方式已經在很多網站上提供了支持，就連銀行也有在使用這種方式）。于是要求Inbound系統所能接受的方式也就多種多樣了。我對呼叫中心中使用的方式進行了排序：TELEPHONE > EMAIL > WEB CALL > SMS> FAX；為什么我會這樣排序呢？傳統的電話仍舊是最為人們容易接受的方式，因此可以所每個呼叫中心必定也就是要把注意力集中在這點上，EMAIL的方式已經漸漸的也為人所能接受，畢竟上網的人哪個沒有用過EMAIL去詢問情況呢？因此如果能合理的安排EMAIL的處理，那么也能少了不少的人力，因為大家都能理解為什么EMAIL的答復總是那么的慢（客戶是這么認為的），于是，SERVICE LEVEL在EMAIL上面的將大大低于TELEPHONE方式，可以在電話空閑的時候抽出1－2個人去處理EMAIL，我看已經是很足夠的了，WEB CALL正如我先前所說的，是一個新的被廣泛使用的媒體，因為他有著實時，快捷，方便的有點，當然怎么樣的CALL叫WEB CALL? MSN算是一種，QQ也算，只要是能聊天的都算，但是這些不帶有排隊和自動路由的功能，所以呢，如果系統要提供這些功能的話，不得不去找第三方或是自己開發了。SMS就不用多說了，但是用他作為呼叫中心的一個Inbound系統還是比較少的，畢竟你不知道用戶到底是發什么東西過來的，于是處理的方式也就和EMAIL差不多了，但是更多的是垃圾了。FAX是個人認為快要被淘汰的Inbound手段，如沒有什么特別要求話（例如什么單據，憑證什么的）個人認為還是讓他去墓地比較的合適。

Inbound系統的目的只有一點，能夠在一個CALL（姑且將所有方式的Inbound都在這里叫做CALL）中解決用戶的問題，提高用戶對服務的滿意，能更好的介紹新的產品（算是一種新的增值，已經有一些方案在使用中了）。

客戶

用戶的信息，一般情況下，用戶會留下他的聯系方式，以便于未來的聯系，其實不留電話根本不重要，因為獲得個主叫不是什么問題，問題是留下客戶的姓名，性別什么的都可以通過電話交流得知（排除特別情況）；客戶的聯絡歷史是另一個很重要的地方，當一個用戶第一次打電話來的時候，就應該記錄下時間同時可以和后面的案例關系起來，那么就能提供給下一次服務更多的信息。

案例

無論怎么樣，Inbound項目都應該將呼入的CALL建立一個案例來處理，目的很簡單為了能跟蹤事情的發展，了解業務的情況，了解客戶的問題所在。那么案例中應該包含哪些必須的東西呢？首先是對客戶的問題做多級別的分析，如果你的項目夠小的話，就分一級也就可以了，但是一般會對一通CALL分很多級，每級別都會有各個級別的分類，因此建議詳細的分解級別，那么對于未來的MIS系統也好，對于OPERATION的業績分析也好，對于客戶的發展也好都有很大的幫助，因此強烈建議將級別分的“明確”、“完整”、“靈活”（這里的靈活是可以為每個級別添加種類）；再就是產品了（服務的種類）這點就每個項目的不同會有所不同，但是如果就泛指的話，無論是服務也好，人員也好都算是產品，只是一種是看不見的，一種是看的見的。詢問的產品會影響你服務人員的服務水平，所以一般情況下會對不同的產品提供不同的TEAM去解決，在IVR上進行了分類之后，人工的再細分也是少不了的，因為當你服務的是一家有幾百個產品的公司的時候，產品在案例中的記錄也就成為了一種藝術，為什么說是一種藝術呢？因為你可以通過不同的方式來將產品呈現給我們的服務人員，從細化到序列號，型號，到泛化到大類，如果讓服務人員去選擇，如何將案例的重點表現出來，又如何為未來的產品推廣做準備呢？呵呵，這些都是產品信息可以給出你的。分析將有注于未來的發展；再者是案例的狀態，其中包括了案例目前的狀態，歷史狀態，狀態更改的原因等，這些往往有人會忽略掉后者，但是在你開發MIS系統的時候就會發現在那么FRONT END記錄的東西那么的少，都不足以出一份簡單的報表了，當然CASE LOG還有利于分析案例的REOPEN情況，FTR等，然后是案例的來源，如果系統做的完善的話，這點應該是不用服務人員自己去填寫的，系統會根據方式來自動填寫的內容；最后就是備注和附件，為什么我會加上附件這樣一種東西呢？因為往往情況下，應該將用戶的描述原封不動的保留給下次來查看，電話就做不到這點了（除非你把錄音最為附件來和案例一起保存，這種做法實在是不多），但是EMAIL和SMS都可以最為附件來保存的話，那么對于未來的服務人員原始信息的查詢就很有利了。

升級

一個再好的呼叫中心，也不可能沒有一次升級，能不被投訴已經是不可能的事情了，升級的目的就是將投訴率降低到最少，能近可能的降低不能解決的問題和近可能的安撫客戶，于是就出現了應答技能更好，技術更強，服務更到位的人了，我在這里說指出的升級不單單包括了內部的，也包括了外部的升級，因為有些情況下升級的內容是需要別人去安排時間上門的，例如產品的包修等。升級應包括了案例的升級，升級的時間警告，升級的多媒體的警告（可以是彈出的窗口，可以是一個OUTBOUND CALL，也可以是一條SMS）這些都可以讓高級的服務人員能更加及時的答復客戶，更加有效的控制案例；當然升級的歷史是一定要保留的，因為OPERATION能通過他更好的考核各個層面對問題的解決情況和效率。

知識庫

好的知識庫能有效的提供服務人員足夠的信息，本人見到過最好的知識庫莫過于MSDN和圖文并茂的NOKIA了，現在服務人員對知識庫的要求也越來越高，能進行查詢是最為起碼的內容，能對知識庫的準確性進行評估，能對常問的問題優先出現，能對產品做多種方式模擬，能更有效的將消息反饋給管理，能對不同的技能做不同的分類處理等，這些需求也隨著技術的發展越發發展了。

其他的單據

不得不說得是由于服務的產品以及服務的面的不同，因此往往會有些不同的單據會產生，跟蹤單據的情況就成為Inbound系統中的另一個部分了，客戶可能會問：上次我打電話來要保修的東西，怎么現在還沒有人來修呀？于是你就要查詢保修單目前到底去了哪里？誰負責的了；或是用戶來問，我買的東西怎么還沒有送到，于是也就出現了訂單的跟蹤，這些都是根據不同的行業有者不同的單據，少的可能一個案例就一個單據，多的，一個案例5－10張單據都有可能，因此，建議在設計的時候使用一對多的方式比較的合適和靈活。

CTI是一個很好的東西，應該集成在我們的Inbound系統中，一方面可以將電話的信息（號碼）直接提供給我們服務人員或是由后臺去尋找相應的客戶資料，另一方面可以讓服務人員了解目前在線的人數，等待的人數，SERVICE LEVEL等，這些都是考核呼叫中心的指標，最后就是有了CTI，服務人員就可以脫離掉電話的按鍵，直接在電腦上進行操作，更好的地方就是很多系統都需要有CTI的功能才能得到更多的信息，例如IVR的信息等。同時有了CTI，轉電話的時候也就有了數據，這點將大大的提高了升級的使用性和靈活性。

最后，要指出的是Inbound系統絕對不可能是通用的，他的通用無非是在CTI，知識庫，工作流上，這些地方的設計可是靈活和通用的，但是別的地方只是建議使用通用的模型，而內容方面還是根據具體需求來開發比較的好。畢竟速度不是可以放棄的一點，越通用越花時間。