首先，在国内如果用任何一个搜索引擎去搜索云呼叫中心，会发现有很多的供应商，可能也会给你进行一些试用，也可以去进行一些基本的操作，你会发现它会有一些它的特点，我们并不否认云呼叫中心有它存在的价值。云呼叫中心比较适合中小型客户，或者说start-ups初创公司。它对话务量、场景要求并没有特别的复杂。它的优势是，通过自动化脚本的定制，能够实现业务的快速提供，能够实现简单化的一些业务的集成。但是它明显的缺点是：没有丰富的连续开发和支持，没有定制化的功能，没有多渠道跨渠道，包括整体与AI能力的方面的支持。云呼叫中心，天然的整体的定位不可能去丰富功能。

 

　　呼叫中心上云是什么概念？我们会发现，当客户的从传统的IDC机房的VMware管理方式迁移到了公有云或者说私有云时，呼叫中心的系统需要配合整体的系统来去进行云的迁移。我们会发现，云的迁移并不是一个痛苦的过程，相反对于软件公司而言，我们是抱着很积极的心态去拥抱云的。呼叫中心上云只是改变了客户对于云部署的一种方式，但同时保留了传统对于数据中心级的呼叫中心的整体系统架构功能的丰富性的保证，同时又可以利用云端的一些便利。

　　第一，整体成熟的软件接口以及它的功能依然保持下来。它如果天然的适合小型中型大型甚至超大型的客户，同时也适合多种渠道，包括多种的平台的对接都能够达到完美的适配。

　　第二，呼叫中心上云实际上是云无关性的。我并不会天然地去绑定某一家云的公司，也就是说对于技术而言，它是一个通用的方案，只是改变了云的部署的方式和使用了云的便利。也就是它可以满足中型或中大型客户对于整体的业务系统云化使用的要求，又可以保留了业务人员对于呼叫中心整体功能和复杂度的这样要求。整体而言，呼叫中心上云完全是可以去替代云呼叫中心的。

　　国内的云呼叫中心分成了两类。传统的云呼叫中心是指，提供了一套CRM的前端，提供的基于云端部署的能力，基于自动化开发脚本支持的点击即可使用的能力。它提供的标准的，一个所谓的语音全家桶，就是呼入、呼出以及基本的文本的聊天的一些功能，通常还会跟运营商或者线路商来进行合作提供话费包。它的好处是快速的能够新建。

　　还有一种，做非传统型的云呼叫中心。这里面实际上是以BAT为代表的公有云和私有云厂商，BAT包括华为在内的公有云和私有云厂商本身并没有踏足呼叫中心这个市场，而目的是他要为了自己的云服务市场，去扩展应用和服务，从而增加用户黏性。事实情况下，呼叫中心是一个挺大的系统工程，使用呼叫中心是云计算的一个最好的伙伴，因为我们会使用大量的服务、大量的数据、大量的计算、大量的存储，这些天然地是IaaS层最好的粘性的卖点。同时我们还提供了PaaS层的，比如说ASR、TTS一些语音的一些增值服务，包括了以BAT华为为代表的，他们会提供一些第三方的AI的服务，这样子整体的用户粘性是非常强的。这也是我把它们定为非传统型云呼叫中心这么一个区分。

　　但是这里面实际上是面临的一些技术情景的，我们会发现无论是我们刚才所说的传统型呼叫中心和非传统型云呼叫中心，它们基本上是基于开源架构来去做的，一般会基于Freeswitch和基于Asterisk为蓝本来进行二次开发。

　　Freeswitch是一个非常好的一门技术，本质上来说它基于C语言开发的同一家server，但是它通过了标准级的适配，以及通过了各级程序员的来自全球各级程序员的开发和努力去实现的基本的模块，包括了语音的处理模块、录音的模块、使用Lua脚本来去开发完成逻辑模块以及IVR菜单模块，当然它是可以去实现基本的语音功能的，但如果想去实现一些联动的场景，比如说多媒体的接入、视频的介入、渠道的整合，包括统一的路由排队，在技术平台上来说本质上而言，它相对来说会较难实现一些。因为区别于其他的开源，比如刚才我们所说的IT开源，比如说芒果DB，比如说Spark、Flink，他们开源，他们也会有一个特点就是，在整个开源领域它会有一个领军的公司去主导这件事情往前走，而Freeswitch实际上它并没有一个主导的公司在引领着整个Freeswitch大家庭去往前走，所以他们在基础平台上短期来说较难去实现一个复杂场景和多业务的场景的适配，也就是说我们的厂商其实基于Freeswitch就做了很多的语音的技术开发，他并没有去做更多的这样一个场景。

　　呼叫中心俨然是一个企业的形象的一个入口，所以数据会显得会更加的重要。所以不能只是把呼叫中心看成语音的一个管道，只是把它看成连接客户的一个渠道。呼叫中心是客户体验提升的手段。我们现在看到很多互联网公司会把呼叫中心从成本中心变成一个创新中心。为什么？因为他们在意客户体验时，发现现在所有的汽车出行领域、美食外卖领域都会产生一个虚拟号码，正是采用这种方式来实现。在技术上来说，就是为了达到更好的体验。

　　无论是传统的和非传统的云呼叫中心，我们发现它有一个很显着的一个特点就是，当它上量之后，往往企业会选择自建。为什么？通过客户的走访，我们也发现其实座席从10到100到300会有什么不同？

　　当呼叫中心座席规模变大是因为业务量变大，客户与企业的交互会增长更快，这个时候说明公司的业务是蒸蒸日上的。必须关注客户的满意度。现在，我们必须注意的是净推荐值，以前聚焦的是如何解决当下的问题，现在我们聚焦的是如何能够让用户有一个好的体验，同时能够推荐给他人，也就是NPS。是否能够一次把问题解决好，是否能让座席有足够的工具和武器帮助客户解决问题。所以拼多多在上市之前，使用的是外包呼叫中心，反正他们是靠拼团靠客户推荐，所以不是很重视呼叫中心。但是拼多多一旦扩大上市，就转而购买了Genesys的客服中心系统，必须为客户体验增值。

　　当呼叫中心座席从100到300之后，运营管理必须要进一步的提升。会更加注重后台的管理和业务的优化。对于运维也提出了更多的一些挑战，提出更多的业务报表的需求。同时还出现了为基于成本的考虑，要去引入人工智能。同时基于整体的企业形象考虑，需要引入社交媒体。此时的业务需求的增长像是一个指数级的增长，如果座席增长是标准的限定级增长，此时传统的云呼叫中心的支持力度就明显会下降，成本就会陡增。

　　如果换一种思路，将企业的这种呼叫中心把它搬上云上来，会发现什么？刚才那些问题，传统的企业里的呼叫中心都是能够解决的。然后，它完整和精确地适配了刚才我们所谓的业务的需求、场景的需求、座席的需求、AI的需求以及容量的需求。同时，由于客服对于云趋势的迈进，我们也利用了上云所带来的便利，能够进一步去降低我们的所谓的CAPEX或者是OPEX。

　　当然了我们在这里面从数据中心的OPEX变成了公有云或私有云的OPEX，但是这里面我们会发现很多的CAPEX我们会进一步地去压缩，我们会使用大量的存储，因为呼叫中心天然要保存大量用户的数据和录音，存储我可以使用云端的这种存储功能，云端的存储，实际上它的可靠性并没有降低，但它的价格就低了很多，比你单独去买一个单纯的存储，它成本是更低。传统我们会采用这种买断式的方式会去买断一个语音识别引擎或者说一个文本引擎。在用云计算的方式，我们实际上是变买为租，会进一步降低我的CAPEX，将CAPEX转成OPEX。

　　用户对于数据企业的数据要求很敏感的时候，比如说数据要求对安全性有顾虑的时候，依然可以采用混合式部署，这个是传统的云呼叫中心所不能提供的，这是呼叫中心上云的提供的一个便利，就是所谓重要数据，或者敏感数据我还依然放在本地部署，核心的东西我放在本地。其他比如说infrastructure放在云端。还有一点就是呼叫中心整体而言我们可以是一个平台无关性的产品，我们可以使用阿里的AI的语音机器人、百度的AI的文本机器。我并不会绑定于某一个平台，而我会去在不同的维度里面选择最适合企业自身的产品，这是云呼叫中心所不能给我们提供的便利。

　　那相比呼叫中心上云与自建呼叫中心还是有一些技术方面对于IT运维带来的挑战。比如说我们传统的录音系统，传统的录音系统可能有很多客户出于成本节约的考虑，会采用这种端口镜像的方式。在传统的据机房是可以完成的，但是在云呼叫中心而言，对于公有云和私有云而言，其实它是很难去做端口镜像的，因为技术上来说是没法去做的。那所以会怎么样？它可以它的录音方式会发生改变，并不是完全录音不了，而是说录音方式是从端口镜像演变为流媒体的方式，或者SIPREC的方式。传统的企业级的这种标准的HAVirtualIP的方式已经不需要了，已经不需要了，因为什么？因为公有云和私有云的网卡本来就是虚拟的，它不能再虚拟第二次。我们会采用这种SIPProxy这种方式，也就是基于SIP级的LoadBalance的方式来进行处理。

　　传统的大型企业自建或者以银行保险为代表的企业自建的这种负载均衡，他们一般都采用比如硬件的F5或者说软件的Nginx。实际上对于云计算公司而言，大量的云计算公司都会提供标准的SLB，也就是业务负载均衡。还有传统的存储方面，刚刚说到录音的存储也发生了改变，安全也发生了改变。在通过这些具体的实践会发现，之前会认为呼叫中心上云之后，远程的职场是需要拉专线去进行连接的，专线可能会采用IPSec或者是SSLVPN的方式，一种是大容量的，一种是单体的。我们现在发现像基于互联网的方式，基于这样加密的方式依然可以实现安全和质量的一个保证。也就是说基于通过我们的具体项目实践，基于互联网的语音，依然是可以值得信赖的，同时安全并没有得到放松，也可以支持云端的一些Single-Sign-On的功能，这些是因为上云所带来的一些改造。