业务体验的实现方法和系统 【技术领域】
本发明涉及通信领域， 尤其涉及一种业务体验的实现方法和系统。背景技术 目前， 电信增值业务正在快速发展， 面对越来越多的增值业务， 用户通常希望在开 通增值业务之前能够对增值业务进行体验， 在经过试用之后决定是否进行订购和开通。面 对用户的体验需求， 运营商会开设业务体验厅和体验门户网站等多种体验平台， 通过体验 厅和体验门户网站， 用户可以对增值业务进行体验。
图 1 是相关技术中业务体验厅的系统示意图。如图 1 所示， 在体验厅系统中， 体验 厅管理服务器与多个体验终端连接， 当用户使用体验终端进行体验时， 体验厅管理服务器 就能够通过体验终端向用户呈现体验的业务内容， 实现用户对增值业务的试用， 这样， 就能 够使用户切身了解到增值业务的功能和具体情况后， 根据自身的意愿判断是否开通对应的 增值业务。
具体地， 在图 1 所示的体验系统中， 预先定义的体验逻辑 ( 即， 体验策略 )、 界面、 以 及相关文件均可以保存在体验厅服务器中， 客户登录体验终端时， 根据客户的操作， 给客户 推送动态的内容， 例如， 文字、 动画、 介绍信息等。 体验终端还包括实体的设备， 例如， 摘机系 统， 如果客户摘下某款手机， 则可以在旁边的显示屏幕上给客户推送这款手机的卖点、 适配 业务、 换购政策等。
另外， 随着互联网体验营销的发展， 运营商也建设了体验门户网站， 并将业务介 绍、 动画教程、 以及互动操作等集成在网站上， 如图 2 所示， 用户可以上网终端通过登录体 验门户网站， 由体验门户网站向上网终端传输体验内容， 达到业务体验的目的。
在用户基于目前的业务体验平台体验业务时， 体验内容的数据直接从体验门户网 站或体验厅管理服务器传输给用户的终端， 而具体每次体验的过程和结果对于上层设备是 不可知的， 也是无法被上层设备控制的。另外， 上述的这两种业务体验方式之间并没有实 现有效的联动， 例如， 当通用户在体验厅进行体验后， 如果用户之后登陆体验门户网站期望 继续体验， 由于门户网站系统无法获得该客户进行业务体验的历史数据， 所以无法基于用 户进行体验的历史结果为客户提供个性化推荐， 例如， 用户已经订阅了手机早报业务， 或者 用户已经体验过手机早报业务， 对手机电子报纸已经有所了解， 但是， 当用户登陆体验平台 进行体验时， 由于体验平台无法获知用户已经订阅或体验了手机早报， 因此， 无法确定用户 是否已经对手机上的各种电子报纸有所了解， 而是需要假设用户对手机电子报纸完全不了 解， 提示用户是否需要对手机电子报纸业务进行介绍， 而不能够主动地向用户介绍其他类 型的手机报纸的内容概要， 导致体验过程出现大量的重复处理， 不仅会影响用户体验， 还会 降低体验的效率， 增加体验系统的处理负担。
造成上述问题的原因在于， 目前的体验系统中， 如果希望将具体的体验场景进行 重现或传输， 每进行一次这种操作， 就需要传输大量的信息， 而目前用户进行业务体验的数 量是相当大的， 因此， 对于目前的网络而言是无法实现这种大量数据交互的。
目前， 针对相关技术中由于网络传输存在的限制导致业务体验智能度低、 重复处 量理大、 体验效率差的问题， 尚未提出有效的解决方案。 发明内容 针对相关技术中的问题， 本发明提出一种业务体验的实现方法和系统， 能够有效 避免相关技术中由于不同体验平台无法进行联动、 网络上层设备不能够控制和管理体验过 程的问题， 从而提高体验的智能度和效率、 降低网络负担。
本发明的技术方案是这样实现的 ：
根据本发明的一个方面， 提供了一种业务体验的实现方法。
该方法包括 ： 在用户通过第一体验平台体验业务的情况下， 管理后台确定需要对 用户采用的体验策略， 其中， 体验策略由至少一个体验规则有序地构成， 体验规则是推送体 验内容的规则 ； 管理后台将体验策略的标识以及体验策略中需要首先执行的体验规则的标 识通知给第一体验平台， 以便第一体验平台根据体验策略的标识和需要首先执行的体验规 则的标识对用户推送体验内容。
其中， 在用户未体验完体验策略中所有体验规则对应的体验内容时就退出体验的 情况下， 该方法可以进一步包括 ： 步骤 1， 第一体验平台将用户当前已经完成体验的体验规 则的标识和体验策略的标识通知给管理后台 ； 步骤 2， 在用户通过第二体验平台继续进行 体验时， 管理后台根据体验策略以及用户当前已经体验完成的体验规则确定用户继续进行 体验时的体验规则 ； 步骤 3， 管理后台将确定的体验规则的标识和体验策略的标识通知给 第二体验平台， 以便第二体验平台根据确定的体验规则对用户推送相应的体验内容， 其中， 第一体验平台与第二体验平台相同或不同。
并且， 在管理后台确定用户继续进行体验时的体验规则进一步包括 ： 在用户通过 第二体验平台继续进行体验时， 根据业务操作历史记录确定需要对用户采用的新的体验策 略， 并判断新的体验策略是否具有与用户根据原体验策略进行体验且中途退出时所产生的 断点， 如果判断结果为是， 则执行步骤 2 和步骤 3 ； 如果判断结构为否， 则根据用户已经体验 完成的体验规则和新的体验策略确定用户继续进行体验时的体验规则， 并将该体验规则的 标识和新的体验策略的标识通知给第二体验平台， 处理结束。
另外， 管理后台确定需要对用户采用的体验策略包括 ： 管理后台根据用户的业务 操作历史记录确定体验策略， 其中， 业务操作历史记录用于表示用户进行业务体验和业务 订购的情况。
可选地， 历史记录包括以下至少之一 ： 用户已经体验的业务的标识， 用户已经体验 的业务的类型， 用户已经订购的业务的标识， 用户已经订购的业务的类型， 用户体验业务、 订购业务以及使用业务的时间。
另外， 至少一个业务规则由管理后台预先根据体验策略所对应的体验流程中不同 的体验阶段划分得到。
可选地， 第一体验平台和第二体验平台包括以下至少之一 ： 体验门户网站、 体验厅 管理服务器。
根据本发明的另一方面， 提供了一种业务体验的实现系统。
根据本发明的业务体验的实现系统包括管理后台和第一体验平台， 其中， 管理后
台用于在用户通过第一体验平台体验业务的情况下， 确定需要对用户采用的体验策略， 并 将体验策略的标识以及体验策略中需要首先执行的体验规则的标识通知给第一体验平台， 其中， 体验策略由至少一个体验规则有序地构成， 体验规则是推送体验内容的规则 ； 第一体 验平台用于根据来自管理后台的体验策略的标识和需要首先执行的体验规则的标识对用 户推送体验内容。
该系统还包括第二体验平台， 其中， 第一体验平台还用于在用户未体验完体验策 略中所有体验规则对应的体验内容时就退出体验的情况下， 将用户当前已经完成体验的体 验规则的标识和体验策略的标识通知给管理后台 ； 管理后台还用于在用户通过第二体验平 台继续进行体验的情况下， 根据体验策略以及用户当前已经体验完成的体验规则确定用户 继续进行体验时的体验规则， 并将确定的体验规则的标识和体验策略的标识通知给第二体 验平台 ； 第二体验平台用于在用户通过第二体验平台继续进行体验时， 根据管理后台确定 的体验规则的标识和体验策略的标识对用户推送相应的体验内容。
该系统可以进一步包括 ： 客户关系服务器， 用于保存用户的业务操作历史记录， 其 中， 业务操作历史记录用于表示用户进行业务体验和业务订购的情况 ； 用户管理后台还用 于根据业务操作历史记录对体验策略进行调整， 并根据用户已经体验完成的体验规则和调 整后的体验策略确定用户继续进行体验时的体验规则。 此外， 上述管理后台还用于预先根据体验策略所对应的体验流程中不同的体验阶 段划分得到至少一个业务规则。
本发明通过一个通用的体验管理后台将业务体验过程所对应的体验逻辑 ( 即， 体 验策略 ) 划分为多个体验规则， 体验规则由管理后台统一生成并分发到各个不同的体验前 端系统 ( 体验前端系统就是用户进行业务体验时所借助的体验平台， 其可以是定制化的体 验机也可以是体验门户网站等 )， 这样， 前端体验系统就能够根据体验规则生成适当的体验 内容展现给客户， 不论用户通过什么体验平台进行业务体验， 这些体验平台都能够根据管 理后台指示的体验规则向用户提供相应的体验内容， 由于网络中传输的仅仅是体验规则的 标识， 因此能够避免大量数据在网络中传输， 同时有助于体验平台将规则上报给管理后台， 并且， 由于体验策略由管理后台确定， 因此， 使得用户的体验能够得到管理后台的控制， 有 助于提高体验的智能度， 避免重复体验的问题出现。
附图说明
图 1 是相关技术中体验厅管理服务器与体验终端连接的结构示意图 ；
图 2 是相关技术中体验门户网站与上网终端连接的结构示意图 ；
图 3 是根据本发明实施例的业务体验的实现方法的流程图 ；
图 4 是根据本发明实施例的业务体验的实现系统的结构框图 ；
图 5 是根据本发明实施例的业务体验的实现系统的部署实例的框图 ；
图 6 是根据本发明实施例的业务体验的实现过程中体验规则发布的信令流程图 ；
图 7 是根据本发明实施例的业务体验过程的具体处理过程的信令流程图 ；
图 8 是根据本发明实施例的业务体验过程出现异常的信令流程图 ；
图 9 是根据本发明实施例的业务体验过程中用户在一次体验未完成的情况下退 出体验的信令流程图 ；图 10 是根据本发明实施例的业务体验过程中用户在一次体验未完成的情况下退 出体验后重新登录并继续体验的信令流程图。具体实施方式
针对相关技术中由于网络传输的局限性， 使得多体验平台的数据不能够互通， 并 且体验过程不能够得到其他上层网元设备的协助， 导致业务体验不能够跨平台进行， 并且 无法在中断后继续执行， 且体验过程智能度较低的问题， 本发明提出， 将业务体验过程所对 应的体验策略划分为多个体验规则 ( 也可以理解为体验的步骤 )， 并由管理后台决策规则 的确定和规则的下发， 这样， 不论用户通过什么体验平台进行业务体验， 这些体验平台都能 够根据管理后台发送的体验规则向用户提供相应的体验内容， 从而避免大量数据在网络中 传输， 并且， 由于体验策略由管理后台确定， 因此， 使得用户的体验能够得到管理后台的控 制， 有助于提高体验的智能度， 避免重复体验的问题出现。
根据本发明的实施例， 提供了一种业务体验的实现方法。
在实现该方法前， 管理后台需要进行体验规则的发布， 在体验规则发布成功后， 每 个体验平台均保存体验规则与相应标识的对应关系， 且管理后台需要继续发布体验策略， 每个体验策略同样具有相应的标识， 并且， 每个体验策略中包含有序排列的至少一个体验 规则， 在体验策略发布后， 体验平台就能够保存每个体验策略与相应策略标识的对应关系。 如图 3 所示， 根据本发明实施例的业务体验的实现方法包括 ：
步骤 S301， 在用户通过第一体验平台体验业务的情况下， 管理后台确定需要对用 户采用的体验策略， 其中， 体验策略由至少一个体验规则有序地构成， 体验规则是推送体验 内容的规则 ；
步骤 S303， 管理后台将体验策略的标识以及体验策略中需要首先执行的体验规则 的标识通知给第一体验平台， 以便第一体验平台根据体验策略的标识和需要首先执行的体 验规则的标识对用户推送体验内容 ( 即， 体验平台会顺序执行体验策略中的体验规则， 依 次推送相应的体验内容 )。
借助于上述处理， 通过将业务体验过程所对应的体验策略划分为多个体验规则， 并由管理后台进行体验策略的确定并将体验策略中的一系列体验规则通知给用户进行体 验时所使用的体验平台， 这样， 不论用户通过什么体验平台进行业务体验， 这些体验平台都 能够根据管理后台指示的体验规则向用户提供相应的体验内容， 由于网络中传输的仅仅是 体验规则的标识， 因此能够避免大量数据在网络中传输， 并且， 由于传输的体验规则的标识 是所有体验平台均能够识别的， 因此， 不同体验平台能够很容易地进行数据共享， 并且有助 于实现体验平台之间的联动， 还有助于体验平台将体验的实际状况通过体验规则上报来通 知给管理后台， 并且， 由于体验策略由管理后台确定， 因此， 使得用户的体验能够得到管理 后台的控制， 有助于提高体验的智能度， 避免重复体验的问题出现。
其中， 对于上述的体验规则， 可以根据以下方式进行划分 ： 根据用户体验业务的不 同阶段， 将每个阶段划分为一个 ( 不可分割的 ) 体验规则， 例如， 对于手机电子报业务， 可以 划分为以下五个顺序排列的体验规则 ： (1) 向用户展示该业务的相关介绍 ； (2) 向用户发送 免费电子报 ； (3) 询问用户是否已经正常看到订购的电子报 ； (4) 在用户无法正常看到电子 报的情况下远程配置用户的终端， 使终端的配置符合浏览电子报的要求 ； (5) 询问用户是
否需要开通业务。
例如， 假设管理后台将这五个体验规则发送给体验大厅管理服务器， 体验大厅管 理服务器首先会向用户发送业务介绍信息， 之后会向用户发送免费的手机报， 然后向用户 发送是否正常浏览手机报的信息， 然后， 可以将对终端进行配置的方式展示发送给用户、 或 者直接发送一段代码给用户由代码直接完成终端的配置 ； 最后， 还可以向用户发送是否订 购该业务的询问信息。
也就是说， 本发明实施例的管理后台是一个跨体验平台的管理系统， 与各个渠道 的体验平台连接， 由于在本申请的实施例中将体验策略划分为多个体验规则， 因此， 管理后 台就能够体验过程中的各个阶段均进行合理的控制和决策， 并且发送各个体验平台均能够 识别的体验规则。
另外， 在相关技术中， 体验门户网站和体验厅服务器各自所掌握的资源并不相同， 在用户进行体验时向用户展示的体验内容也存在差别， 因此， 即使体验门户网站与体验厅 管理服务器能够互相传递体验内容， 也不能够识别对方发送过来的体验内容， 但是， 这些体 验平台是能够根据管理后台发送的体验规则的， 因此， 也就能够将各自需要发送的体验内 容发送给用户终端， 实现业务的体验。 并且， 在体验的过程中， 本发明的处理还可以包括以下步骤 ：
步骤 1， 在用户未体验完体验策略中所有体验规则对应的体验内容时就退出体验 的情况下， 第一体验平台能够将用户当前已经完成体验的体验规则的标识和体验策略的标 识通知给管理后台 ； 步骤 2， 在用户通过第二体验平台继续进行体验时， 管理后台根据体验 策略以及用户当前已经体验完成的体验规则确定用户继续进行体验时的体验规则 ； 步骤 3， 将确定的体验规则和体验策略的标识通知给第二体验平台， 以便第二体验平台根据确定 的体验规则和体验策略对用户推送相应的体验内容， 其中， 第一体验平台与第二体验平台 相同或不同。
以上述场景为例， 假设用户已经在体验厅体验了第一个体验规则， 但是中途退出 体验， 此时体验厅会将用户已经体验完的第一个体验规则 ( 即， 用户已经浏览过业务介绍 ) 通知给管理后台， 而当用户在门户网站登陆继续进行体验时， 管理后台会根据体验策略和 已经体验完的第一个体验规则确定， 用户应当从第二个体验规则继续体验， 进而将第二个 体验规则的标识通知给体验门户网站， 根据第二个体验规则， 体验门户网站会向用户发送 免费手机报。
也就是说， 不论用户在什么体验平台登录进行业务的体验， 或者在什么时候中途 退出体验， 由于管理后台能够存储用户当前的体验状态 ( 即， 当前体验完成的体验规则 )， 就能够在用户后续登录准备继续完成体验时将这一状态通过体验规则通知给体验平台， 从 而实现继续体验， 避免执行重复的体验步骤。
另外， 在管理后台确定需要对用户采用的体验策略时， 可以根据用户的业务操作 历史记录确定体验策略， 其中， 业务操作历史记录用于表示用户进行业务体验和业务订购 的情况， 该操作历史记录可以包括用户已经体验的业务的标识、 用户已经体验的业务的类 型、 用户已经订购的业务的标识、 以及用户已经订购的业务的类型中的一个或其组合， 还可 以进一步包括用户进行订购、 体验和使用的时间， 具体地， 基于用户进行业务订购 / 体验的 历史记录， 管理后台可以确定用户的业务订购关系和使用活跃程度， 进而能够选择适当的
体验策略 ( 体验规则的组合 ) 并自动分发， 即， 管理后台并不控制各个渠道的体验平台向用 户展现什么体验内容， 只是决定控制规则所组成的体验策略， 在后台系统的规则控制下， 每 个体验平台再利用其上可用资源根据体验规则展示体验内容 ( 即， 由每个体验平台来适配 对应来自管理后台体的验规则的体验内容 )， 不同的体验平台进行业务展示的方式不一定 相同。
可选地， 管理后台可以设置活跃度的多个数值范围， 每个数值范围设置一个对应 的体验策略， 根据用户的业务操作历史记录， 管理后台可以得到用户的业务订购关系和活 跃度， 并将用户的活跃度进行量化， 根据量化后的活跃度所在的数值范围和业务订购关系 确定相应的体验策略。
另外， 管理后台能够自行或借助其他方式对用户订购或体验的业务以及体验和订 购的时间进行统计， 确定用户的偏好， 从而进行个性化的体验推荐， 有效提高用户体验的智 能度。
并且， 在管理后台确定用户重新登录时继续进行体验时的体验规则时， 可以根据 业务操作历史记录对体验策略进行调整， 并根据用户已经体验完成的体验规则和调整后的 体验策略确定用户继续进行体验时的体验规则。
例如， 以上述列举的五个体验规则的场景为例， 假设用户完成了第二个体验规则 的体验 ( 即， 用户已经收到了免费发送的手机报 )， 之后退出体验， 当用户后续登录后， 管理 后台会首先判断用户是否完成体验， 并应当确定用户对手机报业务的订购状况， 如果发现 用户已经订购了之前体验的手机报业务， 则管理后台就不应当继续发送询问用户是否订阅 该业务的体验规则， 从而进一步提高体验的智能度。
具体地， 在用户通过第二体验平台继续进行体验时， 可以首先判断用户是否有未 完成的体验策略 ( 即， 判断是否有体验规则被吊起 )， 如果判断为是， 则根据用户当前的业 务操作历史记录确定需要对用户采用的新的体验策略， 并判断新的体验策略是否具有与用 户根据原体验策略进行体验且中途退出时所产生的断点， 如果判断结果为是， 则执行上步 骤 2 和步骤 3 ； 如果判断结构为否， 则表示用户在继续进行体验之前， 已经进行了有关该业 务的操作， 导致原先的体验策略不适用， 此时， 管理后台会根据用户已经体验完成的体验规 则和新的体验策略确定用户继续进行体验时的体验规则， 并将该体验规则的标识和新的体 验策略的标识通知给第二体验平台， 由第二体验平台继续依次执行体验规则， 而不是根据 原先的体验规则进行继续体验。
根据本发明的另一实施例， 提供了一种业务体验的实现系统。
如图 4 所示， 根据本发明实施例的系统包括管理后台 41 和至少一个体验平台， 为 了表述清楚， 以第一体验平台 42 和第二体验平台 43 进行说明。
其中， 管理后台 41 用于在用户通过第一体验平台 42 体验业务的情况下， 确定需要 对用户采用的体验策略， 并将体验策略的标识以及体验策略中需要首先执行的体验规则的 标识通知给第一体验平台 42， 其中， 体验策略由至少一个体验规则有序地构成， 体验规则是 推送体验内容的规则 ；
第一体验平台 42 用于根据来自管理后台 41 的体验策略的标识和需要首先执行的 体验规则的标识对用户推送体验内容。
并且， 第一体验平台 42 还用于在用户未体验完体验策略中所有体验规则对应的体验内容时就退出体验的情况下， 将用户当前已经完成体验的体验规则的标识和体验策略 的标识通知给管理后台 41 ； 而管理后台 41 还用于在用户通过第二体验平台 43 继续进行体 验的情况下， 根据体验策略以及用户当前已经体验完成的体验规则确定用户继续进行体验 时的体验规则， 并将确定的体验规则的标识和体验策略的标识通知给第二体验平台 43 ； 第 二体验平台 43 用于在用户通过第二体验平台 43 继续进行体验时， 根据管理后台 41 确定的 体验规则的标识和体验策略的标识对用户推送相应的体验内容。
为了进一步提高业务体验的智能度， 上述系统还可以进一步包括 ：
客户关系服务器 ( 图 4 中未示出 )， 与管理后台连接， 用于保存用户的业务操作历 史记录， 其中， 业务操作历史记录用于表示用户进行业务体验和业务订购的情况 ； 基于此， 用户管理后台还可以用于根据业务操作历史记录对体验策略进行调整， 并根据用户已经体 验完成的体验规则和调整后的体验策略确定用户继续进行体验时的体验规则 ； 具体地， 在 用户重新登录进行体验时， 管理后台此时可以根据用户当前的订购关系和活跃程度选择适 配的体验策略， 如果这时客户适配的体验策略已经和保存的断点不一致 ( 即， 用户进行了 新的业务订购和体验等操作， 导致原本为该用户确定的体验策略目前已经不适用于该用 户 )， 则需要根据新确定体验策略完成用户的体验。 之前已经提到， 为了提高业务体验的智能度， 管理后台可以借助其他网元的协助， 例如， 可以将与数据分析系统、 业务平台等进行连接， 这样， 管理后台就能够从数据分析系 统获取用户订购和体验业务的统计结果， 通过业务平台能够获知业务的诸多详细介绍和业 务功能的更新等信息。
另外， 在实际应用中， 管理后台可以同步记录多个渠道的每个客户的体验信息， 并 且通过实时的数据交互过程， 实现客户在多个渠道的体验连续性。
应当注意， 之前以第一和第二体验平台进行描述仅仅是出于清楚的目的， 实际应 用中， 体验平台的数量可以为两个以上， 并且每个体验平台都可以具有将用户体验时中途 退出时体验策略的断点通知给管理后台、 以及根据后台通知的体验策略和需要执行的体验 规则标识为重新登录的用户实现继续体验的功能。
图 5 是根据本发明实例的业务体验的实现系统的具体结构实例的框图。
如图 5 所示， 管理后台与数据分析系统、 客户关系服务器、 业务平台、 以及体验平 台连接， 其中， 管理后台可以包括体验管理服务器、 体验数据服务器和体验接口服务器， 具 体地， 体验平台可以包括体验厅管理服务器和门户网站接口服务器。
与管理后台连接的数据分析系统能够根据管理后台统计的一个或多个用户进行 业务体验等业务操作的历史记录或进一步结合业务平台的用户数据进行总结和统计， 得到 统计结果。根据数据分析系统提供的数据， 管理后台能够更有针对性地决策应当如何进行 业务体验的推荐。客户关系服务器中保存了用户进行业务体验、 业务订购等业务操作的历 史记录， 根据客户关系服务器中保存的历史记录， 不仅能够实现用户中途退出体验后、 在重 新登录时在之前从退出而没有完成的体验规则继续完成体验， 而且管理后台还能够根据客 户关系服务器中的历史记录对用户的体验策略进行动态调整， 进一步提高系统的智能度 ； 业务平台是开展业务的网元， 其中会不断更新得到新的业务以及升级后的业务， 管理后台 可以根据业务的更新状况得到新的业务介绍， 并通过修改业务体验规则。 这样， 不仅能够实 现不同类型的体验平台上进行的业务体验得到集中管理和决策， 并且能够为体验厅终端用
户和门户网站用户提供更加智能和个性化的体验。
在本发明中的该系统中， 可以将不同的体验规则按照业务介绍、 使用方法、 高手秘 笈、 趣味体验、 业务试用、 客户端下载、 业务订购等分类， 进行归属和编号， 每个体验规则作 为一个不可分割的原子操作对待， 并分别建立各自分属的类别码和编号。 其中， 体验规则可 以是用于根据业务名称、 客户订购关系、 客户的活跃度三个纬度表示如何推送体验内容的 规则， 例如， 对于彩铃业务， 加入一个用户与该业务存在订购关系， 但是该用户的活跃度较 低， 此时， 在需要对该用户进行彩铃业务体验时， 可以推送一首特定的免费彩铃下载， 此时， 向用户提供免费彩铃下载就构成了一个体验规则， 而提供下载时当如何展示界面、 如何和 用户完成互动以便让用户选择期望下载的音乐， 是某个特定体验平台根据体验规则进行适 配得到的体验内容， 并且该铃声可以属于业务试用类别并具备相应的编号。在用户进行业 务体验时， 体验平台可以根据从 CRM 系统获得的客户业务订购关系， 从分析系统获得的客 户活跃状态 ( 每个活跃状态有自己的不同定义， 例如， 如果用户在一个月内变更过彩铃歌 曲或者同时订购了音乐盒业务， 则可以认为该用户在彩铃业务方面的活跃度较高 ) 以及提 前分发的体验规则， 这样就能够为客户自动生成一个体验内容， 每个体验内容都有一个相 应的体验规则， 根据体验策略的优先级顺序， 根据生成的不同的体验内容， 进行个性化的业 务体验。 从而有效避免了体验内容每次都从统一后台分发， 导致数据传输量大， 而且难以进 行断点保存的问题。 在上述系统中， 每个体验规则对应的体验内容或者步骤是在后台进行开发， 并统 一分发到各个体验平台 ( 分发的方式可以是 FTP 或其他方式， 本文不再一一列举 )， 由这些 体验平台根据体验规则通过具体界面和方式将体验内容展示给用户。
本发明实施例中， 体验管理后台与数据分析平台、 客户关系服务器、 以及业务平台 连接， 在工作中， 管理后台与这些平台实时进行数据交换， 处理对应的数据业务。为了保障 客户在不同渠道的体验的一致性， 在管理后台配置统一的体验策略， 然后发布到每个体验 平台的管理控制服务器， 各个平台的管理控制服务器负责体验规则的执行。如图 6 所示， 具 体的实现过程如下 ：
步骤 601， 管理后台配置体验规则， 图 5 中管理后台的体验管理服务器得到配置的 体验规则 ；
步骤 602， 体验管理服务器对配置的体验规则进行冲突检测 ；
步骤 603， 体验管理服务器将体验规则发布到各个体验平台的独立服务器 ( 例如， 体验厅管理服务器和门户网站接口服务器 ) ；
步骤 604， 体验平台各自的服务器保存并加载体验规则。具体地， 每个体验平台的 接口服务器在接收每个体验规则后可以将该体验规则加载到体验逻辑引擎中， 以便后续执 行。
图 7 是根据本发明实施例的业务体验的详细处理过程的信令流程图。 如图 7 所示， 身份鉴别的过程如下 ：
步骤 701， 体验终端发送推送请求给体验平台 ；
步骤 702， 体验平台将查询用户状态请求发送给管理后台 ；
步骤 703， 管理后台向客户关系服务器发送用户身份鉴别请求 ；
步骤 704， 如果身份鉴别结果为用户合法， 则管理后台在数据分析系统或其本地查
询该用户的行为信息 ；
步骤 705， 管理后台查询该用户目前未完成体验的中断点状态信息 ( 即， 查询该用 户是否有未完成的体验 ) 和历史体验信息 ；
步骤 706， 管理后台向体验平台返回体验策略中未完成 ( 吊起 ) 的体验规则标识 ( 编号 )， 之后， 管理后台可以更新用户的体验状态信息， 更新为用户户又继续开始体验 ；
步骤 707， 体验平台生成体验内容 ；
步骤 708， 体验平台生成体验界面 ；
步骤 709， 体验平台将体验界面推送给体验终端。
如果此后用户请求开始某个具体的业务体验过程， 体验平台需要将体验请求发送 给管理后台 ； 管理后台需要根据用户的信息查找适配的规则编号， 并返回给体验平台， 并更 新体验状态信息 ； 之后， 体验平台针对本次管理平台发布的体验规则生成体验内容和界面， 并推送界面给体验终端。
在图 7 所示的处理过程中， 客户身份鉴别是用来鉴别该客户是否是合法的体验用 户、 以及确定该用户目前的存在的业务订购关系， 同时从分析系统查询客户存在订购关系 的业务的行为信息， 并将该信息转换为活跃状态， 从而确定客户适配的体验规则， 并将相应 适配的规则编号发送给体验平台， 由体验平台根据这些体验规则生成体验内容。 另外， 如果 发现该用户有吊起的体验规则， 则先发送掉起的体验规则， 完成未完成的体验。另外， 通过 查询客户体验状态信息， 可以查询客户目前正在哪个渠道服务器管理下进行体验， 如果在 查询客户已经在某个体验环境下进行体验的过程中， 则发送错误信息， 防止同一用户同时 重复体验和订购业务。 具体地， 在用户同时通过两个或更多不同的体验平台实现同一体验策略对应的体 验过程而导致体验出现异常时， 可以执行图 8 所示的处理， 具体过程如下 ：
步骤 801， 体验终端发送推送请求给体验平台 ；
步骤 802， 体验平台将查询用户状态请求发送给管理后台 ；
步骤 803， 管理后台向客户关系服务器发送用户身份鉴别请求 ；
步骤 804， 如果身份鉴别结果为用户合法， 则管理后台查询该用户生效的体验规 则；
步骤 805， 管理后台查询该用户的状态信息和行为信息 ；
步骤 806， 管理后台查询到该用户同时通过两个或更多不同的体验平台实现同一 体验策略对应的体验过程， 则向体验平台返回重复信息 ( 表示用户体验过程出现异常 ) ；
步骤 807， 体验平台生成提示界面 ；
步骤 808， 体验平台将提示界面推送给体验终端。
图 9 是体验平台检测到用户中途退出体验的情况下收集用户当前体验的状态信 息的处理信令流程图。如图 9 所示， 具体的处理过程如下 ：
步骤 901， 体验平台检测用户的操作 ；
步骤 902， 体验平台检测体验的执行过程中用户是否退出体验， 在本实施例中， 当 用户在两分钟 ( 或其他时间段 ) 内没有进行任何操作， 或者用户在体验界面点击离开按钮， 则判断用户已经中途退出体验， 此时需要向管理后台传输数据 ； 应当注意， 这里判断用户是 否中途退出的方式仅仅是一个具体的实例， 并不用于限定本发明 ；
步骤 903， 在确定用户中途退出的情况下， 体验平台就收集客户当前体验信息， 具 体地， 可以提取用户当前的体验规则编号以及用来生成体验内容的编号序列表 ；
步骤 904， 体验平台向管理后台发送信息同步请求 ；
步骤 905， 管理后台返回同意启动信息同步的指示 ；
步骤 906， 体验平台将记录的该用户的体验信息发送给管理后台 ；
接着， 管理后台保存体验平台发送的体验信息 ； 之后， 管理后台可以与分析系统 完成该用户的体验历史信息和状态信息的同步， 变更该用户的体验状态为未完成体验的状 态；
如果步骤 902 中体验平台判断用户没有退出体验， 则根据从管理后台接收的体验 规则继续生成体验界面并向体验终端推送体验界面。
图 10 是用户中途退出体验后重新登录进行继续体验的处理流程图。
如图 10 所示， 具体过程如下 ：
步骤 1001， 体验平台检测用户的操作 ；
步骤 1002， 如用户请求体验， 则体验平台将用户的请求推送给管理后台 ；
步骤 1003， 管理后台判断该用户是否有未下线的悬挂的体验规则 ( 即， 判断该用 户是否完成了之前的体验过程 ) ； 如果判断为是， 则执行步骤 1004 和步骤 1005 ；
步骤 1004， 管理后台将体验信息发送给体验平台， 其中包含用户需要继续体验的 体验规则 ；
步骤 1005， 根据管理后台的体验状态信息， 体验平台找到具体的体验规则序列并 生成体验界面， 之后将体验界面推送给终端， 从而使用户完成之前未完成的体验 ；
如果步骤 1003 的判断结构为否， 则管理后台查询用户的业务订购关系， 之后执行 步骤 1007 ；
步骤 1007， 管理后台向分析系统查询用户的业务使用记录 ；
步骤 1008， 分析系统向管理后台返回用户的业务使用信息 ；
步骤 1009， 管理后台将用户的业务使用信息转换为活跃度信息并临时保存 ；
如果用户开始体验新的业务， 体验平台会将用户希望体验的业务编码通知给管理 后台 ； 管理后台会生成适配的体验规则编码序列 ( 体验策略 )， 并发送给体验平台 ； 体验平 台会生成相应的体验内容， 并生成新的体验界面， 之后将该界面发送给体验终端。
借助于本发明的上述技术方案， 通过一个通用的体验管理后台将业务体验过程所 对应的体验逻辑 ( 体验策略 ) 划分为多个体验规则， 体验规则由管理后台统一生成并分发 到各个不同的体验前端系统 ( 体验前端系统就是用户进行业务体验时所借助的体验平台， 其可以是定制化的体验机也可以是体验门户网站等 )， 这样， 前端体验系统就能够根据体验 规则生成适当的体验内容展现给客户。体验策略有一系列这样的体验规则组成， 并由管理 后台根据使用客户的在运营商业务系统的使用记录来生成不同的体验策略， 由管理后台将 体验策略通知给用户进行体验时所使用的体验平台， 这样， 不论用户通过什么体验平台进 行业务体验， 这些体验平台都能够根据管理后台指示的体验规则向用户提供相应的体验内 容， 由于网络中传输的仅仅是体验规则的标识， 因此能够避免大量数据在网络中传输， 同时 有助于体验平台将规则上报给管理后台， 并且， 由于体验策略由管理后台确定， 因此， 使得 用户的体验能够得到管理后台的控制， 有助于提高体验的智能度， 避免重复体验的问题出现。 以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡在本发明的精 神和原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。