这篇文章里，作者基于产品视角，对呼叫中心系统的相关专业术语做了梳理和分析，想了解的同学，不妨来看一下，或许会有助于你日常工作中的沟通和需求理解。
知其然也要知其所以然。如果了解了呼叫中心很多专业术语的含义，对于产品和运营在日常工作中沟通和理解需求会有很大的帮助。今天我会从很多专业名词的来源，一步步解析，方便大家了解呼叫中心系统。
1875年贝尔在实验室内发明了电话，但是最初的电话呼叫必须在订户之间直接连接：电话和电话线是成对出售的。如果有100个用户需要实现电话互通，那就至少需要100*99=9900条电话线路。
这种电话网络的搭建成本极为高昂。为了解决这个问题，在1878年诞生了世界上第一个“交换机”。所有用户直接与交换机相连，然后再由交换机去实现两台终端电话的转接连线。交换机与终端电话之间的电话线路，被称之为中继线。
电话的普及使得电话沟通不再局限于一城之内，如果每个终端电话都需要与远距离的交换机搭建中继线，这个成本过高。所以，现代电话网络一般是通过交换机的组合联网，终端电话与端局交换机直连，再由端局交换机连接市级交换局，市级连接长途局，依此类推，最终可以实现全球组网。
以上图举例，用户或者企业会直连端局交换机（在人口密集地区可能还会设置模块局），端局交换机再向上分别是市级汇接局、长途局、省中心、大区中心。目前国内的八大区中心分别是：上海市、北京市、沈阳市、南京市、武汉市、西安市、成都市、广州市。
终端用户不仅指的的家庭电话，现在越来越多的企业用户成为电话系统的终端用户。由于企业内部也有很多的电话用户，每个用户都与电话运营商直连，不仅运营商对接成本高，同时企业内部成员的电话沟通也需要经过运营商，从而产生费用。但是如果企业内部自己搭建一个小型的电话交换网络，不仅与运营商的对接可以统一维护，同时企业内部成员的电话联系就不需要再额外向运营商付费了。这样的交换网络，我们称之为PBX（Private Branch Exchange），定位是企业级交换机。
PBX一般不会只接一家电话运营商，对同一家电话运营商针对于电话线路用途不同，一般也会申请多条中继线线路。需要选择哪条中继线路进行外呼，需要运营商和企业约定，一般我们是通过中继号码进行区分。值得一提的是，用户侧真实展示的号码和中继号码很多时候是不一样的。
随着移动通信的发展，手机用户的普及率越来越高。移动通信的原理其实也是类似，只不过我们把移动通信基站当做了一个交换机，手机与移动通信基站通过微波信号连接，基站再接入电话网络。
传统PBX是一个硬件设备，但现在的企业电话网络中，传统的硬件PBX已经逐步可以由逐步成熟的软交换（SoftPBX）方案替代。PBX的核心功能主要用于企业内部的电话交换、路由，比如日常我们的话务分配、溢出、转接（转人或转IVR）等功能。
是计算机电话集成系统（Computer Telephone Integration）。CTI的核心功能主要是在对通话的控制、处理，通话数据的存储。比如坐席终端（软电话、SIP话机、PSTN固话、手机）的接起、挂断、hold、会议、来电弹屏、自动拨号、录音、语音数据报表等。
ACD：自动呼叫分配（Automatic Call Distribution，ACD），是一种特殊的程控交换机。与传统的PBX相比，ACD的分配支持更多的可由计算机程序控制的分配算法。最为常用的包括：线性加权优先级排队算法、指定号码识别的路由算法、基于客户/坐席分层匹配算法。
线性加权算法，主要用于确定客户排队排序的优先级。根据客户重要等级，调整客户是否被优先接起。排队优先级 = λ * customerlevel + 客户排队等待时间， λ 可根据业务需求定义，用于调整客户等级对排队优先级的影响程度。
指定号码识别路由，可以根据用户的历史咨询情况，可以定向路由给指定客服。比如曾经给过A客服好评、24小时被A客服接待过，这些场景是可以做到优先分配给A客服。
基于客户/坐席分层匹配算法，主要是为了解决相同服务技能但能力高低不同的客服，针对于不同级别的客人、不同细分子问题的分层匹配问题。高技能客服优先接待复杂的、高等级的客人，低技能客服优先接待简单的、低等级的客人，在其中一类客服忙碌，这两类客服可以互作backup。
由于不同的ACD算法，在事实上解决的问题不同，所以，原则上在确定分配算法优先级的情况下，是可以支持多种分配算法结合的分配策略的。
FreeSwitch是一个跨平台的开源电话交换平台，支持多种技术标准，最常用的就是 SIP，和H.323。它主要是作为软交换引擎，被目前大多数的电话系统供应商作为底层服务框架，迭代开发。同时它也有支持CTI的很多服务功能。平时，在电话系统的开发沟通过程中提到的FS，一般就是指部署了FreeSwitch的服务器。
实时传送协议（RTP，Real-Time Transport Protocol），提供端对端的网络传输功能，适合应用程序传输实时数据，包括音频、视频或其他数据。
RTP协议有一个伴生的RTCP协议，两者皆是基于UDP通道进行传输。实时的通话语音流基本都是通过RTP进行传输（这包括实时的ASR和TTS中的语音流信息）。
由于是基于UDP通道进行传输，所以RTP的传输不能保证可靠性，不能保证语音流信息准确、按序传输，所以通话语音信息容易出现丢包、抖动、延时导致的语音丢字、杂音等情况。虽然RTCP会记录一些随路信息，但这些信息也是针对于语音包的单独信息，语音的错误检测和顺序检测，仍然需要依赖于客户端或服务端计算后校正。
常用的通话控制协议包括SIP， H.323等。SIP（Session initialization Protocol，会话初始协议），主要是用于信令的控制。大部分的IP电话的服务商提供的都是基于SIP协议的服务。SIP协议本身是一个文本控制协议，是TCP协议的上层应用协议，它的传输是可靠的。在呼叫中心的场景中，SIP协议主要用于控制通话得一些指令，例如发起通话、振铃、接听、挂断、转接、发起会议等，也可以将一些随路信息通过SIP信令串联到通话的整个链路里。
举例，用户通过A号码呼叫B号码给甲公司，甲公司与乙公司为合作关系，且都有自己的呼叫中心，乙可以代替甲承接该用户的咨询。甲公司通过SIP将电话转接给乙公司，乙公司可以通过SIP信令中传递的信息，获取“用户号码、A、B、甲、乙”完整的信息的。
双音多频 DTMF（Dual Tone Multi Frequency），主要是用于在通话中，通过按键来进行信息采集并传输，例如：客户邀评、客户IVR菜单的选择、采集订单号、采集身份信息证的等。
DTMF由高频群和低频群组成，高低频群各包含4个频率，组合可得16个按键编码，所以，在电话中，通过按键传输信息按键数最多不能超过16个。完整的DTMF键盘是4*4的矩阵，电话每一行代表一个低频，每一列代表一个高频，包含10个数字键和6个功能键。
IVR(Interactive Voice Response)互动式语音应答。目前大型呼叫中心基本都会存在IVR语音菜单。
传统的IVR语音菜单，大部分会采用人工的录音进行播报，再利用DMTF采集客人的按键信息，根据采集到的结果，进行客人问题的分类和路由。随着ASR和TTS技术的发展，语音菜单的播报中可以支持动态播报订单、客户信息相关数据，采集用户信息的方式也从按键采集拓展到了语音信息采集，从而使用IVR衍生出了又一类比较重要的分支应用模块：智能语音机器人。
ASR（Automatic Speech Recognition，自动语音识别）和TTS（Text To Speech，从文本到语音），是人工智能方向的一个重要分支。在CTI的应用系统中，TTS和ASR如果结合IVR的功能，就能实现语音场景下智能交互机器人。
相比较而言，DTMF采集的信息量有限，比如用户如果想要通过电话，预定一张4月16号，从北京飞往上海，东航的机票，如果使用按键采集，是没法采集这么复杂的信息的，但是通过语音交互就可以实现。另一方面，语音交互的方式更像真人，可以用语音机器人代替真人做一些外呼通知、营销场景的工作。
同时ASR也会被应用语音智能质检相关的功能上。
目前语音智能服务的瓶颈，主要是在ASR和NLP处理这块。一方面，由于用户的口音、方言，ASR比较难以识别，另一方面由于RTP语音流传输的不可靠性，存在语音信息丢失或错位的情况。这两方面原因，会使生产环境下ASR转写的准确率不能达到实验室数据那么高。
WebRTC、Sip话机和Sip软电话都是客户端的电话解决方案。
WebRTC是允许浏览器不通过其他媒介，直接依赖于浏览器实现语音流通话，优点在于随时随地都可以通过登录浏览器进行工作，缺点是语音质量不能得到很好的保证，同时如果浏览器关闭或崩溃，语音通话直接会被切断。
SIP话机是一个硬件设备，形态上和传统固话类似，只不过他是通过网线连接来实现通话。缺点硬件采购成本较高，且对硬件的强依赖，一旦发生紧急事件，没有硬件设备是无法兜底服务的。优点也很明显，通话语音质量好，且由于是独立的网线，即便是电脑关机，也不影响SIP话机的工作。
SIP软电话是SIP话机和WEBRTC的一个折中方案，它依赖于浏览器外置的SIP软件实现语音流传输，所以浏览器出现异常不会影响通话。通话质量会介于Webrtc和SIP话机之间，软件安装成本又相对可控，这应该是目前轻量级呼叫中心相对性价比最优的客户端电话解决方案。
本文是基于一个产品视角，对呼叫中心的专业术语的一些解释。如果大家对本文内容有质疑的或是希望我有补充的，可以补充评论，我会进行更新。
本文由@爱吐槽的徐教授 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。