專利名稱：業(yè)務(wù)體驗的實現(xiàn)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及一種業(yè)務(wù)體驗的實現(xiàn)方法和系統(tǒng)。
背景技術(shù)：
目前，電信增值業(yè)務(wù)正在快速發(fā)展，面對越來越多的增值業(yè)務(wù)，用戶通常希望在開 通增值業(yè)務(wù)之前能夠?qū)υ鲋禈I(yè)務(wù)進行體驗，在經(jīng)過試用之后決定是否進行訂購和開通。面 對用戶的體驗需求，運營商會開設(shè)業(yè)務(wù)體驗廳和體驗門戶網(wǎng)站等多種體驗平臺，通過體驗 廳和體驗門戶網(wǎng)站，用戶可以對增值業(yè)務(wù)進行體驗。圖1是相關(guān)技術(shù)中業(yè)務(wù)體驗廳的系統(tǒng)示意圖。如圖1所示，在體驗廳系統(tǒng)中，體驗 廳管理服務(wù)器與多個體驗終端連接，當用戶使用體驗終端進行體驗時，體驗廳管理服務(wù)器 就能夠通過體驗終端向用戶呈現(xiàn)體驗的業(yè)務(wù)內(nèi)容，實現(xiàn)用戶對增值業(yè)務(wù)的試用，這樣，就能 夠使用戶切身了解到增值業(yè)務(wù)的功能和具體情況后，根據(jù)自身的意愿判斷是否開通對應(yīng)的 增值業(yè)務(wù)。具體地，在圖1所示的體驗系統(tǒng)中，預(yù)先定義的體驗邏輯(S卩，體驗策略)、界面、以 及相關(guān)文件均可以保存在體驗廳服務(wù)器中，客戶登錄體驗終端時，根據(jù)客戶的操作，給客戶 推送動態(tài)的內(nèi)容，例如，文字、動畫、介紹信息等。體驗終端還包括實體的設(shè)備，例如，摘機系 統(tǒng)，如果客戶摘下某款手機，則可以在旁邊的顯示屏幕上給客戶推送這款手機的賣點、適配 業(yè)務(wù)、換購政策等。另外，隨著互聯(lián)網(wǎng)體驗營銷的發(fā)展，運營商也建設(shè)了體驗門戶網(wǎng)站，并將業(yè)務(wù)介 紹、動畫教程、以及互動操作等集成在網(wǎng)站上，如圖2所示，用戶可以上網(wǎng)終端通過登錄體 驗門戶網(wǎng)站，由體驗門戶網(wǎng)站向上網(wǎng)終端傳輸體驗內(nèi)容，達到業(yè)務(wù)體驗的目的。在用戶基于目前的業(yè)務(wù)體驗平臺體驗業(yè)務(wù)時，體驗內(nèi)容的數(shù)據(jù)直接從體驗門戶網(wǎng) 站或體驗廳管理服務(wù)器傳輸給用戶的終端，而具體每次體驗的過程和結(jié)果對于上層設(shè)備是 不可知的，也是無法被上層設(shè)備控制的。另外，上述的這兩種業(yè)務(wù)體驗方式之間并沒有實 現(xiàn)有效的聯(lián)動，例如，當通用戶在體驗廳進行體驗后，如果用戶之后登陸體驗門戶網(wǎng)站期望 繼續(xù)體驗，由于門戶網(wǎng)站系統(tǒng)無法獲得該客戶進行業(yè)務(wù)體驗的歷史數(shù)據(jù)，所以無法基于用 戶進行體驗的歷史結(jié)果為客戶提供個性化推薦，例如，用戶已經(jīng)訂閱了手機早報業(yè)務(wù)，或者 用戶已經(jīng)體驗過手機早報業(yè)務(wù)，對手機電子報紙已經(jīng)有所了解，但是，當用戶登陸體驗平臺 進行體驗時，由于體驗平臺無法獲知用戶已經(jīng)訂閱或體驗了手機早報，因此，無法確定用戶 是否已經(jīng)對手機上的各種電子報紙有所了解，而是需要假設(shè)用戶對手機電子報紙完全不了 解，提示用戶是否需要對手機電子報紙業(yè)務(wù)進行介紹，而不能夠主動地向用戶介紹其他類 型的手機報紙的內(nèi)容概要，導致體驗過程出現(xiàn)大量的重復處理，不僅會影響用戶體驗，還會 降低體驗的效率，增加體驗系統(tǒng)的處理負擔。造成上述問題的原因在于，目前的體驗系統(tǒng)中，如果希望將具體的體驗場景進行 重現(xiàn)或傳輸，每進行一次這種操作，就需要傳輸大量的信息，而目前用戶進行業(yè)務(wù)體驗的數(shù) 量是相當大的，因此，對于目前的網(wǎng)絡(luò)而言是無法實現(xiàn)這種大量數(shù)據(jù)交互的。
目前，針對相關(guān)技術(shù)中由于網(wǎng)絡(luò)傳輸存在的限制導致業(yè)務(wù)體驗智能度低、重復處 量理大、體驗效率差的問題，尚未提出有效的解決方案。

發(fā)明內(nèi)容
針對相關(guān)技術(shù)中的問題，本發(fā)明提出一種業(yè)務(wù)體驗的實現(xiàn)方法和系統(tǒng)，能夠有效 避免相關(guān)技術(shù)中由于不同體驗平臺無法進行聯(lián)動、網(wǎng)絡(luò)上層設(shè)備不能夠控制和管理體驗過 程的問題，從而提高體驗的智能度和效率、降低網(wǎng)絡(luò)負擔。本發(fā)明的技術(shù)方案是這樣實現(xiàn)的根據(jù)本發(fā)明的一個方面，提供了 一種業(yè)務(wù)體驗的實現(xiàn)方法。該方法包括在用戶通過第一體驗平臺體驗業(yè)務(wù)的情況下，管理后臺確定需要對 用戶采用的體驗策略，其中，體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，體驗規(guī)則是推送體 驗內(nèi)容的規(guī)則；管理后臺將體驗策略的標識以及體驗策略中需要首先執(zhí)行的體驗規(guī)則的標 識通知給第一體驗平臺，以便第一體驗平臺根據(jù)體驗策略的標識和需要首先執(zhí)行的體驗規(guī) 則的標識對用戶推送體驗內(nèi)容。其中，在用戶未體驗完體驗策略中所有體驗規(guī)則對應(yīng)的體驗內(nèi)容時就退出體驗的 情況下，該方法可以進一步包括步驟1，第一體驗平臺將用戶當前已經(jīng)完成體驗的體驗規(guī) 則的標識和體驗策略的標識通知給管理后臺；步驟2，在用戶通過第二體驗平臺繼續(xù)進行 體驗時，管理后臺根據(jù)體驗策略以及用戶當前已經(jīng)體驗完成的體驗規(guī)則確定用戶繼續(xù)進行 體驗時的體驗規(guī)則；步驟3，管理后臺將確定的體驗規(guī)則的標識和體驗策略的標識通知給 第二體驗平臺，以便第二體驗平臺根據(jù)確定的體驗規(guī)則對用戶推送相應(yīng)的體驗內(nèi)容，其中， 第一體驗平臺與第二體驗平臺相同或不同。并且，在管理后臺確定用戶繼續(xù)進行體驗時的體驗規(guī)則進一步包括在用戶通過 第二體驗平臺繼續(xù)進行體驗時，根據(jù)業(yè)務(wù)操作歷史記錄確定需要對用戶采用的新的體驗策 略，并判斷新的體驗策略是否具有與用戶根據(jù)原體驗策略進行體驗且中途退出時所產(chǎn)生的 斷點，如果判斷結(jié)果為是，則執(zhí)行步驟2和步驟3 ；如果判斷結(jié)構(gòu)為否，則根據(jù)用戶已經(jīng)體驗 完成的體驗規(guī)則和新的體驗策略確定用戶繼續(xù)進行體驗時的體驗規(guī)則，并將該體驗規(guī)則的 標識和新的體驗策略的標識通知給第二體驗平臺，處理結(jié)束。另外，管理后臺確定需要對用戶采用的體驗策略包括管理后臺根據(jù)用戶的業(yè)務(wù) 操作歷史記錄確定體驗策略，其中，業(yè)務(wù)操作歷史記錄用于表示用戶進行業(yè)務(wù)體驗和業(yè)務(wù) 訂購的情況。可選地，歷史記錄包括以下至少之一用戶已經(jīng)體驗的業(yè)務(wù)的標識，用戶已經(jīng)體驗 的業(yè)務(wù)的類型，用戶已經(jīng)訂購的業(yè)務(wù)的標識，用戶已經(jīng)訂購的業(yè)務(wù)的類型，用戶體驗業(yè)務(wù)、 訂購業(yè)務(wù)以及使用業(yè)務(wù)的時間。另外，至少一個業(yè)務(wù)規(guī)則由管理后臺預(yù)先根據(jù)體驗策略所對應(yīng)的體驗流程中不同 的體驗階段劃分得到。可選地，第一體驗平臺和第二體驗平臺包括以下至少之一體驗門戶網(wǎng)站、體驗廳
管理服務(wù)器。根據(jù)本發(fā)明的另一方面，提供了一種業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)。根據(jù)本發(fā)明的業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)包括管理后臺和第一體驗平臺，其中，管理后臺用于在用戶通過第一體驗平臺體驗業(yè)務(wù)的情況下，確定需要對用戶采用的體驗策略，并 將體驗策略的標識以及體驗策略中需要首先執(zhí)行的體驗規(guī)則的標識通知給第一體驗平臺， 其中，體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，體驗規(guī)則是推送體驗內(nèi)容的規(guī)則；第一體 驗平臺用于根據(jù)來自管理后臺的體驗策略的標識和需要首先執(zhí)行的體驗規(guī)則的標識對用 戶推送體驗內(nèi)容。該系統(tǒng)還包括第二體驗平臺，其中，第一體驗平臺還用于在用戶未體驗完體驗策 略中所有體驗規(guī)則對應(yīng)的體驗內(nèi)容時就退出體驗的情況下，將用戶當前已經(jīng)完成體驗的體 驗規(guī)則的標識和體驗策略的標識通知給管理后臺；管理后臺還用于在用戶通過第二體驗平 臺繼續(xù)進行體驗的情況下，根據(jù)體驗策略以及用戶當前已經(jīng)體驗完成的體驗規(guī)則確定用戶 繼續(xù)進行體驗時的體驗規(guī)則，并將確定的體驗規(guī)則的標識和體驗策略的標識通知給第二體 驗平臺；第二體驗平臺用于在用戶通過第二體驗平臺繼續(xù)進行體驗時，根據(jù)管理后臺確定 的體驗規(guī)則的標識和體驗策略的標識對用戶推送相應(yīng)的體驗內(nèi)容。該系統(tǒng)可以進一步包括客戶關(guān)系服務(wù)器，用于保存用戶的業(yè)務(wù)操作歷史記錄，其 中，業(yè)務(wù)操作歷史記錄用于表示用戶進行業(yè)務(wù)體驗和業(yè)務(wù)訂購的情況；用戶管理后臺還用 于根據(jù)業(yè)務(wù)操作歷史記錄對體驗策略進行調(diào)整，并根據(jù)用戶已經(jīng)體驗完成的體驗規(guī)則和調(diào) 整后的體驗策略確定用戶繼續(xù)進行體驗時的體驗規(guī)則。此外，上述管理后臺還用于預(yù)先根據(jù)體驗策略所對應(yīng)的體驗流程中不同的體驗階 段劃分得到至少一個業(yè)務(wù)規(guī)則。本發(fā)明通過一個通用的體驗管理后臺將業(yè)務(wù)體驗過程所對應(yīng)的體驗邏輯(S卩，體 驗策略)劃分為多個體驗規(guī)則，體驗規(guī)則由管理后臺統(tǒng)一生成并分發(fā)到各個不同的體驗前 端系統(tǒng)(體驗前端系統(tǒng)就是用戶進行業(yè)務(wù)體驗時所借助的體驗平臺，其可以是定制化的體 驗機也可以是體驗門戶網(wǎng)站等)，這樣，前端體驗系統(tǒng)就能夠根據(jù)體驗規(guī)則生成適當?shù)捏w驗 內(nèi)容展現(xiàn)給客戶，不論用戶通過什么體驗平臺進行業(yè)務(wù)體驗，這些體驗平臺都能夠根據(jù)管 理后臺指示的體驗規(guī)則向用戶提供相應(yīng)的體驗內(nèi)容，由于網(wǎng)絡(luò)中傳輸?shù)膬H僅是體驗規(guī)則的 標識，因此能夠避免大量數(shù)據(jù)在網(wǎng)絡(luò)中傳輸，同時有助于體驗平臺將規(guī)則上報給管理后臺， 并且，由于體驗策略由管理后臺確定，因此，使得用戶的體驗?zāi)軌虻玫焦芾砗笈_的控制，有 助于提高體驗的智能度，避免重復體驗的問題出現(xiàn)。


圖1是相關(guān)技術(shù)中體驗廳管理服務(wù)器與體驗終端連接的結(jié)構(gòu)示意圖；圖2是相關(guān)技術(shù)中體驗門戶網(wǎng)站與上網(wǎng)終端連接的結(jié)構(gòu)示意圖；圖3是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的實現(xiàn)方法的流程圖；圖4是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)的結(jié)構(gòu)框圖；圖5是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)的部署實例的框圖；圖6是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的實現(xiàn)過程中體驗規(guī)則發(fā)布的信令流程圖；圖7是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗過程的具體處理過程的信令流程圖；圖8是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗過程出現(xiàn)異常的信令流程圖；圖9是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗過程中用戶在一次體驗未完成的情況下退 出體驗的信令流程圖10是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗過程中用戶在一次體驗未完成的情況下退 出體驗后重新登錄并繼續(xù)體驗的信令流程圖。
具體實施例方式針對相關(guān)技術(shù)中由于網(wǎng)絡(luò)傳輸?shù)木窒扌?，使得多體驗平臺的數(shù)據(jù)不能夠互通，并 且體驗過程不能夠得到其他上層網(wǎng)元設(shè)備的協(xié)助，導致業(yè)務(wù)體驗不能夠跨平臺進行，并且 無法在中斷后繼續(xù)執(zhí)行，且體驗過程智能度較低的問題，本發(fā)明提出，將業(yè)務(wù)體驗過程所對 應(yīng)的體驗策略劃分為多個體驗規(guī)則(也可以理解為體驗的步驟)，并由管理后臺決策規(guī)則 的確定和規(guī)則的下發(fā)，這樣，不論用戶通過什么體驗平臺進行業(yè)務(wù)體驗，這些體驗平臺都能 夠根據(jù)管理后臺發(fā)送的體驗規(guī)則向用戶提供相應(yīng)的體驗內(nèi)容，從而避免大量數(shù)據(jù)在網(wǎng)絡(luò)中 傳輸，并且，由于體驗策略由管理后臺確定，因此，使得用戶的體驗?zāi)軌虻玫焦芾砗笈_的控 制，有助于提高體驗的智能度，避免重復體驗的問題出現(xiàn)。根據(jù)本發(fā)明的實施例，提供了 一種業(yè)務(wù)體驗的實現(xiàn)方法。在實現(xiàn)該方法前，管理后臺需要進行體驗規(guī)則的發(fā)布，在體驗規(guī)則發(fā)布成功后，每 個體驗平臺均保存體驗規(guī)則與相應(yīng)標識的對應(yīng)關(guān)系，且管理后臺需要繼續(xù)發(fā)布體驗策略， 每個體驗策略同樣具有相應(yīng)的標識，并且，每個體驗策略中包含有序排列的至少一個體驗 規(guī)則，在體驗策略發(fā)布后，體驗平臺就能夠保存每個體驗策略與相應(yīng)策略標識的對應(yīng)關(guān)系。如圖3所示，根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的實現(xiàn)方法包括步驟S301，在用戶通過第一體驗平臺體驗業(yè)務(wù)的情況下，管理后臺確定需要對用 戶采用的體驗策略，其中，體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，體驗規(guī)則是推送體驗 內(nèi)容的規(guī)則；步驟S303，管理后臺將體驗策略的標識以及體驗策略中需要首先執(zhí)行的體驗規(guī)則 的標識通知給第一體驗平臺，以便第一體驗平臺根據(jù)體驗策略的標識和需要首先執(zhí)行的體 驗規(guī)則的標識對用戶推送體驗內(nèi)容(即，體驗平臺會順序執(zhí)行體驗策略中的體驗規(guī)則，依 次推送相應(yīng)的體驗內(nèi)容)。借助于上述處理，通過將業(yè)務(wù)體驗過程所對應(yīng)的體驗策略劃分為多個體驗規(guī)則， 并由管理后臺進行體驗策略的確定并將體驗策略中的一系列體驗規(guī)則通知給用戶進行體 驗時所使用的體驗平臺，這樣，不論用戶通過什么體驗平臺進行業(yè)務(wù)體驗，這些體驗平臺都 能夠根據(jù)管理后臺指示的體驗規(guī)則向用戶提供相應(yīng)的體驗內(nèi)容，由于網(wǎng)絡(luò)中傳輸?shù)膬H僅是 體驗規(guī)則的標識，因此能夠避免大量數(shù)據(jù)在網(wǎng)絡(luò)中傳輸，并且，由于傳輸?shù)捏w驗規(guī)則的標識 是所有體驗平臺均能夠識別的，因此，不同體驗平臺能夠很容易地進行數(shù)據(jù)共享，并且有助 于實現(xiàn)體驗平臺之間的聯(lián)動，還有助于體驗平臺將體驗的實際狀況通過體驗規(guī)則上報來通 知給管理后臺，并且，由于體驗策略由管理后臺確定，因此，使得用戶的體驗?zāi)軌虻玫焦芾?后臺的控制，有助于提高體驗的智能度，避免重復體驗的問題出現(xiàn)。其中，對于上述的體驗規(guī)則，可以根據(jù)以下方式進行劃分根據(jù)用戶體驗業(yè)務(wù)的不 同階段，將每個階段劃分為一個(不可分割的)體驗規(guī)則，例如，對于手機電子報業(yè)務(wù)，可以 劃分為以下五個順序排列的體驗規(guī)則(1)向用戶展示該業(yè)務(wù)的相關(guān)介紹；(2)向用戶發(fā)送 免費電子報；(3)詢問用戶是否已經(jīng)正?？吹接嗁彽碾娮訄?；(4)在用戶無法正?？吹诫娮?報的情況下遠程配置用戶的終端，使終端的配置符合瀏覽電子報的要求；(5)詢問用戶是否需要開通業(yè)務(wù)。例如，假設(shè)管理后臺將這五個體驗規(guī)則發(fā)送給體驗大廳管理服務(wù)器，體驗大廳管 理服務(wù)器首先會向用戶發(fā)送業(yè)務(wù)介紹信息，之后會向用戶發(fā)送免費的手機報，然后向用戶 發(fā)送是否正常瀏覽手機報的信息，然后，可以將對終端進行配置的方式展示發(fā)送給用戶、或 者直接發(fā)送一段代碼給用戶由代碼直接完成終端的配置；最后，還可以向用戶發(fā)送是否訂 購該業(yè)務(wù)的詢問信息。也就是說，本發(fā)明實施例的管理后臺是一個跨體驗平臺的管理系統(tǒng)，與各個渠道 的體驗平臺連接，由于在本申請的實施例中將體驗策略劃分為多個體驗規(guī)則，因此，管理后 臺就能夠體驗過程中的各個階段均進行合理的控制和決策，并且發(fā)送各個體驗平臺均能夠 識別的體驗規(guī)則。另外，在相關(guān)技術(shù)中，體驗門戶網(wǎng)站和體驗廳服務(wù)器各自所掌握的資源并不相同， 在用戶進行體驗時向用戶展示的體驗內(nèi)容也存在差別，因此，即使體驗門戶網(wǎng)站與體驗廳 管理服務(wù)器能夠互相傳遞體驗內(nèi)容，也不能夠識別對方發(fā)送過來的體驗內(nèi)容，但是，這些體 驗平臺是能夠根據(jù)管理后臺發(fā)送的體驗規(guī)則的，因此，也就能夠?qū)⒏髯孕枰l(fā)送的體驗內(nèi) 容發(fā)送給用戶終端，實現(xiàn)業(yè)務(wù)的體驗。并且，在體驗的過程中，本發(fā)明的處理還可以包括以下步驟步驟1，在用戶未體驗完體驗策略中所有體驗規(guī)則對應(yīng)的體驗內(nèi)容時就退出體驗 的情況下，第一體驗平臺能夠?qū)⒂脩舢斍耙呀?jīng)完成體驗的體驗規(guī)則的標識和體驗策略的標 識通知給管理后臺；步驟2，在用戶通過第二體驗平臺繼續(xù)進行體驗時，管理后臺根據(jù)體驗 策略以及用戶當前已經(jīng)體驗完成的體驗規(guī)則確定用戶繼續(xù)進行體驗時的體驗規(guī)則；步驟 3，將確定的體驗規(guī)則和體驗策略的標識通知給第二體驗平臺，以便第二體驗平臺根據(jù)確定 的體驗規(guī)則和體驗策略對用戶推送相應(yīng)的體驗內(nèi)容，其中，第一體驗平臺與第二體驗平臺 相同或不同。以上述場景為例，假設(shè)用戶已經(jīng)在體驗廳體驗了第一個體驗規(guī)則，但是中途退出 體驗，此時體驗廳會將用戶已經(jīng)體驗完的第一個體驗規(guī)則(即，用戶已經(jīng)瀏覽過業(yè)務(wù)介紹) 通知給管理后臺，而當用戶在門戶網(wǎng)站登陸繼續(xù)進行體驗時，管理后臺會根據(jù)體驗策略和 已經(jīng)體驗完的第一個體驗規(guī)則確定，用戶應(yīng)當從第二個體驗規(guī)則繼續(xù)體驗，進而將第二個 體驗規(guī)則的標識通知給體驗門戶網(wǎng)站，根據(jù)第二個體驗規(guī)則，體驗門戶網(wǎng)站會向用戶發(fā)送 免費手機報。也就是說，不論用戶在什么體驗平臺登錄進行業(yè)務(wù)的體驗，或者在什么時候中途 退出體驗，由于管理后臺能夠存儲用戶當前的體驗狀態(tài)(即，當前體驗完成的體驗規(guī)則)， 就能夠在用戶后續(xù)登錄準備繼續(xù)完成體驗時將這一狀態(tài)通過體驗規(guī)則通知給體驗平臺，從 而實現(xiàn)繼續(xù)體驗，避免執(zhí)行重復的體驗步驟。另外，在管理后臺確定需要對用戶采用的體驗策略時，可以根據(jù)用戶的業(yè)務(wù)操作 歷史記錄確定體驗策略，其中，業(yè)務(wù)操作歷史記錄用于表示用戶進行業(yè)務(wù)體驗和業(yè)務(wù)訂購 的情況，該操作歷史記錄可以包括用戶已經(jīng)體驗的業(yè)務(wù)的標識、用戶已經(jīng)體驗的業(yè)務(wù)的類 型、用戶已經(jīng)訂購的業(yè)務(wù)的標識、以及用戶已經(jīng)訂購的業(yè)務(wù)的類型中的一個或其組合，還可 以進一步包括用戶進行訂購、體驗和使用的時間，具體地，基于用戶進行業(yè)務(wù)訂購/體驗的 歷史記錄，管理后臺可以確定用戶的業(yè)務(wù)訂購關(guān)系和使用活躍程度，進而能夠選擇適當?shù)捏w驗策略(體驗規(guī)則的組合)并自動分發(fā)，即，管理后臺并不控制各個渠道的體驗平臺向用 戶展現(xiàn)什么體驗內(nèi)容，只是決定控制規(guī)則所組成的體驗策略，在后臺系統(tǒng)的規(guī)則控制下，每 個體驗平臺再利用其上可用資源根據(jù)體驗規(guī)則展示體驗內(nèi)容(即，由每個體驗平臺來適配 對應(yīng)來自管理后臺體的驗規(guī)則的體驗內(nèi)容)，不同的體驗平臺進行業(yè)務(wù)展示的方式不一定 相同?？蛇x地，管理后臺可以設(shè)置活躍度的多個數(shù)值范圍，每個數(shù)值范圍設(shè)置一個對應(yīng) 的體驗策略，根據(jù)用戶的業(yè)務(wù)操作歷史記錄，管理后臺可以得到用戶的業(yè)務(wù)訂購關(guān)系和活 躍度，并將用戶的活躍度進行量化，根據(jù)量化后的活躍度所在的數(shù)值范圍和業(yè)務(wù)訂購關(guān)系 確定相應(yīng)的體驗策略。另外，管理后臺能夠自行或借助其他方式對用戶訂購或體驗的業(yè)務(wù)以及體驗和訂 購的時間進行統(tǒng)計，確定用戶的偏好，從而進行個性化的體驗推薦，有效提高用戶體驗的智 能度。并且，在管理后臺確定用戶重新登錄時繼續(xù)進行體驗時的體驗規(guī)則時，可以根據(jù) 業(yè)務(wù)操作歷史記錄對體驗策略進行調(diào)整，并根據(jù)用戶已經(jīng)體驗完成的體驗規(guī)則和調(diào)整后的 體驗策略確定用戶繼續(xù)進行體驗時的體驗規(guī)則。例如，以上述列舉的五個體驗規(guī)則的場景為例，假設(shè)用戶完成了第二個體驗規(guī)則 的體驗(即，用戶已經(jīng)收到了免費發(fā)送的手機報)，之后退出體驗，當用戶后續(xù)登錄后，管理 后臺會首先判斷用戶是否完成體驗，并應(yīng)當確定用戶對手機報業(yè)務(wù)的訂購狀況，如果發(fā)現(xiàn) 用戶已經(jīng)訂購了之前體驗的手機報業(yè)務(wù)，則管理后臺就不應(yīng)當繼續(xù)發(fā)送詢問用戶是否訂閱 該業(yè)務(wù)的體驗規(guī)則，從而進一步提高體驗的智能度。具體地，在用戶通過第二體驗平臺繼續(xù)進行體驗時，可以首先判斷用戶是否有未 完成的體驗策略(即，判斷是否有體驗規(guī)則被吊起)，如果判斷為是，則根據(jù)用戶當前的業(yè) 務(wù)操作歷史記錄確定需要對用戶采用的新的體驗策略，并判斷新的體驗策略是否具有與用 戶根據(jù)原體驗策略進行體驗且中途退出時所產(chǎn)生的斷點，如果判斷結(jié)果為是，則執(zhí)行上步 驟2和步驟3 ；如果判斷結(jié)構(gòu)為否，則表示用戶在繼續(xù)進行體驗之前，已經(jīng)進行了有關(guān)該業(yè) 務(wù)的操作，導致原先的體驗策略不適用，此時，管理后臺會根據(jù)用戶已經(jīng)體驗完成的體驗規(guī) 則和新的體驗策略確定用戶繼續(xù)進行體驗時的體驗規(guī)則，并將該體驗規(guī)則的標識和新的體 驗策略的標識通知給第二體驗平臺，由第二體驗平臺繼續(xù)依次執(zhí)行體驗規(guī)則，而不是根據(jù) 原先的體驗規(guī)則進行繼續(xù)體驗。根據(jù)本發(fā)明的另一實施例，提供了一種業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)。如圖4所示，根據(jù)本發(fā)明實施例的系統(tǒng)包括管理后臺41和至少一個體驗平臺，為 了表述清楚，以第一體驗平臺42和第二體驗平臺43進行說明。其中，管理后臺41用于在用戶通過第一體驗平臺42體驗業(yè)務(wù)的情況下，確定需要 對用戶采用的體驗策略，并將體驗策略的標識以及體驗策略中需要首先執(zhí)行的體驗規(guī)則的 標識通知給第一體驗平臺42，其中，體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，體驗規(guī)則是 推送體驗內(nèi)容的規(guī)則；第一體驗平臺42用于根據(jù)來自管理后臺41的體驗策略的標識和需要首先執(zhí)行的 體驗規(guī)則的標識對用戶推送體驗內(nèi)容。并且，第一體驗平臺42還用于在用戶未體驗完體驗策略中所有體驗規(guī)則對應(yīng)的體驗內(nèi)容時就退出體驗的情況下，將用戶當前已經(jīng)完成體驗的體驗規(guī)則的標識和體驗策略 的標識通知給管理后臺41 ；而管理后臺41還用于在用戶通過第二體驗平臺43繼續(xù)進行體 驗的情況下，根據(jù)體驗策略以及用戶當前已經(jīng)體驗完成的體驗規(guī)則確定用戶繼續(xù)進行體驗 時的體驗規(guī)則，并將確定的體驗規(guī)則的標識和體驗策略的標識通知給第二體驗平臺43 ；第 二體驗平臺43用于在用戶通過第二體驗平臺43繼續(xù)進行體驗時，根據(jù)管理后臺41確定的 體驗規(guī)則的標識和體驗策略的標識對用戶推送相應(yīng)的體驗內(nèi)容。為了進一步提高業(yè)務(wù)體驗的智能度，上述系統(tǒng)還可以進一步包括客戶關(guān)系服務(wù)器(圖4中未示出)，與管理后臺連接，用于保存用戶的業(yè)務(wù)操作歷 史記錄，其中，業(yè)務(wù)操作歷史記錄用于表示用戶進行業(yè)務(wù)體驗和業(yè)務(wù)訂購的情況；基于此， 用戶管理后臺還可以用于根據(jù)業(yè)務(wù)操作歷史記錄對體驗策略進行調(diào)整，并根據(jù)用戶已經(jīng)體 驗完成的體驗規(guī)則和調(diào)整后的體驗策略確定用戶繼續(xù)進行體驗時的體驗規(guī)則；具體地，在 用戶重新登錄進行體驗時，管理后臺此時可以根據(jù)用戶當前的訂購關(guān)系和活躍程度選擇適 配的體驗策略，如果這時客戶適配的體驗策略已經(jīng)和保存的斷點不一致(即，用戶進行了 新的業(yè)務(wù)訂購和體驗等操作，導致原本為該用戶確定的體驗策略目前已經(jīng)不適用于該用 戶)，則需要根據(jù)新確定體驗策略完成用戶的體驗。之前已經(jīng)提到，為了提高業(yè)務(wù)體驗的智能度，管理后臺可以借助其他網(wǎng)元的協(xié)助， 例如，可以將與數(shù)據(jù)分析系統(tǒng)、業(yè)務(wù)平臺等進行連接，這樣，管理后臺就能夠從數(shù)據(jù)分析系 統(tǒng)獲取用戶訂購和體驗業(yè)務(wù)的統(tǒng)計結(jié)果，通過業(yè)務(wù)平臺能夠獲知業(yè)務(wù)的諸多詳細介紹和業(yè) 務(wù)功能的更新等信息。另外，在實際應(yīng)用中，管理后臺可以同步記錄多個渠道的每個客戶的體驗信息，并 且通過實時的數(shù)據(jù)交互過程，實現(xiàn)客戶在多個渠道的體驗連續(xù)性。應(yīng)當注意，之前以第一和第二體驗平臺進行描述僅僅是出于清楚的目的，實際應(yīng) 用中，體驗平臺的數(shù)量可以為兩個以上，并且每個體驗平臺都可以具有將用戶體驗時中途 退出時體驗策略的斷點通知給管理后臺、以及根據(jù)后臺通知的體驗策略和需要執(zhí)行的體驗 規(guī)則標識為重新登錄的用戶實現(xiàn)繼續(xù)體驗的功能。圖5是根據(jù)本發(fā)明實例的業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)的具體結(jié)構(gòu)實例的框圖。如圖5所示，管理后臺與數(shù)據(jù)分析系統(tǒng)、客戶關(guān)系服務(wù)器、業(yè)務(wù)平臺、以及體驗平 臺連接，其中，管理后臺可以包括體驗管理服務(wù)器、體驗數(shù)據(jù)服務(wù)器和體驗接口服務(wù)器，具 體地，體驗平臺可以包括體驗廳管理服務(wù)器和門戶網(wǎng)站接口服務(wù)器。與管理后臺連接的數(shù)據(jù)分析系統(tǒng)能夠根據(jù)管理后臺統(tǒng)計的一個或多個用戶進行 業(yè)務(wù)體驗等業(yè)務(wù)操作的歷史記錄或進一步結(jié)合業(yè)務(wù)平臺的用戶數(shù)據(jù)進行總結(jié)和統(tǒng)計，得到 統(tǒng)計結(jié)果。根據(jù)數(shù)據(jù)分析系統(tǒng)提供的數(shù)據(jù)，管理后臺能夠更有針對性地決策應(yīng)當如何進行 業(yè)務(wù)體驗的推薦?？蛻絷P(guān)系服務(wù)器中保存了用戶進行業(yè)務(wù)體驗、業(yè)務(wù)訂購等業(yè)務(wù)操作的歷 史記錄，根據(jù)客戶關(guān)系服務(wù)器中保存的歷史記錄，不僅能夠?qū)崿F(xiàn)用戶中途退出體驗后、在重 新登錄時在之前從退出而沒有完成的體驗規(guī)則繼續(xù)完成體驗，而且管理后臺還能夠根據(jù)客 戶關(guān)系服務(wù)器中的歷史記錄對用戶的體驗策略進行動態(tài)調(diào)整，進一步提高系統(tǒng)的智能度； 業(yè)務(wù)平臺是開展業(yè)務(wù)的網(wǎng)元，其中會不斷更新得到新的業(yè)務(wù)以及升級后的業(yè)務(wù)，管理后臺 可以根據(jù)業(yè)務(wù)的更新狀況得到新的業(yè)務(wù)介紹，并通過修改業(yè)務(wù)體驗規(guī)則。這樣，不僅能夠?qū)?現(xiàn)不同類型的體驗平臺上進行的業(yè)務(wù)體驗得到集中管理和決策，并且能夠為體驗廳終端用戶和門戶網(wǎng)站用戶提供更加智能和個性化的體驗。在本發(fā)明中的該系統(tǒng)中，可以將不同的體驗規(guī)則按照業(yè)務(wù)介紹、使用方法、高手秘 笈、趣味體驗、業(yè)務(wù)試用、客戶端下載、業(yè)務(wù)訂購等分類，進行歸屬和編號，每個體驗規(guī)則作 為一個不可分割的原子操作對待，并分別建立各自分屬的類別碼和編號。其中，體驗規(guī)則可 以是用于根據(jù)業(yè)務(wù)名稱、客戶訂購關(guān)系、客戶的活躍度三個緯度表示如何推送體驗內(nèi)容的 規(guī)則，例如，對于彩鈴業(yè)務(wù)，加入一個用戶與該業(yè)務(wù)存在訂購關(guān)系，但是該用戶的活躍度較 低，此時，在需要對該用戶進行彩鈴業(yè)務(wù)體驗時，可以推送一首特定的免費彩鈴下載，此時， 向用戶提供免費彩鈴下載就構(gòu)成了一個體驗規(guī)則，而提供下載時當如何展示界面、如何和 用戶完成互動以便讓用戶選擇期望下載的音樂，是某個特定體驗平臺根據(jù)體驗規(guī)則進行適 配得到的體驗內(nèi)容，并且該鈴聲可以屬于業(yè)務(wù)試用類別并具備相應(yīng)的編號。在用戶進行業(yè) 務(wù)體驗時，體驗平臺可以根據(jù)從CRM系統(tǒng)獲得的客戶業(yè)務(wù)訂購關(guān)系，從分析系統(tǒng)獲得的客 戶活躍狀態(tài)(每個活躍狀態(tài)有自己的不同定義，例如，如果用戶在一個月內(nèi)變更過彩鈴歌 曲或者同時訂購了音樂盒業(yè)務(wù)，則可以認為該用戶在彩鈴業(yè)務(wù)方面的活躍度較高)以及提 前分發(fā)的體驗規(guī)則，這樣就能夠為客戶自動生成一個體驗內(nèi)容，每個體驗內(nèi)容都有一個相 應(yīng)的體驗規(guī)則，根據(jù)體驗策略的優(yōu)先級順序，根據(jù)生成的不同的體驗內(nèi)容，進行個性化的業(yè) 務(wù)體驗。從而有效避免了體驗內(nèi)容每次都從統(tǒng)一后臺分發(fā)，導致數(shù)據(jù)傳輸量大，而且難以進 行斷點保存的問題。在上述系統(tǒng)中，每個體驗規(guī)則對應(yīng)的體驗內(nèi)容或者步驟是在后臺進行開發(fā)，并統(tǒng) 一分發(fā)到各個體驗平臺(分發(fā)的方式可以是FTP或其他方式，本文不再一一列舉)，由這些 體驗平臺根據(jù)體驗規(guī)則通過具體界面和方式將體驗內(nèi)容展示給用戶。本發(fā)明實施例中，體驗管理后臺與數(shù)據(jù)分析平臺、客戶關(guān)系服務(wù)器、以及業(yè)務(wù)平臺 連接，在工作中，管理后臺與這些平臺實時進行數(shù)據(jù)交換，處理對應(yīng)的數(shù)據(jù)業(yè)務(wù)。為了保障 客戶在不同渠道的體驗的一致性，在管理后臺配置統(tǒng)一的體驗策略，然后發(fā)布到每個體驗 平臺的管理控制服務(wù)器，各個平臺的管理控制服務(wù)器負責體驗規(guī)則的執(zhí)行。如圖6所示，具 體的實現(xiàn)過程如下步驟601，管理后臺配置體驗規(guī)則，圖5中管理后臺的體驗管理服務(wù)器得到配置的 體驗規(guī)則；步驟602，體驗管理服務(wù)器對配置的體驗規(guī)則進行沖突檢測；步驟603，體驗管理服務(wù)器將體驗規(guī)則發(fā)布到各個體驗平臺的獨立服務(wù)器(例如， 體驗廳管理服務(wù)器和門戶網(wǎng)站接口服務(wù)器)；步驟604，體驗平臺各自的服務(wù)器保存并加載體驗規(guī)則。具體地，每個體驗平臺的 接口服務(wù)器在接收每個體驗規(guī)則后可以將該體驗規(guī)則加載到體驗邏輯引擎中，以便后續(xù)執(zhí) 行。圖7是根據(jù)本發(fā)明實施例的業(yè)務(wù)體驗的詳細處理過程的信令流程圖。如圖7所示， 身份鑒別的過程如下步驟701，體驗終端發(fā)送推送請求給體驗平臺；步驟702，體驗平臺將查詢用戶狀態(tài)請求發(fā)送給管理后臺；步驟703，管理后臺向客戶關(guān)系服務(wù)器發(fā)送用戶身份鑒別請求；步驟704，如果身份鑒別結(jié)果為用戶合法，則管理后臺在數(shù)據(jù)分析系統(tǒng)或其本地查詢該用戶的行為信息；步驟705，管理后臺查詢該用戶目前未完成體驗的中斷點狀態(tài)信息(即，查詢該用 戶是否有未完成的體驗)和歷史體驗信息；步驟706，管理后臺向體驗平臺返回體驗策略中未完成(吊起)的體驗規(guī)則標識 (編號)，之后，管理后臺可以更新用戶的體驗狀態(tài)信息，更新為用戶戶又繼續(xù)開始體驗；步驟707，體驗平臺生成體驗內(nèi)容；步驟708，體驗平臺生成體驗界面；步驟709，體驗平臺將體驗界面推送給體驗終端。如果此后用戶請求開始某個具體的業(yè)務(wù)體驗過程，體驗平臺需要將體驗請求發(fā)送 給管理后臺；管理后臺需要根據(jù)用戶的信息查找適配的規(guī)則編號，并返回給體驗平臺，并更 新體驗狀態(tài)信息；之后，體驗平臺針對本次管理平臺發(fā)布的體驗規(guī)則生成體驗內(nèi)容和界面， 并推送界面給體驗終端。在圖7所示的處理過程中，客戶身份鑒別是用來鑒別該客戶是否是合法的體驗用 戶、以及確定該用戶目前的存在的業(yè)務(wù)訂購關(guān)系，同時從分析系統(tǒng)查詢客戶存在訂購關(guān)系 的業(yè)務(wù)的行為信息，并將該信息轉(zhuǎn)換為活躍狀態(tài)，從而確定客戶適配的體驗規(guī)則，并將相應(yīng) 適配的規(guī)則編號發(fā)送給體驗平臺，由體驗平臺根據(jù)這些體驗規(guī)則生成體驗內(nèi)容。另外，如果 發(fā)現(xiàn)該用戶有吊起的體驗規(guī)則，則先發(fā)送掉起的體驗規(guī)則，完成未完成的體驗。另外，通過 查詢客戶體驗狀態(tài)信息，可以查詢客戶目前正在哪個渠道服務(wù)器管理下進行體驗，如果在 查詢客戶已經(jīng)在某個體驗環(huán)境下進行體驗的過程中，則發(fā)送錯誤信息，防止同一用戶同時 重復體驗和訂購業(yè)務(wù)。具體地，在用戶同時通過兩個或更多不同的體驗平臺實現(xiàn)同一體驗策略對應(yīng)的體 驗過程而導致體驗出現(xiàn)異常時，可以執(zhí)行圖8所示的處理，具體過程如下步驟801，體驗終端發(fā)送推送請求給體驗平臺；步驟802，體驗平臺將查詢用戶狀態(tài)請求發(fā)送給管理后臺；步驟803，管理后臺向客戶關(guān)系服務(wù)器發(fā)送用戶身份鑒別請求；步驟804，如果身份鑒別結(jié)果為用戶合法，則管理后臺查詢該用戶生效的體驗規(guī) 則；步驟805，管理后臺查詢該用戶的狀態(tài)信息和行為信息；步驟806，管理后臺查詢到該用戶同時通過兩個或更多不同的體驗平臺實現(xiàn)同一 體驗策略對應(yīng)的體驗過程，則向體驗平臺返回重復信息(表示用戶體驗過程出現(xiàn)異常)；步驟807，體驗平臺生成提示界面；步驟808，體驗平臺將提示界面推送給體驗終端。圖9是體驗平臺檢測到用戶中途退出體驗的情況下收集用戶當前體驗的狀態(tài)信 息的處理信令流程圖。如圖9所示，具體的處理過程如下步驟901，體驗平臺檢測用戶的操作；步驟902，體驗平臺檢測體驗的執(zhí)行過程中用戶是否退出體驗，在本實施例中，當 用戶在兩分鐘(或其他時間段)內(nèi)沒有進行任何操作，或者用戶在體驗界面點擊離開按鈕， 則判斷用戶已經(jīng)中途退出體驗，此時需要向管理后臺傳輸數(shù)據(jù)；應(yīng)當注意，這里判斷用戶是 否中途退出的方式僅僅是一個具體的實例，并不用于限定本發(fā)明；
步驟903，在確定用戶中途退出的情況下，體驗平臺就收集客戶當前體驗信息，具 體地，可以提取用戶當前的體驗規(guī)則編號以及用來生成體驗內(nèi)容的編號序列表；步驟904，體驗平臺向管理后臺發(fā)送信息同步請求；步驟905，管理后臺返回同意啟動信息同步的指示；步驟906，體驗平臺將記錄的該用戶的體驗信息發(fā)送給管理后臺；接著，管理后臺保存體驗平臺發(fā)送的體驗信息；之后，管理后臺可以與分析系統(tǒng) 完成該用戶的體驗歷史信息和狀態(tài)信息的同步，變更該用戶的體驗狀態(tài)為未完成體驗的狀 態(tài)；如果步驟902中體驗平臺判斷用戶沒有退出體驗，則根據(jù)從管理后臺接收的體驗 規(guī)則繼續(xù)生成體驗界面并向體驗終端推送體驗界面。圖10是用戶中途退出體驗后重新登錄進行繼續(xù)體驗的處理流程圖。如圖10所示，具體過程如下步驟1001，體驗平臺檢測用戶的操作；步驟1002，如用戶請求體驗，則體驗平臺將用戶的請求推送給管理后臺；步驟1003，管理后臺判斷該用戶是否有未下線的懸掛的體驗規(guī)則(即，判斷該用 戶是否完成了之前的體驗過程)；如果判斷為是，則執(zhí)行步驟1004和步驟1005 ；步驟1004，管理后臺將體驗信息發(fā)送給體驗平臺，其中包含用戶需要繼續(xù)體驗的 體驗規(guī)則；步驟1005，根據(jù)管理后臺的體驗狀態(tài)信息，體驗平臺找到具體的體驗規(guī)則序列并 生成體驗界面，之后將體驗界面推送給終端，從而使用戶完成之前未完成的體驗；如果步驟1003的判斷結(jié)構(gòu)為否，則管理后臺查詢用戶的業(yè)務(wù)訂購關(guān)系，之后執(zhí)行 步驟1007 ；步驟1007，管理后臺向分析系統(tǒng)查詢用戶的業(yè)務(wù)使用記錄；步驟1008，分析系統(tǒng)向管理后臺返回用戶的業(yè)務(wù)使用信息；步驟1009，管理后臺將用戶的業(yè)務(wù)使用信息轉(zhuǎn)換為活躍度信息并臨時保存；如果用戶開始體驗新的業(yè)務(wù)，體驗平臺會將用戶希望體驗的業(yè)務(wù)編碼通知給管理 后臺；管理后臺會生成適配的體驗規(guī)則編碼序列(體驗策略)，并發(fā)送給體驗平臺；體驗平 臺會生成相應(yīng)的體驗內(nèi)容，并生成新的體驗界面，之后將該界面發(fā)送給體驗終端。借助于本發(fā)明的上述技術(shù)方案，通過一個通用的體驗管理后臺將業(yè)務(wù)體驗過程所 對應(yīng)的體驗邏輯(體驗策略)劃分為多個體驗規(guī)則，體驗規(guī)則由管理后臺統(tǒng)一生成并分發(fā) 到各個不同的體驗前端系統(tǒng)(體驗前端系統(tǒng)就是用戶進行業(yè)務(wù)體驗時所借助的體驗平臺， 其可以是定制化的體驗機也可以是體驗門戶網(wǎng)站等)，這樣，前端體驗系統(tǒng)就能夠根據(jù)體驗 規(guī)則生成適當?shù)捏w驗內(nèi)容展現(xiàn)給客戶。體驗策略有一系列這樣的體驗規(guī)則組成，并由管理 后臺根據(jù)使用客戶的在運營商業(yè)務(wù)系統(tǒng)的使用記錄來生成不同的體驗策略，由管理后臺將 體驗策略通知給用戶進行體驗時所使用的體驗平臺，這樣，不論用戶通過什么體驗平臺進 行業(yè)務(wù)體驗，這些體驗平臺都能夠根據(jù)管理后臺指示的體驗規(guī)則向用戶提供相應(yīng)的體驗內(nèi) 容，由于網(wǎng)絡(luò)中傳輸?shù)膬H僅是體驗規(guī)則的標識，因此能夠避免大量數(shù)據(jù)在網(wǎng)絡(luò)中傳輸，同時 有助于體驗平臺將規(guī)則上報給管理后臺，并且，由于體驗策略由管理后臺確定，因此，使得 用戶的體驗?zāi)軌虻玫焦芾砗笈_的控制，有助于提高體驗的智能度，避免重復體驗的問題出現(xiàn)。 以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精 神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
一種業(yè)務(wù)體驗的實現(xiàn)方法，其特征在于，所述方法包括在用戶通過第一體驗平臺體驗業(yè)務(wù)的情況下，管理后臺確定需要對所述用戶采用的體驗策略，其中，所述體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，所述體驗規(guī)則是推送體驗內(nèi)容的規(guī)則；所述管理后臺將所述體驗策略的標識以及所述體驗策略中需要首先執(zhí)行的體驗規(guī)則的標識通知給所述第一體驗平臺，以便所述第一體驗平臺根據(jù)所述體驗策略的標識和所述需要首先執(zhí)行的體驗規(guī)則的標識對所述用戶推送所述體驗內(nèi)容。
2.根據(jù)權(quán)利要求1所述的實現(xiàn)方法，其特征在于，在所述用戶未體驗完所述體驗策略 中所有體驗規(guī)則對應(yīng)的體驗內(nèi)容時就退出體驗的情況下，進一步包括步驟1，所述第一體驗平臺將所述用戶當前已經(jīng)完成體驗的體驗規(guī)則的標識和所述體 驗策略的標識通知給所述管理后臺；步驟2，在所述用戶通過第二體驗平臺繼續(xù)進行體驗時，所述管理后臺根據(jù)所述體驗 策略以及所述用戶當前已經(jīng)體驗完成的體驗規(guī)則確定所述用戶繼續(xù)進行體驗時的體驗規(guī) 則；步驟3，所述管理后臺將確定的所述體驗規(guī)則的標識和所述體驗策略的標識通知給所 述第二體驗平臺，以便所述第二體驗平臺根據(jù)確定的所述體驗規(guī)則對所述用戶推送相應(yīng)的 體驗內(nèi)容，其中，所述第一體驗平臺與所述第二體驗平臺相同或不同。
3.根據(jù)權(quán)利要求2所述的實現(xiàn)方法，其特征在于，在所述管理后臺確定所述用戶繼續(xù) 進行體驗時的體驗規(guī)則進一步包括在所述用戶通過第二體驗平臺繼續(xù)進行體驗時，根據(jù)所述業(yè)務(wù)操作歷史記錄確定需要 對所述用戶采用的新的體驗策略，并判斷所述新的體驗策略是否具有與用戶根據(jù)原體驗策 略進行體驗且中途退出時所產(chǎn)生的斷點，如果判斷結(jié)果為是，則執(zhí)行所述步驟2和所述步 驟3 ；如果判斷結(jié)構(gòu)為否，則根據(jù)所述用戶已經(jīng)體驗完成的體驗規(guī)則和所述新的體驗策略 確定所述用戶繼續(xù)進行體驗時的體驗規(guī)則，并將該體驗規(guī)則的標識和所述新的體驗策略的 標識通知給所述第二體驗平臺，處理結(jié)束。
4.根據(jù)權(quán)利要求2或3所述的實現(xiàn)方法，其特征在于，所述管理后臺確定需要對用戶采 用的體驗策略包括所述管理后臺根據(jù)所述用戶的業(yè)務(wù)操作歷史記錄確定所述體驗策略，其中，所述業(yè)務(wù) 操作歷史記錄用于表示所述用戶進行業(yè)務(wù)體驗和業(yè)務(wù)訂購的情況。
5.根據(jù)權(quán)利要求4所述的實現(xiàn)方法，其特征在于，所述歷史記錄包括以下至少之一所述用戶已經(jīng)體驗的業(yè)務(wù)的標識，所述用戶已經(jīng)體驗的業(yè)務(wù)的類型，所述用戶已經(jīng)訂購的業(yè)務(wù)的標識，所述用戶已經(jīng)訂購的業(yè)務(wù)的類型，所述用戶體驗業(yè)務(wù)、訂購業(yè)務(wù)以及使用 業(yè)務(wù)的時間。
6.根據(jù)權(quán)利要求1至3中任一項所述的實現(xiàn)方法，其特征在于，所述至少一個業(yè)務(wù)規(guī)則 由所述管理后臺預(yù)先根據(jù)體驗策略所對應(yīng)的體驗流程中不同的體驗階段劃分得到。
7.根據(jù)權(quán)利要求2所述的實現(xiàn)方法，其特征在于，所述第一體驗平臺和所述第二體驗 平臺包括以下至少之一體驗門戶網(wǎng)站、體驗廳管理服務(wù)器。
8.—種業(yè)務(wù)體驗的實現(xiàn)系統(tǒng)，其特征在于，所述系統(tǒng)包括管理后臺和第一體驗平臺，其中，所述管理后臺用于在用戶通過所述第一體驗平臺體驗業(yè)務(wù)的情況下，確定需要對所述 用戶采用的體驗策略，并將所述體驗策略的標識以及所述體驗策略中需要首先執(zhí)行的體驗 規(guī)則的標識通知給所述第一體驗平臺，其中，所述體驗策略由至少一個體驗規(guī)則有序地構(gòu) 成，所述體驗規(guī)則是推送體驗內(nèi)容的規(guī)則；所述第一體驗平臺用于根據(jù)來自所述管理后臺的所述體驗策略的標識和所述需要首 先執(zhí)行的體驗規(guī)則的標識對所述用戶推送所述體驗內(nèi)容。
9.根據(jù)權(quán)利要求8所述的實現(xiàn)系統(tǒng)，其特征在于，還包括第二體驗平臺，其中，所述第一體驗平臺還用于在所述用戶未體驗完所述體驗策略中所有體驗規(guī)則對 應(yīng)的體驗內(nèi)容時就退出體驗的情況下，將所述用戶當前已經(jīng)完成體驗的體驗規(guī)則的標識和 所述體驗策略的標識通知給所述管理后臺；所述管理后臺還用于在所述用戶通過所述第二體驗平臺繼續(xù)進行體驗的情況下，根據(jù) 所述體驗策略以及所述用戶當前已經(jīng)體驗完成的體驗規(guī)則確定所述用戶繼續(xù)進行體驗時 的體驗規(guī)則，并將確定的所述體驗規(guī)則的標識和所述體驗策略的標識通知給所述第二體驗 平臺；所述第二體驗平臺用于在所述用戶通過第二體驗平臺繼續(xù)進行體驗時，根據(jù)所述管理 后臺確定的所述體驗規(guī)則的標識和所述體驗策略的標識對所述用戶推送相應(yīng)的體驗內(nèi)容。
10.根據(jù)權(quán)利要求9所述的實現(xiàn)系統(tǒng)，其特征在于，進一步包括客戶關(guān)系服務(wù)器，用于保存所述用戶的業(yè)務(wù)操作歷史記錄，其中，所述業(yè)務(wù)操作歷史記 錄用于表示所述用戶進行業(yè)務(wù)體驗和業(yè)務(wù)訂購的情況；所述用戶所述管理后臺還用于根據(jù)業(yè)務(wù)操作歷史記錄對所述體驗策略進行調(diào)整，并根 據(jù)所述用戶已經(jīng)體驗完成的體驗規(guī)則和調(diào)整后的所述體驗策略確定所述用戶繼續(xù)進行體 驗時的體驗規(guī)則。
11.根據(jù)權(quán)利要求8至10中任一項所述的實現(xiàn)系統(tǒng)，其特征在于，所述管理后臺還用于 預(yù)先根據(jù)體驗策略所對應(yīng)的體驗流程中不同的體驗階段劃分得到所述至少一個業(yè)務(wù)規(guī)則。
全文摘要
本發(fā)明公開了一種業(yè)務(wù)體驗的實現(xiàn)方法和系統(tǒng)，該方法包括在用戶通過第一體驗平臺體驗業(yè)務(wù)的情況下，管理后臺確定需要對用戶采用的體驗策略，其中，體驗策略由至少一個體驗規(guī)則有序地構(gòu)成，體驗規(guī)則是推送體驗內(nèi)容的規(guī)則；管理后臺將體驗策略的標識以及體驗策略中需要首先執(zhí)行的體驗規(guī)則的標識通知給第一體驗平臺，以便第一體驗平臺根據(jù)體驗策略的標識和需要首先執(zhí)行的體驗規(guī)則的標識對用戶推送體驗內(nèi)容。通過本發(fā)明，不論用戶通過什么體驗平臺進行業(yè)務(wù)體驗，這些體驗平臺都能夠根據(jù)管理后臺指示的體驗規(guī)則向用戶提供相應(yīng)的體驗內(nèi)容，避免大量數(shù)據(jù)在網(wǎng)絡(luò)中傳輸，有助于體驗平臺將規(guī)則上報給管理后臺，且能使用戶的體驗?zāi)軌虻玫焦芾砗笈_的控制。
文檔編號H04M3/42GK101997914SQ20101053086
公開日2011年3月30日 申請日期2010年10月29日 優(yōu)先權(quán)日2010年10月29日
發(fā)明者唐勇, 孫錚, 張輝, 潘宏筠, 高鍵 申請人:中國移動通信集團北京有限公司