如何从零开始搭建智能外呼系统?

17 评论 31329 浏览 153 收藏 26 分钟

本文作者是“AI产品经理大本营”团员何静 ,她用非常接地气的文字介绍了智能外呼系统的必备入门信息,对于不是这个细分领域的AI从业者来说,非常值得一看。

一、序言

随着人工智能技术的发展,近半年来涌现了大量基于人工智能的呼叫中心业务服务商和集成商。仅电销机器人这一个方向就至少有近百家公司正在推广运营,包括百度、讯飞、智齿、硅基、百应、箭鱼、容联等。商务上的需求非常强烈,整个市场都飞快地热闹起来。

一套可提供saas服务的智能外呼系统,看起来功能并不复杂。一个网站可注册、充值缴费开票,登录后在后台页面选择或者定制外呼话术脚本,新建外呼任务并导入外呼号码列表,明确外呼策略(时间段、重呼次数),设置外呼机器人数量(同时拨出几个号码),点击开始。然后就可以看着进度条走完,外呼机器人按照列表一个个打电话出去。任务完成后,可以查看外呼结果列表。

那么如何从零开始搭建一套对外可以提供saas服务的智能外呼系统呢?

二、总览

我们先列出,搭建这样一整套系统需要哪些技术和资源:

  • 运营商线路:提供方包括三大运营商、集成线路商,这是我们打电话出去要交电话费,必须涉及的供应商。
  • 呼叫中心设备:商用设备原厂包括avaya、genesys、cisco、华为等,集成商很多,开源的也有一些。在发起外呼任务时,saas平台是把外呼请求发给了呼叫中心设备经由运营商线路而拨出去的。
  • AI能力:包含语音识别、语音合成、语义理解。这就是外呼机器人的核心组成部分,它能听懂接电话的人所说的话、表达的意思,并回复和引导对话。
  • saas服务平台:即用户可以注册、登录、缴费、上传呼叫列表、发起外呼任务、外呼结果查看的网站,这个是终端用户唯一可以看得到的前端界面。

简单关系示意图如下:

上图中四个主要模块,其中一些难以自研,只能选择供应商:

  1. AI能力部分(中文ASR/TTS)基本已经格局稳定,没太多可挑选的。
  2. 运营商资源这块儿,可以选择大牌老厂的码号线路资源多的然后便宜的去谈合作,一方面外呼应用在催收场景时容易被封号,同时话费再便宜也好几分钱一分钟,也是重要的成本。
  3. 呼叫中心设备,因为涉及不少接口对接调试,优先选自己熟悉的,其次选便宜的且技术资料多的。
  4. 最后是外呼saas平台,可能这是各个电销机器人服务商/集成商最容易实现自研的部分。

明确了涉及到的技术和资源之后,再明确一下建设步骤。由于各个厂商都有各自的资源和能力,建设方式也各不相同,简单来说可以分成以下几类:

  1. 有运营商资源的,等着别人找上门来就行了。
  2. 呼叫中心厂商,必然有已长期合作的运营商线路资源,手里也有呼叫中心设备+职场,也有技术人员。于是就选择自研saas平台,然后找AI能力厂商合作提供ASR/TTS/NLU。
  3. AI能力厂商,尤其以NLU起家的在线客服类厂商,通常会选择接入百度/讯飞的语音能力,然后去找呼叫中心类厂商合作。
  4. 啥都没有,只有几个技术人员的,选择自研saas平台,接入呼叫中心设备、AI能力、运营商资源。

作为初学者,为了自行从零开始搭建一套对外可以提供saas服务的智能外呼系统,身份必然是第四种,啥都没有,啥都要干。

以上这四部分,核心角色是呼叫中心。AI只是插上了想象力的翅膀,但是没这翅膀,呼叫中心还是呼叫中心,但是AI就只是空中楼阁了。业务明确可落地的呼叫中心才是想象力的基石,这一点与CV和安防的关系很像。

三、呼叫中心搭建

1. 通信原理

目前对呼叫中心比较普遍接受的定义是:呼叫中心是以计算机电话集成(CTI)技术系统为基础,将计算机的信息处理功能、数字程控交换机的电话接入和智能分配、自动语音处理技术、 Internet技术、网络通信技术、商业智能技术与业务系统紧密结合在一起,将公司的通信系统、计算机处理系统、人工业务代表、信息等资源整合成统一、高效的服务工作平台 。

最新一代呼叫中心架构NGCC(Next Generation Call Center)如下图所示:

具体如何理解呢?

先从最简单的说起:个人A给个人B打了个电话。

  • 流程:A→PSTN→B
  • 解释:PSTN是Public Switched Telephone Network,公共交换电话网络,也就是运营商的电话网络。

然后来个复杂点的:个人A给呼叫中心400xxxxxxxx打了个电话,拨通后先听到了录音,“您好,找B类接线员说话请按0号键”。按了0,然后听到录音,“排队中,请稍后”。几分钟后接通,B0026号接线员接了电话。

流程:A→PSTN→PBX→IVR→ACD→B

解释:PBX是Private Branch Exchange,用户级交换机,这是企业内部的局端用户级交换机,整个呼叫中心的出入口设备。

PSTN到PBX之间是中继(分成模拟中继、数字中继、IP中继),这是将通讯公司的局端交换机与企业内部的用户级交换机(PBX)相连的通讯线路。

IVR是Interactive Voice Response,互动/交互式语音应答,我们把它叫语音导航。实现的是类似拨打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部分示意图如下:

2. 集成实施

上面提到的全部流程中,PBX、IVR、ACD等部分基本都是由我们说的呼叫中心设备商提供,产品有三种类型:板卡式、交换机式、VoIP形式。

交换机式比较适合大型职场,例如三五百人以上,硬件价格五位数。交换机领域,主要有:avaya、genesys、cisco、华为、中兴,其中最常用的两家对比下来,avaya比genesys便宜(参见文章)。

板卡式适合中小型职场,比如几十人到两三百人,硬件价格四位数。基于板卡建设呼叫中心的步骤,可以参考使用三汇板卡的这几篇(主要前4篇讲原理)。

选择板卡之前,先要确定选用哪种中继线路,比如:使用常规的数字中继,那么就需要选择数字板卡,这个找板卡的供应商问就行了。通常来说呼叫中心要购买的一条E1数字中继报价五位数/年,由用户级交换机将局端的光信号转换为30路模拟信号,也就是支持30个人同时接打电话,通话费会另外按照实际呼出分钟数收取。

近期一个实际落地项目是选择了数字中继+Asterisk(开源VoIP PBX纯软方案),(可参考:安装配置调试)示意图如下:

具体的软件业务细节,比如:常规客服中心需要的管理模块、配置模块、工单服务、坐席服务、报表模块、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提供的一次完整语音识别能力。

电话渠道的语音流采样率一般是8k 16bit,这种语音识别的准确率远远低于app等渠道采集音频的识别率。再加上人在打电话时说话方式相对随意,导致语音识别部分成为了影响电话机器人能力和效果的重要瓶颈。

2. 语音合成

实现语音合成典型的流程时序,具体包括一下部分:

  • SPEAK:向服务器端提供文本,启动语音合成(c→s)。
  • STOP:如果服务器正在语音合成资源,则停止语音合成与语音流(c→s)。
  • PAUSE:通知服务器资源暂停语音合成与语音流(c→s)。
  • RESUME:通知暂停的语音合成资源继续进行语音合成与语音流(c→s)。
  • CONTROL:更改语音合成资源相关参数,从而影响合成的语音流(c→s)。
  • SPEAK-COMPLETE: SPEAK请求已经成功处理(s→c)。
  • SPEECH-MARKER:服务器正在处理语音标签时,遇到请求消息头字段 Speech Marker中标记的tag(s→c)。
  • BARGE-IN-OCCURRED:客户端检测到barg-in-able事件或DTMF数字时,发送该消息通知服务器(c→s)。

现在主流厂商为了使通话效果尽可能模拟真人外呼,除了涉及业务接口调用的数据查询使用了TTS,基本采取整句录音的方式。

3. NLU部分

准确来说,一个简单的对话机器人系统框图,包括语音识别(ASR)、语音合成(TTS)、自然语言理解(NLU)、对话管理(DM)、自然语言生成(NLG)几个模块组成。而这一部分就是智能外呼系统的主流玩家——NLU类(智能客服)厂商的强项了。

对于呼叫中心从业者来说,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开始搭建智能外呼系统的全流程,才疏学浅囿于见闻,疏漏和不当之处在所难免,权当抛砖引玉。

诸多细节限于主题和篇幅不做详述,如有任何问题,欢迎随时交流。

参考资料:

#专栏作家#

hanniman,人人都是产品经理专栏作家,前腾讯、现创业公司PM;专注于人工智能领域的产品化研究,关注人机交互(特别是语音交互)在手机、机器人、智能汽车、智能家居、AR/VR等前沿场景的可行性和产品体验;擅长对创业团队管理、个人成长提出实战型的建议方案;知乎/简书/微博帐号,均为hanniman。

本文原创发布于人人都是产品经理,未经许可,不得转载。

题图来自 Pixabay,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 九四AI,欢迎大家交流学习

    来自北京 回复
  2. 13156566517 ,外呼系统不被挂!

    来自安徽 回复
  3. 大佬求请教,正好在从事这方面的工作,方便加个v x吗 nightwf

    来自浙江 回复
    1. 哈喽!外呼系统你现在在用吗

      来自菲律宾 回复
    2. 我们在做外呼系统的

      来自浙江 回复
    3. 可以加个V信吗,我们也在做,脑袋大了

      来自浙江 回复
  4. 求交流

    来自四川 回复
  5. 有没有在线客服机器人的知识普及呢?

    来自北京 回复
    1. Hi
      你是做什么的

      来自菲律宾 回复
  6. 你好能六个联系方式吗

    回复
  7. 取经

    来自江西 回复
  8. 想请教下,关于“语义层面,返回节点问答”是否会制造出较多的badcase,造成会话的流程混乱呢

    来自北京 回复
  9. 怎么能联系上作者,交流交流

    回复
  10. 关于可视化话术配置像鸡肋不敢苟同,金牌话术固然重要,可作为通用模版省去个性化定制。但是通过培训代理商的策略将编辑话术的成本进行分担将会大大提高响应速度。同做这一块的,有机会可以交流一下~

    来自江苏 回复
  11. 大佬 ,你好 刚刚看到你文章中写的SaaS平台需要一步动作就是上传呼叫列表、发起外呼任务、外呼结果查看的网站,那有没有一键同步对接通话和报表同步生成的呢

    来自上海 回复
  12. 捧捧场 🙂 希望有机会能探讨一下合作方式

    来自北京 回复
    1. 大佬 ,你好 刚刚看到你文章中写的SaaS平台需要一步动作就是上传呼叫列表、发起外呼任务、外呼结果查看的网站,那有没有一键同步对接通话和报表同步生成的呢

      来自上海 回复