客服中心培訓解決方案

1. 網店客服的培訓流程

交流過程包括：歡迎-溝通-議價（包含物流）-支付-售後-歡送+好評。 A.反應快，對於客戶的第一條消息，響應速度要快，不讓客戶等待時間超過10秒；
B.歡迎語言主要的基本格式為：您好，歡迎光臨XX店，我是客服露露，很高興為您效勞+笑臉。實際過程中各店根據不同情況可進行調整。 溝通環節是客戶對產品了解的一個過程，也是客戶享受客服服務的一個綜合環節，更是做好網店用戶體驗感的幾點因素之一。對產品的專業了解程度不用多說了，這個是崗位基本需求；其次要站在客戶的角度解答客戶的疑問，適當引用一些數據、專業術語也可，讓他們信服讓她們信賴你的介紹和推薦；
另外還需要注意一點，在溝通環節中有些客戶會認為現咨詢的產品不適合他們，表現出不想購買的的意向了，這時需求及時注意客戶的語言，根據需求推薦其他替代產品，切勿讓一個到手的顧客溜走了。 包括物流費用，這個是比較頭痛的問題，很多客戶在網購過程中已經養成了講價的習慣：
A、喜歡撿小便宜，講一點算一點；
B、內心滿足感，通過講價滿足內心價值感；
對於顧客，我們要強調這幾點：
A、產品優質，一分價錢一分貨，便宜的價格只能買到次品；
B、價格是公司制定的統一價格，無權修改；
C、上兩條表達後仍然表現出不滿的可以適當給與其他一些優惠轉移價格敏感度：打折產品、滿就送小禮品、包郵活動、運費少量優惠等。 A、對於新手買家，需要耐心指導，因為沒使用過，支付過程中會遇到很多疑問，需要耐心解答，直到完成付款；
B、已下訂單，卻遲遲未有支付的可以進行詢問：「親，我已經看到您的訂單了，請問你是在支付過程中遇到問題了嗎？如有不懂之處，我可以指導您+笑臉。」
另外需要注意，需要掌握的一些網店客服催單技巧。 這一塊需要專門一篇文章來講解的，主要就是這樣幾個步驟：安撫—原因—解決－致歉—感謝。
一般售後問題客戶都有一些不滿或者情緒問題，首先要安撫，在情緒平穩後再進一步商議解決方案：退換貨、退款等等，雙方商議一致解決方案，然後再表達我們的歉意，讓顧客心理感覺舒適，最後再一次滿足顧客就是上帝的心態：感謝他們的理解，歡送。 訂單支付以後，需要給客戶確認發貨信息，不要讓人感覺賣了東西態度就大轉彎了。首先是發貨信息，當天發貨、3天內、還是什麼情況，需要您及時查看物流信息；其次是歡送：感謝您的惠顧，期待您的再次光臨；最後是好評：收到貨物後請給我們全5分好評（5分好評得優惠卷等），如有不滿請及時聯系我，我們的進步離不開您的支持+笑臉表情。

2. 電話客服培訓計劃及方案

就讓復我用我的寶貴時間給你回答一制下下！記得請客哦！ 培訓計劃： 1，人員的選定！從性格，聲音上尋找合適的人； 2，第一步，練習微笑，雖然接電話打電話不要和對方面對面，但是也要保持微笑，這樣說出來的話讓人感覺很舒服； 第二步，接電話的禮儀以及注意事項「喂，您好，這里是……請問有什麼可以為您效勞的嗎」電話響了三聲才接的話就要說「喂，您好，不好意思讓您久等了，這邊是……請問有什麼可以為您效勞的嗎」 第三步，打電話的禮儀以及注意事項「喂，您好，請問是……先生/小姐嗎？」「不好意思，打擾您一下，我這邊是……」「謝謝您聽我講解了這么多，請問您還有什麼疑問嗎」等等 我要說的重點就是說，一定要注意語言的方式和禮貌用語！

3. 在線客服技術的解決方案

1、 輪詢
這是一種比較古老而簡單的解決方案，也就是定時刷新，在線客服在聊天的時候，aJax在後台定時獲取數據，如果接收到發送過來的消息的話，則將消息顯示在聊天框上。
這種技術的缺點就是後台刷新太頻繁了，而很多刷新都是沒有數據返回了，導致性能的下降。
2、 長連接
這種技術有稱為「長輪詢」，它是基於輪詢技術的，但有所改進，客戶端向服務端發起請求的時候，服務端不會直接返回，而是會阻塞請求，直到伺服器讀取到消息後才返回，這個時候，客戶端才調用回調函數，將讀取到的消息顯示出來。
這里講的在線客服系統將選用該技術來實現。
圖2. 基於長輪詢的伺服器推模型
消息
這種解決方案採用一個作為client的applet，它使用TCP/IP或者無連接的UDP、甚至多播協議來建立與消息中間鍵server的通訊，然後由server推送消息給client。你可以從例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event這些消息產品中直接挑選，或者自己使用基於socket的定製開發消息軟體。
Comet技術Commet是一種使用HTTP長連接，無需瀏覽器安裝插件的「伺服器推」方案。它有兩者方案：基於aJax的長輪詢方式；基於iframe和htmlfile的流方式。這里，我們只關注裡面的基於aJax的長輪詢方式。
Pushlet是一個開源的Comet框架，其中在設計上有很多值得借鑒的地方，能夠使用它來開發一個不是大規模的在線客服系統。而對於大型商用的在線客服系統，我覺得它還無法勝任。
負載均衡（分布式部署）一個正式商用的在線客服系統，不可能只在一個WEB伺服器部署，這樣子，性能和容量都很難擴展，所以必然是允許分布式部署的，通過負載均衡設備（或軟體）來實現分布式訪問。
如果採用分布式部署的話，那麼就涉及到聊天的數據保存在哪裡的問題。是保存在web伺服器上，還是資料庫呢？如果是單web伺服器的話，那肯定是保存在web伺服器上，其流程大概如下：
1、 用戶發送消息是，系統將數據保存在web伺服器（同時也保存資料庫）上。
2、 客服對應的長連接獲取web伺服器上的數據，然後在客服的頁面上顯示出來。
3、 客服回復聊天信息，系統將數據保存到web伺服器（同時也保存資料庫）上。
4、 用戶所在的長連接獲取web伺服器上的數據，然後在用戶的頁面上顯示處理。
由於從web伺服器上獲取數據比在資料庫獲取數據的效率高，所以上面的邏輯是合理的，但是，基於分布式部署的環境下，他存在多個web伺服器，那麼發起聊天的消息應該保存在哪台伺服器上呢？還是所有的伺服器都保存一次呢？在分布式環境下存在一些像JBossCache等緩存同步的技術，但對應在線聊天系統，實時性的要求非常高，是否存在實時性的問題呢？
另外一個，基於安全的考慮，一般需要將用戶所訪問的功能放到一個web伺服器集群上，客服所訪問的功能放到另外一個web伺服器集群上，兩個web伺服器集群的網路需要隔離，以防止黑客的攻擊。這就又出現一個問題，如果用戶發送的消息放到用戶的web伺服器上，那麼客服如果獲取到該消息呢？同理，用戶的web伺服器有如果獲取客服web伺服器對應的消息呢？
那麼放到資料庫來實現呢？把聊天記錄都放到資料庫中，用戶和客服都從資料庫獲取聊天的信息。這樣子的話，那麼資料庫的負荷將非常大，隨著用戶數的不斷增加，資料庫負荷越來越大，而且，在大用戶下，存儲都是非常頻繁的，將所有人的聊天信息放到資料庫上，是不明智的。還有一個安全上的考慮，一般實現用戶的功能都不直接訪問資料庫，一般會經過一個中間的伺服器作為中轉，那麼如果聊天信息從資料庫取的話，效率則會更低。
那麼，能不能像QQ那樣，聊天雙方直接建立連接，實時發送呢？其實，這是一種相對老點的技術，一般是採用Socket，或者UDP，實現雙方的通訊。這種機制的缺點客戶端可能需要採用applet插件或ActiveX插件，通訊時有比較大的性能消耗，最重要的一點，這些技術受網路的影響特別大，在一個環境下可以正常使用，在另外一個環境下，可能就無法正常使用了。所以，本文考慮的是採用aJax長輪詢方式來實現的。
在這里，我建議客服的聊天數據從資料庫讀取，而用戶的聊天數據從web伺服器上讀取。這是因為客服的數據相對比用戶少很多，直接從資料庫讀取聊天數據，對資料庫的性能影響較少，而用戶的數量龐大，直接從資料庫讀取，無法滿足要求。
那麼，客服是將回復數據寫到客服的web伺服器，還是用戶的web伺服器呢？我的建議是寫到用戶的web伺服器，因為用戶的數據量非常龐大，用戶從用戶的web伺服器獲取數據，要比從客服的web伺服器獲取數據，性能要高得多。客服每次發送聊天信息的時候，往用戶的web伺服器寫數據，雖然效率低，但由於客服的數據量小，並不影響性能。
另外，在分布式部署下，數據該記得所以的web伺服器，還是某台特定的web伺服器呢？我建議寫到某個特定的web伺服器上，這樣避免客服每發送一條聊天信息，都要往所有的web伺服器寫數據，這會影響性能，但web伺服器不斷增加的時候，性能會隨之下降。
那麼，客服往哪台特定的web伺服器寫數據呢？用戶又如何知道從哪台特定的web伺服器上獲取數據呢？這個，我們在用戶登陸，負載均衡伺服器給其分配到某個特定的伺服器的時候，就可以將這個特定伺服器的IP記錄下來，客服就可以往這台機器發消息了，而用戶也同樣可以從該IP獲取數據了。

4. 在線客戶服務解決的方案網路客服

你要的解決方案是客戶跟客服之前的橋梁吧，網路那塊你指的是比如網站，公眾號，那塊吧，你應該是要了解在線客服系統吧，不知道我說的對不對，我之前用過的是快商通的，在客戶流量統一接入跟客服工作效率提高都會有很大的一個解決方案，絕壁好用就是

5. 教育培訓機構客戶服務解決方案

所有行業的客戶都需要進行維系，對於教育培訓機構來說維系客戶是非常重要的，而如何維系版就是一權個問題。要經常的和顧客進行互動，在顧客面前刷臉，從而讓顧客熟悉你。如果客戶太多的話，一個個進行維系又過於麻煩，你可以直接試試（里德助手）的親密群發功能。它的帶稱呼群發信息的功能，可以讓客戶感覺到親切，從而維護與顧客之間的關系。希望我的回答可以幫你。