主题论坛-呼叫中心技术发展及应用实录(3)

　　为推动客户关怀及管理(Customer Care & Management)理论和实践在中国的发展，促成新思想的深度撞击，客户世界机构(CCMworld Group)发起并联合客户中心技术领域的世界级顶级供应商Avaya公司于3月15日在北京举办了“呼叫中心技术发展及应用专题研讨会”。就“语音门户”和“主动服务”两大前沿技术应用分别设立专场进行研讨。

　　下文是Avaya语言识别及IVR应用顾问Ted Bray介绍如何利用语音自助产品解决方案和开发设计软件来实现语音门户服务。

　　非常感谢Michael Perry！稍微讲一下我自己的背景，我目前在Avaya工作，是负责语音应用的咨询顾问服务。特别是有关Avaya还有IVR数字语音识别技术方面的工作。在此之前我做过Michael Perry的工作，包括语音产品的管理和服务。在此之前我从98年到04年是在Edify帮他们做自助服务产品的管理。我离开的原因是像Michael Perry前面讲的一样，Avaya今天做的工作是关于语音服务的架构，这些架构涉及到我们整合的IP技术的设施发展，这是令人非常兴奋和非常振奋的。随着把网络融合的时候，开始把传统的数据环境跟传统的电话环境结合起来，把这两个结合在一个非常丰富的网络里面，可以提供非常智能的客户保护，对于我来说是非常兴奋和高兴的。我想加入能够帮助企业和客户更好的联系，能够给他们带来一些价值。

　　在加入Avaya之前，我有很多年在Edify和AT&T工作，在我职业生涯的时候我行业的发展我感到是非常兴奋的，因为有一个时间是非常孤立的电话网络，我们有一些巨大的机会来降低我们的支出，提高客户服务的满意度。

　　Michael Perry前面讲了关于面向服务的架构是什么。你们有一些人比较熟悉，有一些人不熟悉，它是这样的，任何一个根据网络连接的东西，都可以是一种服务。它可以是一种服务而且连接到其他的网络上，可以被任何一些东西跟网络连接起来加以使用，并不只是一种看作服务来提供信息。它也可以使用其他的网络连接的一些服务，就那么简单。这是一个叫做面向服务的SOA体系架构。

　　我们可以设想一下整个IT的网络，可以想一下如果所有的事情跟网络连接，都可以服务网络其他的部分，能够享受网络提供其他服务的话，这是一个那么深远、庞大的构成。去年我们做过一个调查，我们发现我们的客户平均使用率，一个服务器的使用率不到20%，意味着在一个机构内部资本的投入，投入到一个服务器的架构上只能享用20%的使用率投资资产。

　　我们看一下面向服务体系架构的前景，关键是推动对资产的利用率，能够降低客户的成本和业务成本等。面向服务的体系架构从现有的我们叫Web服务演进而来的，它是一个非常简单的概念。在我们互联网的世界是很容易来访问互联网的资源，只要有一个通用的地址就可以了，在互联网变成了基于标准的情况。还有一些其他的关键因素，这个是我们地址的部分。

　　另外一个关键的就是复用性，表明可以有一种模块化的方案，这样的话有一个共同的任务，这个任务主要是识别客户。而不是说把这个任务放在多个不同的应用服务里面去而是重复应用，如果把这个任务割裂开来让它重复使用。包括电话的应用也可以针对一些有业务代表的复用，这是非常深远的，它已经变成了一种现实，因为我们有面向服务的架构。这种架构已经提供了标准的可编程接口，这是非常重要的一点。把这些接口标准化我们能够推动模块化，能够可复用型面向服务的体系架构。

　　这是一个比较好的研究，是一年前做的，差不多超过一半的全球企业完成了服务架构的项目，另外30%正在评估SOA，我可以保证这些数字已经比当时统计的数据还要更高，但是我们没有另外的研究数字，这是一个比较老的数字。

　　面向服务的架构涉及到我们语音的自助服务也是非常重要的，SOA所驱动的自助服务，我们没有看到，今天我们面向服务的架构正在语言服务、自助服务实施当中。我们发现了什么呢？跟传统的IVR不一样的是，在传统的IVR里面所有的东西都放在我们IVR的设备里面，我们有电话、数据的访问、数据的逻辑，把所有的东西都集中在IVR里面。但是非常有意思，在网络连接的其他部分，还是同样的东西，同样重复数据的访问和业务逻辑、业务规则，所以IVR的技术是比较老的。

　　我们这里面有很多资本的投入和重复性，在IVR系统里面。我们面向服务的架构是一种模块化的自助服务架构，我们可以看到能够消除重复性的东西，就是传统的IVR里面的。取而代之在SOA里面可以充分利用以前的投资，在IVR的架构上，可以消除一些重复的投资在整个环境上。可以能够让我们的IVR变成一种服务的消费者，它是一个服务的提供者，也就是为IVR投资是一个得到更加有效的利用，被网络上其他的部件来使用。它的结果也是非常直截了当的，我们可以想象作为一个消费者怎么样跟公司发生互动关系，最后是自动化的服务，他会问客户名称或者是收入你可以告诉他，花几分钟你意识到我还是跟一个真人来沟通一下，跟一个业务代表。在意识到这一点之后，你希望看到一个什么呢？他又跟你说，你好把你的名字再告诉一下，这并不是很好的体验。

　　我们的企业应用并不只是一种应用自助服务，它是具有吸引力的智能性的逻辑性的，我们的客户会对服务形成一种忠实性，让我们的客户非常羡慕。如果是非常差的服务，这种应用如果不能集成的话，这些客户会远离你们。面向服务体系的架构可以提高我们的工作效率，而且我们看一下语音识别技术，我们会更多的了解关于语音的技术。这样一种能力充分的利用我们已经做的投资，也包括我们对语音方面的投资在整个企业内部，已经变的越来越有能力去做，在这样一种面向服务的架构里面去实现。

　　IVR随着我们产品的发展，在外部的服务上我们给大家分享一下，我们来告诉我们全球的客户，他想知道我们的产品发展是怎么样的？他希望我们自助服务是开放的，而且是一种有智能性的，开放来说比如说IT的标准，XML的标准，我不肯定有多少人熟悉它或者不熟悉，你们都听说过XML这是肯定的。很简单的说是一个VoiceXML的变种，定义一下语音的应用、自助服务的表述，整个来说是把它加以标准化，怎么样编写和怎么样执行的服务，对我们的客户来说，我们的应用必须是有这样一个XML，必须建立在我们外部已有的体系架构之上，我们做一些报告我们知道怎么样梳理安全性和怎么样管理。我们的客户说已经不再希望有这样一个孤立和单一体的IVR，所有的都在这些之上。

　　我们的客户告诉我们，他们已经充分的利用在做的投资之上，就像访问数据，共同的流程在他的机构内部，因为在Web我们定义了怎么做这些事情，我们的Web环境已经做了这样的事情。我们的客户告诉我们的是什么呢？他们并不想在IVR必须重复数据的访问包括客户的验证，他们想利用他们已经做出的企业内部的投资，充分发挥他们的潜力。我们的客户告诉我们，他们享有可复用性和灵活性，他们想进入他们的Web系统一样。看到我们的组建的架构，他们也看到应用、平台、开发工具，他们看到这些东西能够按照同样一种原则、同样的一种潜在来发展，他们使用Web产品，用于他们网络的发展，他们并不想看一个单独的IVR的发展方式，又要求有一些独特机能来开发IVR的应用，他们意识到来发展IVR的应用有一些人对机的交流，并不是人对人的交流，他们希望看到一些专家在语言上有一些专业知识来开发IVR的发展。这样一些技能机可以把话音采用一些智能方式集成在一起。

　　我们的客户还告诉我们说提供一种支持。比如说一些许可、授权能够变的更加灵活，更加具有动态针对他们的应用。我们的客户也告诉我们，他们要求这样一些方案具有很高的可用性，还有一些关键使用的性能的一些要求比如说五个九的可靠性。他们希望消除备份系统和备份人员的必要性，为什么呢？因为竞争对手变的越来越好，变的越来越强大。每一个系统人员都是从系统里面拿出来的钱，他们如果不能够变的效率更高一些，他们会失败。我们的客户也告诉我们他们有更多应用成本的降低，我们的客户他们坚持拥有成本必须降下来以及总体应用成本的好处进一步最大化。他们希望看到最大的利用率，他们已经投资的设备不管是在互联网、Web，还是在软件上，他们想看到简化性和统一性在他们所部署的硬件上，他们并不想看到IVR系统运行在某些非标准的服务器上，他们希望看到一个单一的服务器的类型在整个企业内部。为什么呢？他们希望看到他们怎么去维护、怎么去扩展的优势，在这个系统上。

　　我来回答这样一些要求，IVR推出了Avaya语音门户，语音门户有四个程序组成。Avaya语音门户已经把传统的IVR架构打破，它里面有语音的连接、数据的访问、业务规则和业务的逻辑，还有一些媒体的流程解释应用，管理语音的访问、语音识别以及传统的IVR里面包含了所有的东西，在单一的服务器上。我们看到这一点，一个从最初的采购考虑，从一个维护的角度，从质量的保证角度、开发的角度、分布发展的角度来说，我们看到它要求有大量的投资，并不是在生产的基础上，还有支持的基础上、增长的战略上有大量的投资是非常昂贵的，还有很高的融合性和兼容性。所以从门户来说已经完全改变了这种状态，语音门户它并不会重复这些已经现有的东西，在这个环境里面。

　　语音门户它们并不是在一个单一的模块化里面做所有的事情，我们有外部基础的东西，它把媒体处理给它分别开来。比如说来处理这样一些语音、文本。从系统的监控和报告上分离出来，因为我们猜想一下，如果把它放在一起我们监控一个系统，如果这个系统出现问题的话，我们失去了所有的东西，所有的监控能力。我们把它变成基于外部的话，我们更加有智能性的话在一个分布性的环境里面实现这些要求。

　　Avaya的语音门户是非常紧密地跟其他一些联络中心里面的组件能够结合起来，也包括我们的Avaya的联络中心的组件，如果把语音门户放在Avaya联络中心里面，你会看到一些非常惊讶的结果，包括报告类型、功能、管理、可靠性等等。我们把Avaya的语音门户放在非Avaya环境里面，我们可以发现，我们模块化可以让我们是非常适合的，不管是什么样的环境。

　　我们向一种叫做融合的发展来说，是一个非常关键的步骤，对于自助服务成功的话，语音门户正成为中心，语音门户正是按照SOA这个体系架构建立起来的。还有一些门户是由一对多的服务器的组成，它们密切的结合在一起，客户来开发自己的基于Avaya基础架构的应用。

　　再突出一下关于语音门户的要点，W3C全球的标准化机构是负责互联网标准的，他们有一个论坛叫做互联网论坛，它是W3C是负责标准单一的标准，目前这个标准的版本是VoiceXML 2.0版本，是非常关键的，应该搞清楚保证我们所建立的应用，是一种标准化的。这些应用需要能够按照VoiceXML 2.0标准来做。非常关键在看自己潜在的选择的时候，要考虑到选择的平台是被互联网论坛所认证的。

　　Avaya在这个服务架构里面，我们可以看一下有Avaya的浏览器是得到认证的，它是一个一样的浏览器，在我们应用开发的工具里面，我们可以看一下。而且这个基于浏览器的语音门户应用设计工具同样适用于传统的IVR系统。这是什么意思呢？如果我们的客户是长期客户的话，有很多IVR端口，他们可以编写他们(XML)的应用和Avaya的应用。他们可以免费的迁移，准备好之后从语音互动式的应答系统迁移到语音门户。他们其中利用一些维护费用能够让他们免费的升级，升级到语音门户，如果他们准备好的话。

　　因为使用相同的语音浏览器，像Michael Perry前面讲到一些投资，这些巨大的投资可以继承下来，转移到我们的语音门户上。同样XML的浏览器和Linux服务器，我们能够提供同样的应用，这是一个非常好的例子，也是我们的客户要求的，我们必须有Web Service的版本，这是一个非常好的例子。除了VoiceXML之外，我们充分利用一些行业的标准，比如媒体资源控制协议(MRCP)，这是一个全球的标准，怎么样跟语音识别技术相互连接的。比如说有了(MRCP)连接协议，可以通过语音引擎，语音门户能够跟它进行连接，这些语音包括文本都是可以相互转换的。这是我们做的电话部分，按照这样的标准去做。还有一个CCXML呼叫控制XML标准，规定怎么样去回答电话，怎么转接电话、怎么样挂电话等等。按照行业的标准来做，我们能够真正的进入到与Web环境里面无缝的连接进来。

　　对于一个真正的开放环境来说，能够有能力非常便宜的运行服务器，非常好的使用我们的架构。这里面关键的组件就是支持Linux的门户。它支持的版本是开源的Linux系统，这是一个巨大的变化。在IVR里面，如果我们熟悉IVR的话，有的时候它是专用的

　　IVR分布在各个国家和全球各个地方，他们保证并不是买重复的认证许可。我们在Avaya的语音门户上说，我有一些基于外部的许可，能够动态的分布许可认证。它意味着什么呢？我们来计算一下业务量的时候，以及有多少渠道和端口来支持IVR的话，我们只是买自己需要的就够了，不需要那么多重复。在语音门户和端口方面，可以依赖于环境的需求去分配。这是一个非常难的认可或者是一种授权，在过去老的单一的办法上。目前在这个环境里面IVR的厂商它面临的环境，他们正在尝试一种动态的许可分配方式，他们自己可以去选择。

　　语音门户可以从一个升级到上千个端口，是一个高度的模块化，在Web的应用上。语音门户像一种硬件设备的做法，它是一个比较低的成本，有高可用性很容易得到的。它是这样一种硬件平台。因为我们现在是一种模块化，即使我们是一种叫做分布式的语音门户，分布于整个国家各种不同地区的IT设施上，考虑到怎么样管理、维护这些设备呢？有一个单一的管理点是很难的，在我们过去单一的IVR里面是这样一种情况。因为每一个是单体的IVR，它所有的事情都是内置在一个系统里面，每一个单一的系统都需要自己的报告系统、管理系统。如果里面涉及到一个非常广泛的企业级的分布系统的话，IVR是一种传统的单体途径，就面临很大的问题。要实现这样一种共同的管理、共同的报告系统就需要集中化的管理模式。

　　我们基于Web的架构里面，我们有能力看到分布在整个网络之上，有一个单独的管理和报表。从媒体的处理器上，包括处理跟语音识别系统结合在一起，把它分开来能够让报告部分看到在它里面是什么情况，已经变的更加容易了。所以我们才设想到怎么样来监控我们的系统和管理系统，我们基于Web的办法有巨大的能力。我们的客户经常说买了很多Avaya的基础设施，该有一些公用的应用和管理，我们想要看到多个Avaya的系统能够整合起来，我们有一个共同的管理、共同的认证、共同的工具。

　　我们所推出的语音门户，因为是一种基于面向服务的架构，正因为这是一个模块化的语音门户，我们能够满足客户的需求，我们以前是做不到的。现在我们有这样一个紧密的集成，跟我们IVR的产品融合起来，我们可以看到这是一种不同的框架，并不只是怎么样开发一种语音的应用，这就变成共同的Eclipse框架。针对我们IVR的工具，在整个联络中心的产品线上，通用的处理工具是非常重要的，如果你是Avaya的客户买了多个Avaya产品的话，你不做什么事情呢？就是四个、五个、六个产品，你所希望看到的是基于客户给我们讲的一些情况，是希望基于一个单一的环境能够充分的利用Web的环境技术，并不是开发语音应用，也设计一些向导，来设计一些PBX的应用和设计IC的应用。Avaya的Eclipse的应用是一个基础，是我们的产品管理战略，我们有一个共同的工具环境，而不是单个的孤立的工具环境。

　　因为我们充分的利用了我们面向服务的架构，还有Web服务。也正是因为我们的开发团队在Avaya里面完全是相互密切合作的，我们可以发现在Dialog Designer里面有非常丰富的，跟其他Avaya产品的集成。比如说在Dialog Designer里面我们有非常密切的集成跟我们Avaya的IC还有PDS的集成，我们能够连接，能够再回到客户跟我们讲的非常明确的要求上降低成本。提高我们的智能，提高客户的满意度，以及整体的解决方案，并不只是IVR有多好，而是关于我们整体的客户体验有多好，涉及到我们整个部署的解决方案，这是他们的要求。这样的话，我现在稍微停一下，我们有一个休息，先讲到这里，休息完之后再给讲一下Avaya Dialog Designer的操作情况，暂时讲到这儿。