本公開涉及通信技術領域，具體涉及一種信息交互系統(tǒng)。

背景技術：

隨著信息技術的不斷發(fā)展，通信應用程序的功能日益豐富。現(xiàn)在，通信應用程序已經(jīng)不再單純的作為聊天工具，而是發(fā)展成為集交流、咨詢、娛樂、搜索、電子商務、辦公協(xié)作、企業(yè)客戶服務和營銷等服務為一體的綜合化信息平臺。

為了能夠與群體客戶進行更好的交互，公眾號以及公眾號服務平臺應運而生。企業(yè)在公眾號服務平臺申請作為應用帳號的公眾號之后，可以利用公眾號在公眾號服務平臺上與其客戶群體之間進行文字、圖片、語音等信息的全方位交互、溝通，以滿足企業(yè)對營銷和客服等方面的需求。

對于企業(yè)級的公眾號，公眾號開發(fā)者一般需要部署兩類服務：一類是對于來自公眾號的各種請求的進行處理的核心業(yè)務服務，一類是通過公眾號與客戶之間進行交互的交互服務。舉例而言，上述交互服務中通過公眾號接收客戶的信息，核心業(yè)務服務對接收信息的進行分析處理后得到響應信息，最后通過交互服務將響應信息返回至客戶，完成與客戶的交互。

如圖1中所示，現(xiàn)有技術中，上述兩類服務通常被部署在同一臺服務器上，而不會進行區(qū)分，使得服務器壓力面臨雙重壓力，特別是在對于通過公眾號服務平臺和客戶交流頻繁的公眾號，其對應的服務器處理核心業(yè)務的能力會明顯下降。對于此種信息交互系統(tǒng)架構，一方面，不利于開發(fā)人員對核心業(yè)務服務的開發(fā)，另一方面，不利于向客戶提供更好的交互服務。此外，由于公眾號對應的服務器之間是獨立的，進而各公眾號交互相關的信息之間也是相互隔離的，無法實現(xiàn)共享，這對于同一企業(yè)旗下多個公眾號業(yè)務的耦合拓展非常不利。

技術實現(xiàn)要素：

本公開的目的在于提供一種信息交互系統(tǒng)，用于至少在一定程度上克服由于相關技術的限制和缺陷而導致的一個或多個問題。

本公開的其他特性和優(yōu)點將通過下面的詳細描述變得清晰，或部分地通過本公開的實踐而習得。

根據(jù)本公開的第一方面，提供一種信息交互系統(tǒng)，用于通過公眾號與客戶進行交互；所述信息交互系統(tǒng)包括獨立的交互服務器以及后臺服務器；其中：

所述交互服務器包括：

接收模塊，用于自公眾號服務平臺接收客戶向所述公眾號發(fā)送的信息；

獲取模塊，用于根據(jù)所述接收模塊接收的信息生成一請求信息并發(fā)出；

發(fā)送模塊，用于接收一響應信息并通過公眾號服務平臺利用所述公眾號將所述響應信息發(fā)送給所述客戶；

所述后臺服務器包括：

處理模塊，用于接收所述獲取模塊發(fā)出的請求信息，并根據(jù)所述請求信息生成對應的響應信息發(fā)送至所述發(fā)送模塊。

本公開的一種示例性實施例中，所述交互服務器還包括：

MySQL數(shù)據(jù)庫，具有一第一安全級別，用于存儲第一類型數(shù)據(jù)信息；

NoSQL數(shù)據(jù)庫，具有一第二安全級別，用于存儲第二類型數(shù)據(jù)信息；

其中，所述第一安全級別高于所述第二安全級別，所述第一類型數(shù)據(jù)信息所需的訪問權限較所述第二類型數(shù)據(jù)信息更高，所述第二類型數(shù)據(jù)信息被訪問的頻率較所述第一類型數(shù)據(jù)信息更高。

本公開的一種示例性實施例中，所述第一類型數(shù)據(jù)信息為高訪問權限數(shù)據(jù)信息，包括管理員信息、客戶信息、多媒體文件參數(shù)以及客戶交易記錄中的一種或多種；在本發(fā)明中，所述高訪問權限數(shù)據(jù)信息是指公眾號與客戶之間進行信息交互過程中被訪問或調取等操作頻率低于預設頻率，但由于包含諸如客戶隱私等因素而需具有保密要求的數(shù)據(jù)信息，其中所述的信息交互過程包括：公眾號響應客戶需求而進行的互動過程、公眾號主動向客 戶派送信息的過程等等。

所述第二類型數(shù)據(jù)信息為高訪問頻率數(shù)據(jù)信息，包括客戶和公眾號消息、公眾號參數(shù)信息、通信端口、機器應答信息、支付憑據(jù)以及服務鏈接中的一種或多種。在本發(fā)明中，所述高訪問頻率數(shù)據(jù)信息是指公眾號與客戶之間進行信息交互過程中被訪問或調取等操作頻率高于預設頻率的數(shù)據(jù)信息，其中所述的信息交互過程包括：公眾號響應客戶需求而進行的互動過程、公眾號主動向客戶派送信息的過程等等。

本公開的一種示例性實施例中，所述交互服務器還包括：

NAS數(shù)據(jù)庫，用于存儲歸檔數(shù)據(jù)信息。

本公開的一種示例性實施例中，所述歸檔數(shù)據(jù)信息包括多媒體文件、業(yè)務辦理資料、客戶操作記錄以及日志文件中的一種或多種。

本公開的一種示例性實施例中，所述公眾號為多個，所有所述公眾號共用各所述數(shù)據(jù)庫。

本公開的一種示例性實施例中，所述交互服務器還包括：

判斷模塊，用于判斷所述接收模塊接收的信息的類型：

若所述判斷模塊判斷所述接收模塊接收的信息屬于自動應答范圍，則所述獲取模塊生成一第一請求信息并發(fā)出；

若所述判斷模塊判斷所述接收模塊接收的信息屬于業(yè)務辦理范圍，則所述獲取模塊生成一第二請求信息并發(fā)出；

若所述判斷模塊判斷所述接收模塊接收的信息屬于人工解答范圍，則所述獲取模塊生成一第三請求信息并發(fā)出。

本公開的一種示例性實施例中，所述處理模塊包括：

資訊提供單元，用于根據(jù)所述第一請求信息提供對應的機器應答信息作為所述響應信息；

業(yè)務辦理單元，用于根據(jù)所述第二請求信息辦理對應的業(yè)務，并將業(yè)務辦理信息作為所述響應信息；

人工服務中心，用于呈現(xiàn)所述第三請求信息以及接受向所述人工服務中心輸入的信息作為所述響應信息。

本公開的一種示例性實施例中，所述后臺服務器還包括：

推送模塊，用于接收公眾號管理員的指令生成一推送信息并發(fā)送至所 述處理模塊，

所述處理模塊接收所述推送信息，并根據(jù)所述推送信息生成對應的響應信息發(fā)送至所述發(fā)送模塊。

本公開的一種示例性實施例中，所述數(shù)據(jù)信息具有公眾號源標識，僅與所述公眾號源標識對應的來源公眾號標識具有對相應數(shù)據(jù)信息的訪問權限。

本公開的一種示例性實施例中，所述交互服務器還包括：

學習模塊，與各所述數(shù)據(jù)庫連接，用于根據(jù)公眾號管理員的指令開放指定公眾號對全部數(shù)據(jù)信息的訪問權限。

本公開的一種示例性實施例中，所述交互服務器還包括：

學習模塊，與各所述數(shù)據(jù)庫連接，用于根據(jù)公眾號管理員的指令開放指定公眾號對特定目標客戶的所述數(shù)據(jù)信息的訪問權限。

本公開的一種示例性實施例中，所述信息交互系統(tǒng)還包括：

客服模塊，包括優(yōu)先級依次降低的多個客服系統(tǒng)；所述客服模塊用于在所述客戶尋求客服服務時，優(yōu)先利用最高優(yōu)先級的客服系統(tǒng)進行應答，其他優(yōu)先級的客服系統(tǒng)在上一優(yōu)先級的客服系統(tǒng)無法應答時進行應答。

本公開的一種示例性實施例中，所述NoSQL數(shù)據(jù)庫中還存儲有客服設置數(shù)據(jù)，用于設定增加或減少所述客服系統(tǒng)以及改變所述客服系統(tǒng)的優(yōu)先級。

本公開的一種示例性實施例中，所述公眾號服務平臺包括微信公眾號服務平臺或者微博公眾號服務平臺。

本公開示例性實施例中的信息交互系統(tǒng)中，通過設置相對獨立的交互服務器和后臺服務器，實現(xiàn)交互服務和核心業(yè)務的相互分離，二者互不影響，兩種服務都可以得到優(yōu)化，進而可以使得企業(yè)的信息交互系統(tǒng)整體處理能力得到提升。同時，相互獨立的分層結構也將使得公眾號交互過程中的安全性得以提升。

進一步的，本公開實施方式中還可以對公眾號交互相關信息進行分類存儲，在增加了信息的對外安全性的同時，也有效地提升了信息讀取的速度。在數(shù)據(jù)中設置了公眾號源標識，規(guī)定了僅與該源標識對應的公眾號才具有對該數(shù)據(jù)信息的訪問權限，從而更進一步增加系統(tǒng)內部的信息安全性 管理。同時，根據(jù)公眾號管理員的需求增加了學習模塊，在保障內部信息安全基礎上，又可以實現(xiàn)內部信息的共享與相互學習，從而可以通過大數(shù)據(jù)分析以及自動學習等技術綜合利用整體信息為客戶提供更好的交互服務體驗。

此外，本公開實施方式中還可以通過設置新架構的客服模塊，從而可以盡可能為客戶提供更優(yōu)選的客服系統(tǒng)，因此可以使得公眾號的客戶體驗大大提升。

附圖說明

通過參照附圖詳細描述其示例性實施例，本公開的上述和其它特征及優(yōu)點將變得更加明顯。

圖1是現(xiàn)有技術中信息交互系統(tǒng)的架構示意圖。

圖2是本公開示例性實施例中一種信息交互系統(tǒng)的架構示意圖。

圖3是本公開示例性實施例中一種信息交互系統(tǒng)的模塊示意圖。

圖4是本公開示例性實施例中一種信息交互系統(tǒng)的拓撲結構示意圖。

圖5是本公開示例性實施例中另一種信息交互系統(tǒng)的模塊示意圖。

圖6是本公開示例性實施例中另一種信息交互系統(tǒng)的拓撲結構示意圖。

圖7是本公開示例性實施例中一種客服系統(tǒng)切換流程示意圖。

具體實施方式

現(xiàn)在將參考附圖更全面地描述示例性實施例。然而，示例性實施例能夠以多種形式實施，且不應被理解為限于在此闡述的實施方式；相反，提供這些實施方式使得本公開將全面和完整，并將示例性實施例的構思全面地傳達給本領域的技術人員。在圖中，為了清晰，夸大、變形或簡化了形狀尺寸及連接關系。在圖中相同的附圖標記表示相同或類似的結構，因而將省略它們的詳細描述。

此外，所描述的特征、結構或步驟可以以任何合適的方式結合在一個或更多實施例中。在下面的描述中，提供許多具體細節(jié)從而給出對本公開的實施例的充分理解。然而，本領域技術人員將意識到，可以實踐本公開 的技術方案而沒有所述特定細節(jié)中的一個或更多，或者可以采用其它的方法、步驟、結構等。

本示例性實施例中提供了一種信息交互系統(tǒng)，用于通過公眾號與客戶進行交互。參考圖2中所示，所述信息交互系統(tǒng)主要包括交互服務器以及后臺服務器。交互服務器與后臺服務器之間相互獨立，分別處理各自業(yè)務。例如，交互服務器主要專注于實現(xiàn)交互服務，后臺服務器主要專注于根據(jù)請求處理核心業(yè)務。以下將對本示例性實施例中的交互服務器與后臺服務器進行更詳細的說明。

交互服務器主要用于為后臺服務器和公眾號服務平臺之間提供交互的通道，參考圖3以及圖4中所示，本示例性實施例中，所述交互服務器主要包括接收模塊、獲取模塊以及發(fā)送模塊。其中，接收模塊主要用于自公眾號服務平臺接收客戶向所述公眾號發(fā)送的信息；獲取模塊主要用于根據(jù)所述接收模塊接收的信息生成一請求信息并發(fā)出；發(fā)送模塊主要用于接收一響應信息并通過公眾號服務平臺利用所述公眾號將所述響應信息發(fā)送給所述客戶。后臺服務器可以無需處理交互服務，其主要包括處理模塊，處理模塊用于接收所述獲取模塊發(fā)出的請求信息，并根據(jù)所述請求信息生成對應的響應信息發(fā)送至所述發(fā)送模塊。

以所述公眾號是微信公眾號，所述公眾號服務平臺是微信服務器為例，客戶通過微信公眾號辦理T企業(yè)的保險業(yè)務為例：

客戶首先通過手機等移動終端或其他設備獲取并關注T企業(yè)辦理保險業(yè)務相關的微信公眾號(僅在客戶第一次與業(yè)務系統(tǒng)服務器建立對話關系時)，T企業(yè)的交互服務器通過微信服務器建立T企業(yè)的后臺服務器與客戶之間的對話關系。在建立對話關系后，客戶向公眾號發(fā)送信息，該信息可以是客戶輸入的一段文字，也可能是錄入的一段語音或其他類型的信息。微信服務器將客戶向公眾號發(fā)送的信息轉發(fā)至交互服務器，交互服務器中的接收模塊接收該信息，交互服務器對微信服務器轉發(fā)的客戶向公眾號發(fā)送的信息進行分析，得知客戶需要辦理保險業(yè)務，則獲取模塊據(jù)此生成一請求辦理保險業(yè)務的信息并發(fā)送給后臺服務器的處理模塊，處理模塊根據(jù)請求辦理保險業(yè)務的信息生成對應的響應信息發(fā)送至所述發(fā)送模塊，響應信息可能是保險業(yè)務辦理成功的信息，也可能是供客戶填寫辦理保險 業(yè)務相關信息的電子表單，也可能是保險業(yè)務相關資訊等等；該信息的類型可能是文字、圖片、語音、視頻等。發(fā)送模塊接收到響應信息之后，通過微信服務器利用上述公眾號將所述響應信息發(fā)送給所述客戶，完成一次交互。在完成辦理保險業(yè)務過程中，可能需要進行多次上述的交互。

通過上述客戶與保險企業(yè)微信公眾號的至少一次交互，在保險企業(yè)微信公眾號的數(shù)據(jù)庫中即可記錄該客戶為目標客戶，同時讀取或記錄下該客戶的客戶信息、客戶交易記錄以及管理員信息、多媒體文件參數(shù)等高訪問權限數(shù)據(jù)信息，以及一次或多次交互過程中的客戶和公眾號消息、公眾號參數(shù)信息、通信端口、機器應答信息、支付憑據(jù)以及服務鏈接等高訪問頻率數(shù)據(jù)信息；以及多媒體文件、業(yè)務辦理資料、客戶操作記錄、日志文件等歸檔數(shù)據(jù)信息。

另外，繼續(xù)參考圖3中所示，在本示例實施方式中，后臺服務器中還可以包括一推送模塊。推送模塊用于獲取公眾號管理員的信息推送指令生成一推送信息并發(fā)送至處理模塊。處理模塊接收該推送信息，并根據(jù)該推送信息生成對應的響應信息發(fā)送至交互服務器的發(fā)送模塊，再由該發(fā)送模塊發(fā)送給客戶接收。

例如，當T企業(yè)需要向廣大目標客戶推出某一新型保險產(chǎn)品的信息時，可由微信公眾號管理員發(fā)送一新產(chǎn)品信息推送指令至臺服務器中的推送模塊，推送模塊接收該推送指令并生成一新產(chǎn)品推送信息并發(fā)送至處理模塊。處理模塊接收該推送信息，并根據(jù)該推送信息生成對應的響應信息發(fā)送至交互服務器的發(fā)送模塊，再由該發(fā)送模塊發(fā)送該新產(chǎn)品的推廣信息至微信服務器，進而微信服務器將其轉發(fā)給T企業(yè)微信公眾號數(shù)據(jù)庫中所有的目標客戶接收。

上述信息交互系統(tǒng)中，交互服務器為后臺服務器和公眾號服務平臺之間提供了交互的通道，能夠相對獨立的完成交互服務，因此后臺服務器可以無需處理交互服務，公眾號開發(fā)者可以把集中精力和資源用于開發(fā)核心業(yè)務。由于交互服務和核心業(yè)務相互分離，二者互不影響，兩種服務都可以得到優(yōu)化，進而可以使得企業(yè)的信息交互系統(tǒng)整體處理能力得到提升。同時，相互獨立的分層結構也將使得公眾號交互過程中的安全性得以提升。

現(xiàn)有技術中，客戶通過公眾號和企業(yè)之間交互的信息，例如客戶信息、公眾號信息、客戶和公眾號消息記錄、客戶操作記錄、業(yè)務辦理記錄以及機器應答信息等均存儲在同一數(shù)據(jù)庫，且不區(qū)分重要等級、安全等級或使用頻率等級等。數(shù)據(jù)查詢調查時也通常采用輪詢的方式，將所涉及客戶的全部信息進行輪詢調取，再根據(jù)管理員或客戶對顯示內容的具體需求進行選擇展現(xiàn)。這主要是因為在同一數(shù)據(jù)庫中根據(jù)安全性等不同進行訪問權限等級的分別設定較為復雜且性價比不高。這就造成了現(xiàn)階段由于不同信息的重要程度不一，常用程度不一，將不同信息存儲在同一數(shù)據(jù)庫將會出現(xiàn)安全性無法確保或者在設置高安全級別時讀取不便等問題，影響交互效率。此外，在企業(yè)具有多個公眾號時，各個公眾號所對應的交互信息互相封閉，無法實現(xiàn)共享，這對于同一企業(yè)旗下多個公眾號業(yè)務的耦合拓展非常不利?，F(xiàn)階段企業(yè)級數(shù)據(jù)在保證數(shù)據(jù)對外安全性的基礎上，還要既有對內安全性也有共享耦合性。

繼續(xù)參考圖3以及圖4中所示，針對上述問題，本示例性實施例中所述交互服務器還包括MySQL數(shù)據(jù)庫以及NoSQL數(shù)據(jù)庫。其中，MySQL數(shù)據(jù)庫具有一第一安全級別，第一安全級別為相對更高的安全級別，用于存儲第一類型數(shù)據(jù)信息。NoSQL數(shù)據(jù)庫具有一第二安全級別，第二安全級別低于所述第一安全級別；NoSQL數(shù)據(jù)庫用于存儲第二類型數(shù)據(jù)信息。所述第一類型數(shù)據(jù)信息所需的訪問權限較所述第二類型數(shù)據(jù)信息更高，所述第二類型數(shù)據(jù)信息被訪問的頻率較所述第一類型數(shù)據(jù)信息更高。例如，所述第一類型數(shù)據(jù)信息包括客戶信息(例如實名信息)、客戶交易記錄以及管理員信息、多媒體文件參數(shù)以及備份文件等高訪問權限信息。所述第二類型數(shù)據(jù)信息包括客戶和公眾號消息、公眾號參數(shù)信息、通信端口(例如交互服務器和后臺服務器之間的通信端口、交互服務器和公眾號服務平臺之間的通信端口)、機器應答信息(例如關鍵字)、支付憑據(jù)以及服務鏈接(例如業(yè)務辦理連接)等高訪問頻率信息。當然，本領域技術人員也可以根據(jù)需求對交互涉及到的信息進行更多的分類，并對應提供相應類型數(shù)據(jù)庫進行存儲，例如，參考圖5及圖6中所示，交互服務器還可以包括NAS數(shù)據(jù)庫，用于存儲歸檔數(shù)據(jù)信息。歸檔數(shù)據(jù)信息可以包括多媒體文件(例如影音圖像文件)、業(yè)務辦理資料(例如客戶理賠資料)、客戶操作 記錄(例如客戶點擊菜單記錄)、日志文件等，即并不以本示例性實施例為限。

進一步的，本示例性實施例中，在所述公眾號為多個時，所有所述公眾號可以在同一交互服務器上進行，因此所有所述公眾號的交互可以共用各所述數(shù)據(jù)庫，從而可以使同一企業(yè)旗下所有公眾號之間實現(xiàn)信息整體共享。而為實現(xiàn)對內的數(shù)據(jù)信息安全保障，可進一步將第一類型數(shù)據(jù)信息及第二類型數(shù)據(jù)信息設置為具有公眾號源標識，僅有與所述公眾號源對應的來源公眾號才能擁有對相應數(shù)據(jù)信息的訪問權限。而當企業(yè)的推送信息是面向所有目標客戶時，交互服務器還包括學習模塊，與MySQL數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫以及以及NAS數(shù)據(jù)庫連接，用于根據(jù)公眾號管理員的指令開放所有公眾號對全部第一類型數(shù)據(jù)信息及第二類型數(shù)據(jù)信息的訪問權限，這樣就實現(xiàn)了對所有目標客戶信息的調取，保障了信息推送的全面性效果。

另外，當企業(yè)通過微信系統(tǒng)擁有了海量的目標客戶信息時，根據(jù)大數(shù)據(jù)理論，利用統(tǒng)計學原理可以從海量的目標客戶信息中搜索出適合于某一保險產(chǎn)品(例如保險理財產(chǎn)品)的特定目標客戶(具有理財能力或愿望的客戶)。但如該保險理財產(chǎn)品發(fā)送給對該保險理財產(chǎn)品無興趣的目標客戶則會浪費推送資源，甚至可能引起該客戶厭惡心理，導致放棄對企業(yè)微信的關注。為解決這一問題，在本示例性實施例中的學習模塊，可以根據(jù)公眾號管理員的指令開放指定公眾號對特定目標客戶的所述數(shù)據(jù)信息的訪問權限。也就是說，當某一目標客戶并非通過保險理財公眾號而進入T企業(yè)交互服務器的數(shù)據(jù)庫內，通過搜索確認該目標客戶具有理財能力或愿望，則可選定該目標客戶為保險理財公眾號的特定目標客戶。學習模塊可以為保險理財公眾號開啟該特定目標客戶的第一類型數(shù)據(jù)信息及第二類型數(shù)據(jù)信息的訪問權限，從而定向向其推送保險理財產(chǎn)品的信息。

再者，學習模塊與MySQL數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫以及以及NAS數(shù)據(jù)庫連接時還可用于分析MySQL數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫以及以及NAS數(shù)據(jù)庫中的數(shù)據(jù)以改善向所述客戶提供的服務，從而可以為客戶提供更好的體驗。舉例而言，學習模塊分析客戶和公眾號消息記錄，從而不斷自動優(yōu)化上述機器應答信息；學習模塊也可以分析客戶信息、公眾號參數(shù)信息、 業(yè)務辦理記錄、客戶和公眾號消息記錄、客戶操作記錄等信息，進而可以統(tǒng)計客戶的年齡分布、職業(yè)分布、地域分布、需求分布、服務體驗等數(shù)據(jù)從而供后臺服務器有針對性的為客戶提供更好的交互服務等等。

相比于現(xiàn)有技術，本示例性實施例中一方面對公眾號交互相關信息進行分類存儲，在增加了安全性的同時，也有效的提升了信息讀取的速度。同時，使各公眾號之間實現(xiàn)信息的共享，從而可以通過大數(shù)據(jù)分析以及自動學習等技術綜合利用整體信息為客戶提供更好的交互服務體驗。

繼續(xù)參考圖3至圖6中所示，本示例性實施例中，所述交互服務器還可以包括一判斷模塊。判斷模塊用于判斷所述接收模塊接收的信息的類型，進而為后續(xù)處理提供便利。例如，若所述判斷模塊判斷所述接收模塊接收的信息屬于自動應答范圍，則所述獲取模塊可以生成一第一請求信息并發(fā)出；若所述判斷模塊判斷所述接收模塊接收的信息屬于業(yè)務辦理范圍，則所述獲取模塊可以生成一第二請求信息并發(fā)出；若所述判斷模塊判斷所述接收模塊接收的信息屬于人工解答范圍，則所述獲取模塊可以生成一第三請求信息并發(fā)出。相對應的，所述處理模塊具備處理不同請求的單元，例如，所述處理模塊包括資訊提供單元、業(yè)務辦理單元以及人工服務中心等。其中，資訊提供單元可以用于根據(jù)所述第一請求信息提供對應的機器應答信息作為所述響應信息；業(yè)務辦理單元可以用于根據(jù)所述第二請求信息辦理對應的業(yè)務，并將業(yè)務辦理信息作為所述響應信息，業(yè)務辦理信息可以包括辦理結果或者辦理業(yè)務所需電子表單等信息；人工服務中心可以用于通過屏幕向客服人員呈現(xiàn)所述第三請求信息以及接受客服人員向所述人工服務中心輸入的信息作為所述響應信息。當然，在本公開的其他示例性實施例中，判斷模塊也可能判斷接收模塊接收的信息同時屬于多種類型，此時則可能需要對應同時提供多種不同的處理方式；而且，處理模塊的各單元之間也可能出現(xiàn)相互調用的情形等，均屬本公開的保護范圍。

現(xiàn)有技術中，企業(yè)的信息交互系統(tǒng)的客服系統(tǒng)單一，而且管理混亂，客戶體驗較差。繼續(xù)參考圖3及圖5中所示，本示例性實施例中，所述信息交互系統(tǒng)還可以包括一客服模塊，用于在客戶需要向客服咨詢、尋求幫助或者投訴時提供相應的文字或者語音等形式的服務。本示例性實施例 中，客服模塊可以包括優(yōu)先級依次降低的多個客服系統(tǒng)；所述客服模塊用于在所述客戶尋求客服服務時，優(yōu)先利用最高優(yōu)先級的客服系統(tǒng)進行應答，其他優(yōu)先級的客服系統(tǒng)在上一優(yōu)先級的客服系統(tǒng)無法應答時進行應答。

舉例而言，客服模塊可以包括優(yōu)先級依次降低的UC客服、智能客服、微信客服、騰訊客服以及自定義客服。當客戶求客服服務時，客服模塊的工作流程如圖7中所示，首先，當判斷UC客服處于開啟狀態(tài)時，則優(yōu)先通過UC客服對客戶進行應答；當判斷UC客服處于關閉狀態(tài)時，且判斷智能客服處于開啟狀態(tài)時，則優(yōu)先通過智能客服對客戶進行應答......當所有客服系統(tǒng)均無法應答時，則只能通過默認客服進行應答。此外，本示例性實施例中，所述NoSQL數(shù)據(jù)庫中還可以存儲有客服設置數(shù)據(jù)，用于增加或減少所述客服系統(tǒng)以及改變所述客服系統(tǒng)的優(yōu)先級。例如，可以允許公眾號管理員設置各客服系統(tǒng)的優(yōu)先級別，也可以允許客戶根據(jù)自身需要加入對應的客服。當然，在本公開的其他示例性實施例中，客戶也可以根據(jù)關鍵字提示，主動進入任一客服系統(tǒng)，并不以本示例性實施例中為限。相比于現(xiàn)有技術，本示例性實施例中的客服模塊盡可能提供更優(yōu)選的客服系統(tǒng)，同時可以自由切換，因此可以使得公眾號的客戶體驗大大提升。

另外，上述公眾號服務平臺除了微信服務器之外，還可以為微博服務平臺、短信后臺服務器等其它服務平臺等，本實施例不對公眾號服務平臺的具體形式進行限定。此外，企業(yè)及所提供的服務類型不受本公開的限定，無論何種企業(yè)，都可以在得到公眾號服務平臺授權后，使用公眾號服務平臺授權的API(Application Programming Interface，應用程序編程接口)接口，根據(jù)其業(yè)務需求結合API接口進行二次開發(fā)，以實現(xiàn)通過公眾號服務平臺與客戶之間的交互，此處不再一一贅述。

本公開已由上述相關實施例加以描述，然而上述實施例僅為實施本公開的范例。必需指出的是，已揭露的實施例并未限制本公開的范圍。相反地，在不脫離本公開的精神和范圍內所作的更動與潤飾，均屬本公開的專利保護范圍。