![](http://www.ctiforum.com/uploadfile/2018/0807/20180807041943169.jpg)
一、序言
随着人工智能技术的发展,近半年来涌现了大量基于人工智能的呼叫中心业务服务商和集成商。仅电销机器人这一个方向就至少有近百家公司正在推广运营,包括百度、讯飞、智齿、硅基、百应、箭鱼、容联等。商务上的需求非常强烈,整个市场都飞快地热闹起来。
一套可提供saas服务的智能外呼系统,看起来功能并不复杂。一个网站可注册、充值缴费开票,登录后在后台页面选择或者定制外呼话术脚本,新建外呼任务并导入外呼号码列表,明确外呼策略(时间段、重呼次数),设置外呼机器人数量(同时拨出几个号码),点击开始。然后就可以看着进度条走完,外呼机器人按照列表一个个打电话出去。任务完成后,可以查看外呼结果列表。
那么如何从零开始搭建一套对外可以提供saas服务的智能外呼系统呢?
二、总览
我们先列出,搭建这样一整套系统需要哪些技术和资源:
- 运营商线路:提供方包括三大运营商、集成线路商,这是我们打电话出去要交电话费,必须涉及的供应商。
- 呼叫中心设备:商用设备原厂包括avaya、genesys、cisco、华为等,集成商很多,开源的也有一些。在发起外呼任务时,saas平台是把外呼请求发给了呼叫中心设备经由运营商线路而拨出去的。
- AI能力:包含语音识别、语音合成、语义理解。这就是外呼机器人的核心组成部分,它能听懂接电话的人所说的话、表达的意思,并回复和引导对话。
- saas服务平台:即用户可以注册、登录、缴费、上传呼叫列表、发起外呼任务、外呼结果查看的网站,这个是终端用户唯一可以看得到的前端界面。
简单关系示意图如下:
![](http://www.ctiforum.com/uploadfile/2018/0807/20180807042043771.jpg)
上图中四个主要模块,其中一些难以自研,只能选择供应商:
AI能力部分(中文ASR/TTS)基本已经格局稳定,没太多可挑选的。
运营商资源这块儿,可以选择大牌老厂的码号线路资源多的然后便宜的去谈合作,一方面外呼应用在催收场景时容易被封号,同时话费再便宜也好几分钱一分钟,也是重要的成本。
呼叫中心设备,因为涉及不少接口对接调试,优先选自己熟悉的,其次选便宜的且技术资料多的。
最后是外呼saas平台,可能这是各个电销机器人服务商/集成商最容易实现自研的部分。
明确了涉及到的技术和资源之后,再明确一下建设步骤。由于各个厂商都有各自的资源和能力,建设方式也各不相同,简单来说可以分成以下几类:
有运营商资源的,等着别人找上门来就行了。
呼叫中心厂商,必然有已长期合作的运营商线路资源,手里也有呼叫中心设备+职场,也有技术人员。于是就选择自研saas平台,然后找AI能力厂商合作提供ASR/TTS/NLU。
AI能力厂商,尤其以NLU起家的在线客服类厂商,通常会选择接入百度/讯飞的语音能力,然后去找呼叫中心类厂商合作。
啥都没有,只有几个技术人员的,选择自研saas平台,接入呼叫中心设备、AI能力、运营商资源。
作为初学者,为了自行从零开始搭建一套对外可以提供saas服务的智能外呼系统,身份必然是第四种,啥都没有,啥都要干。
以上这四部分,核心角色是呼叫中心。AI只是插上了想象力的翅膀,但是没这翅膀,呼叫中心还是呼叫中心,但是AI就只是空中楼阁了。业务明确可落地的呼叫中心才是想象力的基石,这一点与CV和安防的关系很像。
三、呼叫中心搭建
1.通信原理
1.通信原理
目前对呼叫中心比较普遍接受的定义是:呼叫中心是以计算机电话集成(CTI)技术系统为基础,将计算机的信息处理功能、数字程控交换机的电话接入和智能分配、自动语音处理技术、Internet技术、网络通信技术、商业智能技术与业务系统紧密结合在一起,将公司的通信系统、计算机处理系统、人工业务代表、信息等资源整合成统一、高效的服务工作平台。
最新一代呼叫中心架构NGCC(Nex tGeneration Call Center)如下图所示:
![](http://www.ctiforum.com/uploadfile/2018/0807/20180807042132509.jpg)
具体如何理解呢?
先从最简单的说起:个人A给个人B打了个电话。
流程:A→PSTN→B
解释:PSTN是Public Switched Telephone Network,公共交换电话网络,也就是运营商的电话网络。
然后来个复杂点的:个人A给呼叫中心400xxxxxxxx打了个电话,拨通后先听到了录音,“您好,找B类接线员说话请按0号键”。按了0,然后听到录音,“排队中,请稍后”。几分钟后接通,B0026号接线员接了电话。
流程:A→PSTN→PBX→IVR→ACD→B
解释:PBX是PrivateBranchExchange,用户级交换机,这是企业内部的局端用户级交换机,整个呼叫中心的出入口设备。
PSTN到PBX之间是中继(分成模拟中继、数字中继、IP中继),这是将通讯公司的局端交换机与企业内部的用户级交换机(PBX)相连的通讯线路。
IVR是InteractiveVoiceResponse,互动/交互式语音应答,我们把它叫语音导航。实现的是类似拨打10086后听到录音说,xx业务请按x,这个环节。主要用途是根据业务分流来电,进入对应的排队机。
ACD是Automatic Call Distribution,自动电话分配,也叫排队机。
再来个复杂点的:个人A给呼叫中心400xxxxxxxx打了个电话,拨通后先听到了录音,“您好,您想找哪类接线员?”
个人A说,“B~~”。
然后很快接通,“您好,这是B0026号机器人,有什么可以帮您?”
个人A说,“我不想跟机器人说话,泥奏凯~”
然后听到录音,“为您转接很贵的真人客服,排队中,请稍后”。
几分钟后接通,B1026号真人接线员接了电话。
流程:A→PSTN→PBX→IVR(→ASR→NLU)→ACD(→ASR→NLU→DM→NLG→TTS)→ACD→B
解释:现在智能的部分,也就是我们说的语音机器人的部分,分别在IVR和虚拟坐席处体现。
IVR部分,不再需要提示按键,而是直接问来电方需要办理什么业务,然后识别语音、理解意图后,进入对应的业务队列排队。排队后可以等待真人客服接待,也可以由机器人先行接待。
机器人(实际是服务器资源)资源空闲时,直接接待,进行语音对话,对话过程就是语音识别、语义理解、语音合成的多次调用,部分业务涉及业务数据接口对接调用,比如查询话费、积分。并可以根据需求自动或者选择转人工,再次进入排队,等候真人客服接待。
其中IVR部分示意图如下:
![](http://www.ctiforum.com/uploadfile/2018/0807/20180807042316569.jpg)
2.集成实施
上面提到的全部流程中,PBX、IVR、ACD等部分基本都是由我们说的呼叫中心设备商提供,产品有三种类型:板卡式、交换机式、VoIP形式。
交换机式比较适合大型职场,例如三五百人以上,硬件价格五位数。交换机领域,主要有:avaya、genesys、cisco、华为、中兴,其中最常用的两家对比下来,avaya比genesys便宜(参见文章)。
板卡式适合中小型职场,比如几十人到两三百人,硬件价格四位数。基于板卡建设呼叫中心的步骤,可以参考使用三汇板卡的这几篇(主要前4篇讲原理)。
选择板卡之前,先要确定选用哪种中继线路,比如:使用常规的数字中继,那么就需要选择数字板卡,这个找板卡的供应商问就行了。通常来说呼叫中心要购买的一条E1数字中继报价五位数/年,由用户级交换机将局端的光信号转换为30路模拟信号,也就是支持30个人同时接打电话,通话费会另外按照实际呼出分钟数收取。
近期一个实际落地项目是选择了数字中继+Asterisk(开源VoIPPBX纯软方案),(可参考:安装配置,调试)示意图如下:
![](http://www.ctiforum.com/uploadfile/2018/0807/20180807042355511.jpg)
具体的软件业务细节,比如:常规客服中心需要的管理模块、配置模块、工单服务、坐席服务、报表模块、CRM,还有比如:坐席班长监听、通话插入、质检,录音文件管理等整套软件细节,不做详述。
四、AI能力对接
在具体落地中,这个领域的常规参与者通常具备呼叫中心能力或者AI能力其中一种,而主要的对接点也就在于AI能力与呼叫中心设备去对接,而ASR/TTS与呼叫中心设备对接的常规协议主要是mrcp/sip。
媒体资源控制协议(Media Resource Control Protocol,MRCP)是一种通讯协议,用于语音服务器向客户端提供各种语音服务(如语音识别和语音合成)。有两个版本的MRCP协议,版本2使用SIP作为控制协议,版本1使用RTSP。
实际对接的时候,会遇到不少技术问题,有的呼叫中心厂商会要求ASR/TTS引擎做私有云部署,这样避免了内外网穿透时防火墙的诸多设置和语音流的时延。这对基于语义起家(并购买语音能力)的公司是一个小小的难题。
1.语音识别
现有技术中实现一次性语音识别典型的流程时序,具体包括一下步骤:
MRCP Client发送INVITE消息给MRCP Server请求建立会话,携带MRCP Client侧的SDP;
MRCP Server回复200表示请求已经成功接受处理,携带MRCP Server侧的SDP;
MRCP Client随后发送ACK消息证实200消息已经收到,至此一个SIP会话成功建立;
MRCP Client发送RECOGNIZE消息给MRCP Server请求语音识别,按照MRCP协议规定的格式携带相关的语音识别控制参数,并且指定语法文件路径;
MRCP Server接收RECOGNIZE请求,编译语法文件,回复200消息给MRCP Client;
MRCP Client此时开始根据之前协商好的SDP,开始源源不断的发送RTP语音流给MRCP Server;
MRCP Server接收RTP语音流,当检测到用户开始说话时,发送START-OF-INPUT事件;
当MRCP Server根据语法文件定义得到识别结果时,通过RECOGNITION-COMPLETE事件返回识别结果;
MRCP Client发送BYE消息给MRCP Server结束会话;
MRCP Server发送200消息给MRCP Client确认结束;
MRCP Client通过上述流程获得MRCP Server提供的一次完整语音识别能力。
电话渠道的语音流采样率一般是8k16bit,这种语音识别的准确率远远低于app等渠道采集音频的识别率。再加上人在打电话时说话方式相对随意,导致语音识别部分成为了影响电话机器人能力和效果的重要瓶颈。
2.语音合成
实现语音合成典型的流程时序,具体包括一下部分:
SPEAK:向服务器端提供文本,启动语音合成(c→s)。
STOP:如果服务器正在语音合成资源,则停止语音合成与语音流(c→s)。
PAUSE:通知服务器资源暂停语音合成与语音流(c→s)。
RESUME:通知暂停的语音合成资源继续进行语音合成与语音流(c→s)。
CONTROL:更改语音合成资源相关参数,从而影响合成的语音流(c→s)。
SPEAK-COMPLETE:SPEAK请求已经成功处理(s→c)。
SPEECH-MARKER:服务器正在处理语音标签时,遇到请求消息头字段SpeechMarker中标记的tag(s→c)。
BARGE-IN-OCCURRED:客户端检测到barg-in-able事件或DTMF数字时,发送该消息通知服务器(c→s)。
现在主流厂商为了使通话效果尽可能模拟真人外呼,除了涉及业务接口调用的数据查询使用了TTS,基本采取整句录音的方式。
3.NLU部分
准确来说,一个简单的对话机器人系统框图,包括语音识别(ASR)、语音合成(TTS)、自然语言理解(NLU)、对话管理(DM)、自然语言生成(NLG)几个模块组成。而这一部分就是智能外呼系统的主流玩家——NLU类(智能客服)厂商的强项了。
![](http://www.ctiforum.com/uploadfile/2018/0807/20180807042619838.jpg)
对于呼叫中心从业者来说,ASR/TTS/NLU如同黑盒一般,只暴露出接口。而国内语音能力的供应商,要么很土豪,少量QPS不要钱,要么就是非常标准的报价五位数一条线路/年,实在也没有太多可以选择的余地。
对于只有NLU能力的厂商来说局面也是一样,除了需要接入ASR/TTS的能力,还需要去寻找可以合作的呼叫中心,并且想办法拿到尽可能低的话费报价。
五、行业现状
经过一些调研和竞品分析,行业内虽然有至少近百家公司在推广和运营电销机器人,但毫不客气地说,大部分都不及格。
一星级★
官网粗制滥造,类似有漂浮闪动flash,反复频繁提示你联系商务。
对各类基础能力只有含糊其辞的描述,没有录音、演示、试用途径。
二星级★★
有录音可以试听,但明显可以听出来,部分是真人直接对话录音,而并非机器人与真人的通话录音。部分若干家公司用于试听播放的录音文件完全一致,不知道谁抄谁的。
三星级★★★
有录音可以试听,甚至也有演示视频。录音可能仍有作假嫌疑,演示视频部分能感觉出来是按照特定的对话脚本去走流程,但是可以完成多轮对话了,语音时延在2s以内,属于基本可用。
不支持NLG,机器人所说的内容均为录音。
四星级★★★★
支持NLG(Natural Language Generation),支持字段调用,支持TTS合成与录音无缝衔接。但由于TTS调用的是某几个大厂的api,而录音多数为自己根据业务需求去录的,会出现衔接生硬的问题。解决方案是直接全文TTS,或者选择与TTS音色相接近的播音员进行录制。
对打断的处理有待优化,要么不支持打断,要么打断后处理方式粗糙(如重播、多次打断后多次直接播放对应录音)。
语义理解能力相对较弱,但配合相对完善的话术策略,可以保持相对可接受的兜底。
五星级★★★★★
支持对话中识别关键词打断。如介绍推销信息时被打断问价格,则直接停下并立刻回复价格信息。
报价模式不局限于“线路xxxxx元/年,话费0.xx元/分,话术脚本xxxx/个”的模式。如纯录音外呼机器人0.xx元/分,含NLG的外呼机器人x。xx元/分。
除了根据业务场景定制话术脚本之外,基于已有的积累(如呼叫中心金牌电销的通话记录等)形成特定行业的金牌话术模板,只需要填入特殊字段信息即可使用。
语义层面,支持跨节点/返回节点问答(比如:先回答说我不是本人,进入到下一个节点后,客户再说一次我是本人,系统仍能处理)。
外呼结果分析,目前阶段通常机器人外呼只用来做第一轮初筛,需要对通话内容进行语义判断,按需分析是否需要第二轮人工跟进。
通话中转人工,是否允许在机器人外呼过程中被动或主动转人工,这一项在实现时接近于IVR部分机器人应答+转人工的模式,在流程设计和资源配置上相对有难度。
根据通话内容自动判别二次回拨,如被告知“现在没空接电话,10分钟后再给我打”(机器人二次呼叫),或者表示“有兴趣,需转人工跟进”后经由预测式外呼后回拨到用户号码上(真人接线)。
六、商业落地
商务模式比较简单粗暴,粗略的成本核算如下:
首先运营商的通讯资源,几分钱一分钟的话费成本,以及平均下来一千左右一路的中继线路费用。
其次是呼叫中心厂商的服务器、带宽、呼叫中心设备license/运维等成本。
再次是AI能力的使用费,比如:讯飞公开报价2w每线路每年。
最后是外呼saas平台的建设和运维成本。
那么电销机器人厂商,竞争这么激烈,谁才会笑到最后呢?
一是要有价格相对低廉的运营商资源和语音能力资源,这样可以明确的报出一个行业内相对较低的价格。比如:完全不按照主流友商们1-3w/线/年的报价方式,直接来几毛钱一分钟随便打,随打随充。
二是呼叫中心资源方,最好是带客进场,别从0开始找客户,直接把现有的呼叫中心B端客户转化一部分成为机器人电销客户。
三是语义的能力,尤其是话术模板的设计能力。这一块儿很容易被忽视,但是这反而也是产品经理可以出成绩的地方。一般来说可以拿呼叫中心多年积累的语料去分析一套最佳话术模板(堪比金牌销售的万能对话体系),然后做ABtest也好。
从mvp开始逐渐增加主要话术分支也好,心理学基础必须要有,必要时可以从游戏成瘾机制等角度入手,《恋与制作人》的对话技巧学起来,一句话怎么说能让接电话的人最大概率的顺着自己的思路走,达成目的,从而形成特定细分领域机器人话术模板,得到最佳的外呼效果(接通率、通话时长、电销意愿、催收意愿)。
这一块儿虽然很细,但是反复迭代之后可以以一敌万,甚至达到现在各类智能音箱背后核心系统一样的地位。
四是外呼saas平台。这部分是web类产品经理的天下了,具体功能点就不详细列举了,友商们的网页和后台过一遍,基本好坏也能判断出来了。
至于现在此时此刻被视作亮点的可视化外呼脚本编辑,笔者个人认为其实是鸡肋,普通人根本用不好,脚本逻辑只能做得很简单,多轮对话、跨节点对话效果也不好,反而很容易导致客户放弃。还不如干干脆脆给个可设置变量的场景化标准模板(金牌话术模板由产品经理提供),外呼试用效果好,客户更容易买单。
七、结语与参考资料
这一套智能外呼系统搭下来,不仅仅可以做电销机器人,可以做各类外呼,也可以做IVR语音导航、呼入电话客服。“NLU+CallCenter”就像这几年“CV+安防”的结合一样,也会如商汤科技联合创始人林达华所说:
“中间也存在风险:一边是从应用端往前走,一边是从技术端往后走,大家都想占领技术上的制高点。这需要大家建立一种信任和共赢机制,只有这样合作才能长久”。
AI虽然火热受追捧,但具体项目落地并被市场认可和买单并不是那么容易。作为入行并不久的初学者,尝试借以此文抽丝剥茧梳理了从0开始搭建智能外呼系统的全流程,才疏学浅囿于见闻,疏漏和不当之处在所难免,权当抛砖引玉。
诸多细节限于主题和篇幅不做详述,如有任何问题,欢迎随时交流。
参考资料:
- 《呼叫中心技术》,詹舒波等,人民邮电出版社,2015-09-01
- MRCPv2概述
- MRCPv2–Speech Synthesizer Resource
- MRCP协议学习笔记
- MRCPv2协议及其在分布式语音资源解决方案中的应用
- 华为在审专利:一种语音识别方法及装置
- 百度-智能呼叫中心JavaSDK文档
#专栏作家#
hanniman,人人都是产品经理专栏作家,前腾讯、现创业公司PM;专注于人工智能领域的产品化研究,关注人机交互(特别是语音交互)在手机、机器人、智能汽车、智能家居、AR/VR等前沿场景的可行性和产品体验;擅长对创业团队管理、个人成长提出实战型的建议方案;知乎/简书/微博帐号,均为hanniman。