浅谈呼叫中心中多媒体、富媒体、全媒体的内涵

　　传统的Genesys多媒体渠道都包含哪些？

　　1、邮件Email，包含WebEmail

　　2、聊天Chat，一般指PC端网页版Chat

　　3、短信SMS，包含MMS彩信

　　4、工单Workitem，或称通知信息

　　5、WebCallBack，网页回呼

　　6、Co-Browsing，共享浏览

　　7、传真Fax

　　一般来说邮件系统和聊天系统是最常用的两种渠道。

　　短信服务一般是与CRM系统进行进程，CTI系统使用短信服务业无非是SMPP标准协议，彩信业务仅存在理论上的业务，已经被微信所替代。

　　大部分银行还依然提供传真服务，一般会使用Fax-to-email无纸化传真，借用Email渠道来提供传真服务。

　　呼叫中心的后台工单流转系统Workitem一般也会以CRM／ERP的方式来提供。

　　Webcallback在大多数用户的实际应用实践中都是用户的IT部门来在网页前端展示，后台插入回呼数据库，然后由CTI读取话单并推送至坐席桌面Click to callback来实现。

　　Co-browsing自诞生以来就一直推广不利，主要是受制于用户网速，网络防火墙等限制，而且涉及用户界面敏感信息等，实际的用户普及率并不高。如果是企业内部，一般都会在UC上来实现，实在不济的，teamviewer／QQ远程。

　　咳，咳，后来啊～系统开始进化了

　　FB和TW在天朝以外使用广泛，Genesys特意做了相应的API Adapter，可以通过ESP协议转换为一个Interaction接入至呼叫中心系统中来。后来Facebook修改了规定，后续有企业存在Facebook坐席的情况，需要由Genesys来统一代为申请账号，基本上G厂是唯一能够提供FB坐席的CTI厂家。

　　微博和微信在中国的大范围使用，Genesys在中国的技术合作伙伴们纷纷在Multimedia平台上二次开发了微博和微信的接口。

　　一般来说，用户打开网页时看见悬浮的chat widget可能会关闭窗口，等到真正要用了，反而就找不到聊天窗口了。Proactive Chat的方法论基于用户的行为轨迹，只有在用户的特定行为触发后才会主动弹出邀请聊天对话框。特定行为可以是页面停留时间，也可以是网站浏览轨迹，或者特定关键词搜索等。注意：用户才是主动发起聊天的一方，坐席无论如何也不该主动弹出聊天对话框打字的...。。Proactive Chat其实不算是主动式聊天，顶多是主动式弹出聊天屏。

　　番外配音：为什么没有Whatsapp和Line和imessage？差评！

　　因为做不到呀～这两家压根就没有对接的官方API，不要跟我说第三方开发的whatsapp API或者Line企业号，它们还非常原始，很多时候系统集成商们都得“猜”出它们的API，每次他们升级，集成商又得被动地再猜一回。笔者良心来讲：让世界存在几个简单的P2P聊天工具吧，这几个APP压根就不是作用户-企业沟通的工具呀。

　　咳，咳，后来啊～系统开始变形了

　　随着APP的广泛流行，用户操作行为的改变，呼叫中心可以在移动APP或者移动Web上来提供聊天服务，Genesys基于MobileServer提供的Rest接口方便调用chatAPI，提供Native的内嵌式聊天，将Chat由PC网页端引入至手机端。

　　多模态，不是量子理论，而是特指用户在与呼叫中心交互过程中使用了多种的渠道并发，通话的过程中，接受一个短信，打开一个链接展现出可视化IVR菜单，同时可以网页／通话互操作。

　　狭义的多媒体，可以理解为呼叫中心铺设了多种用户接入的渠道，你要语音我给你语音，你要邮件我给你邮件，但是每一个渠道都是独立的，可能会存在来自不同渠道坐席回复标准不一的情况，这就尴尬了。别担心，Genesys还有One Converatation和Customer Journey的概念，改天慢慢谈。

　　狭义的富媒体，可以理解以时间为刻度线性地提供多种媒体与用户交互，比如用户打了一个电话到呼叫中心，通话结束后系统给一个短信做满意度调查，用户回复不满意，触发一个callback的流程由QA坐席闻讯情况，处理结果后续再以邮件告知。丰富地使用者各种媒体来与用户交互。

　　狭义的全媒体，可以理解为One Converation，在各个渠道提供一致的用户体验，呼叫中心的后台需要实时的数据库支持，同时在路由逻辑上保证用户数据的一致性，引入lastagentcall、多模态等技术为用户提供服务。