|
第五章 技术的设计（二）
李宝民 2005/03/17
5.2 企业顾客关系管理解决方案
5.3 服务请求
。。多渠道的客户关系管理措施将要求用于传送公司需要的功能。基本上，通过"双重渠道"将较容易进行目标系统服务，也可用于电话和互联网客户。
但是，有一部分服务是向来不适合电话渠道的。如今大多数服务可以通过邮件或人工进行，因为客户要求获得比电话中更多的信息。除传统的公司渠道外，这些服务将利用互联网渠道进行，。
| 部门 |
服务内容 |
渠道
|
需要的支持办公 |
| 所有 |
公司范围直接 |
呼叫中心 |
互联网 |
| 服务 |
服务查询 |
√ |
√ |
√ |
| 清单 |
查核清单水平 |
√ |
√ |
√ |
| 投诉 |
对服务和/或产品的投诉 |
√ |
√ |
√ |
| 市场 |
市场运作事务要求 |
√ |
√ |
√ |
| 销售 |
推销产品和/或服务 |
√ |
√ |
√ |
| 维护 |
报告事故和故障 |
√ |
√ |
√ |
。。下面的图表说明了目标系统如何使委托客户服务请求和申请的。另外，目标系统从各部门调配公司员工履行/解答服务请求，传达请求的解决办法。
Figure: System Request System Concept
。。为了提供请求的服务，目标系统要以企业CRM方案为基础，该方案是为委托客户和客户服务专业人员制定的，可以帮助他们轻松地提交、获取、处理和跟踪服务情况，并且快速准确地解决问题。
具体说明，运行呼叫中心系统的CRM方案必须：
- 对公司现有产品和服务水平表示不满
- 标准基础上--允许应用程序改进（不需要改变"编码"），适应公司不断变化的需求和运行策略
- 可延伸--支持公司提供的发展中的服务"清单"
- 可提高--使公司能够支持随时间不断增加的使用目标系统的委托客户数量。
更详细地说，运行目标系统的企业CRM方案应含有下列内容：
- 应用和登记办法：能够收集并处理（综合后备办公办法支持）登记和应用信息，以便公司服务、许可、执照和事件的处理。
- 服务请求办法：能够收集客户服务请求，以便通过电话和互联网渠道提供服务。
- 百科全书：提供信息知识库，其中包含公司服务、联络信息、按时间排列的事件和活动表、方针和步骤，以及其他可以使用的客户服务信息。
- 联络中心统计：能够收集和分析关于实际时间服务代表生产力的广泛的统计数据，包括回应和处理时间、呼叫完成比率、放弃呼叫比率、平均呼叫长度，以及忙音百分比。服务代表生产力数字可使经理跟踪服务代表的目标完成及生产情况。
? 呼叫电子邮件：能够将客户的电子邮件发送给适合的服务代表，使客户和终端用户通过互联网取得服务请求许可，访问信息库。
- 联络分配：按规则进行工作量分配，保证将知识最丰富、最有用、最适合的客户服务自动分配给进行服务请求或客户联络的人。
- 联络史：记录客户相互作用，包括呼叫发送、服务请求状况、服务代表联络信息，以及互联网活动。呼叫和互联网的递交历史有助于分析呼叫种类和服务质量。
- 操作任务：能够形成、分配、发送、分类和操作处理从客户联络渠道取得的服务请求。
- 外部知识库链接：提供链接，使组织或产品信息能够形成、储存和管理，从而有助于处理客户服务请求和询问。 ? 工作流：自动发送文件和工作条目给在个别服务发送过程中负责执行具体步骤的人员。工作流能力能够分析和智能化执行公司业务步骤。
- Quick Star-up Out of Box：提供一个健全的整体的解决办法，能够满足关于客户呼叫/互联网联络中心的基本功能要求。Out-of-box
办法减少了运行成本和时间，并且比客户办法有更少的内在风险。
- 屏幕定制：可使用户将屏幕用户化，反映其偏好或具体的业务要求。用户选择想要的个人屏幕种类--如服务请求、协议和服务信息--此外使用过滤器--如"显示所有服务请求"，"只打开服务请求"，和"只打开过去7天提交的服务请求"。
- 环球网连接：允许公司服务代表通过公共网络设施如互联网支持公司内外的联系和事务。能够通过互联网联系、知识库和客户资助服务建立和维持委托客户关系。
- 报告：允许服务代表和经理利用多种有用的预备或特别报告汇报、分析和散发客户服务相关信息。利用第三方报告工具和办公自动操作技术制定报告。
- 跟踪重复发生的问题：使服务代表能够持续、快速、准确地回复各种委托客户的询问和服务请求。运用解决方案，逐步加强记录并跟踪客户呼叫联系和互联网联系。
- 架构：能够按照行业标准、开放式服务平台、网络协议和数据库平台，以及客户平台运行。
5.5 后台办公集成中间件
。。呼叫中心系统将与许多公司遗留数据和新型后台办公方案相结合。该系统的客户接待和处理部分也将结合企业支付系统，支持提供可支付服务。结合后台办公系统的工作将利用中间件技术进行。
。。中间件在运行系统和网络服务间形成了分布式应用程序组件的连通性。这些服务一般利用应用程序接口（API）使用，并通过某组服务执行，这组服务能够使应用程序组件：
- 内部运行而不需考虑潜在的计算机架构。可以通过把应用程序组件从运行环境和相关架构中分离出来进行这一工作。分离利用一个抽象接口和可从原运行环境分离出应用程序组件的中间件API进行。
- 内部运行而不需考虑网络架构。这一功能通常称为"联系桥梁"或"传送桥梁"，它促进了运行环境间运用各种网络协议进行联系。当应用程序组件要在各网络诸如TCP/IP.SNA，IPX/SPX和X.25之间分配时，这种功能是很有必要的。
- 共享数据和使用参数而不需考虑运行程序和网络。此功能通过"数据翻译"和"参数调度"服务进行。数据翻译服务保证了以本机格式为分配的应用程序组件提供数据。例如，可能需要将数据从EBCDIC翻译成ASCII，在不同字节次序间转换，或者在不同数据表示类型间转换。参数调度为网络传输预备了数据架构并由分配的应用程序组件使用。例如，当使用指示器时，参数调度服务负责识别参考数据，复制数据及准备网络传输，传输后不压缩数据，根据对分配的应用程序组件的价值进行发送。
。。大多数商用中间件系统建立在远程呼叫或信息发送和信息排队技术的基础上。服务方面，两者本质上提供同种功能：它们都促进了分布式应用程序组件的进程间通信。
。。不过在技术上二者有很大区别。例如，远程过程调用（RPC）中间件以过程调用类似概念为基础，本质上会发生同步化和堵塞。
因此，RPC基础的中间件要求：
- 客户程序和服务器在服务请求期间同时可用
- 客户等候服务器应答后再进行其他工作
。。显然，这种程序模式已不适用了。举例来说，即使不是服务请求时间，公司也可能要收集、储存、给后台办公系统传达服务请求信息。如果技术同步化，使用RPC是不能进行这些工作的。同样地，服务请求系统也可能需要同时查询各个后台办公系统。使用RPC系统也不可能进行工作，因为技术堵塞，需要客户等候递交请求的回复，然后再递交别的请求。下面的图表说明了这一过程。
。。RPC技术的一个替换方案是信息发送中间件。信息发送和信息排队技术利用信息传送和排队技术支持应用程序进程间通信。信息传送模式可使客户通过发送信息给服务器呼叫API并发送服务请求。许多运行过程中，信息发送模式通过排队和保证发送措施得到提高，可以非常灵活并不同步地储存，进行联络。这种不同步模式加上综合传送桥梁服务系统，可以完美地运用广域网络技术发送信息--在此范围内不能同步使用分配的资源。下面的图表描述了信息排队模型。
。。举例来说，一些公司的呼叫中心系统运用两种信息发送产品结合了所需的后台办公方案。它们是IBM公司的MQ系列以及Mitem
有限公司的MitemView 。更具体地说，MitemView 用于紧密地将呼叫中心系统"结合"后台办公方案包括IBM3270，或类似的终端设备。该方案不要求以任何方式修改现有后台办公方案，也不要求在系统上安装其他软件。也就是说，MitemView运用提供终端图像服务的数据流建立要求的应用程序界面，这在下图中有所说明。
。。当后台办公方案不能提供3270或类似界面时，就要使用IBM公司的MQ系列。作为呼叫中心系统的一部分，通过持续排队和保证发送服务，MQ系列可以不同时不堵塞地发送信息。这些服务可以保证正常阅读排队中的客户请求，并在业务委托和确认之前都能进行--即使排队运行环境不稳定或在程序中发生错误的情况下也能工作。
。。在决定中间件研究怎样结合特别的后台办公方案之前，需要进一步分析公司的历史数据和后台办公方案。
本文由作者向CTI论坛提供
回到 李博士专栏——呼叫中心构建规划指南
·
·
·
|
