呼叫中心架构设计

本贴最后更新于 2800 天前,其中的信息可能已经时移世易

背景

  • 客户在打电话给客服(坐席)时需要保护自己的隐私(客户电话号码不能透传给客服)
  • 客服在打电话给客户时可根据实际对应业务来设定是否进行号码透传(大部分场景是透传)
  • 对一些业务提供基础数据的支撑(通话开始时间、结束时间、录音等)
  • 不建立真正的实体呼叫中心,而是接入多个第三方提供的云通话服务完成实际通话过程,降低成本和风险

为此我们需要实现一个能够能够支撑业务实现并能够接入多个云通话服务渠道的系统,命名为 CC(Call Center,呼叫中心)。

架构设计

从呼叫模式上看,目前业界大多数采用的是“回拨”模式,即由呼叫中心发起两路呼叫,然后将两路进行连通。提供回拨服务的厂商比较多,比如玖云、华为、吉亚等,下面以玖云和华为为例进行架构设计。(选择玖云和华为主要是因为他们正好使用了不同的两种通话状态获取模式,玖云是回调,而华为是轮询)

1468845260279

(图片看不清的话请另存为后查看)

子模块

  • Callback Logging:玖云事件回调持久化,实现上使用 NGINX 写文件日志
  • Scheduled Task:华为事件轮询
  • Dispatch & Handle:处理来自 Callback Logging 和 Scheduled Task 的通话事件
  • Unified Call Records:统一格式的通过记录持久化存储
  • Channel:提供给应用调用,完成“用户-坐席-渠道”的关联管理功能
  • User-Agent-Channel:“用户-坐席-渠道”持久化存储
  • Call:提供给应用调用,完成“回拨”功能
  • Call Query:提供给应用调用,完成通话数据查询功能
  • Health:渠道及回调日志健康状态检查,以及渠道故障时让 Channel 自动切换渠道
  • Aliyun OSS:将获取到的通话录音上传到阿里云 OSS 进行存储

通话记录表

列名 类型 长度 备注
id bigint 20 主键
tenant varchar 32 租户标识
main_num varchar 16 400 商户号码
ext_num varchar 8 400 商户分机号码
agent varchar 64 坐席标识
call_id varchar 64 由渠道返回的话单 id
caller varchar 16 主叫(A 路)号码
called varchar 16 被叫(B 路)号码
biz_data text 业务数据
channel varchar 8 渠道标识:(玖云:e9;华为:hw;吉亚:jy)
ch_state varchar 32 渠道返回的话单当前状态
state varchar 8 话单当前状态。初始化(发起呼叫 A 路):init;双通:conn;关闭:close
a_call_time bigint 20 呼叫 A 路时间
b_call_time bigint 20 呼叫 B 路时间
a_offhook_time bigint 20 A 路摘机(接通)时间
b_offhook_time bigint 20 B 路摘机(接通)时间
conn_time bigint 20 双通时间
close_time bigint 20 关闭通话时间
duration int 11 通话时长(秒)
ch_audio_url varchar 512 渠道录音文件 URL
audio_url varchar 512 外部存储录音文件 URL
ivr_url varchar 512 IVR 语音文件 URL
ivr_text text IVR 文本内容
close_type varchar 32 0:正常挂断;1:A 路无法接通;2:B 路无法接通;3:A 路目标忙;4:B 路目标忙;5:通话达到最大时长;6:渠道服务器错误;7:渠道网络错误;255:其他错误
updated bigint 20 记录更新时间
created bigint 20 记录创建时间

回拨流程

  1. 应用发起回拨请求,调用 Call
  2. Call 调用 Channel,有 Channel 选择适合的渠道,并通过公网 HTTP(S) 进行回拨请求
  3. 由渠道通过 PSTN 实现电话呼叫:
    3.1 呼叫 A 路(客服),A 路摘机
    3.2 呼叫 B 路(客户),客户摘机
    3.3 A-B 接通进行通话
    3.4 通话结束(A/B 挂断或异常)
  • 在此期间需要接收事件回调(玖云)或进行事件轮询(华为)并持久化通话状态,最终形成统一格式的通话记录
  • 回拨接口参数中可以带上业务实体标识,以便将通话记录和业务实体进行关联对应
  • 回拨接口的返回值中会返回一个 callId,用来表示该次回拨,以便将通话记录和业务实体进行关联对应
  • 在通话期间,应用可以使用 callId 来轮询 CC 查看通话状态

用户-坐席-渠道

这个模型用于描述业务系统中的用户实体以及坐席(可以理解为渠道提供的通话线路,同一时刻同一个线路只能有一通电话在拨打)的关联,并却定了这个用户所使用的通话渠道。

  • 对于玖云,坐席对应的是电话号码
  • 对于华为,坐席对应的是坐席号

默认情况下并不需要指定关联,CC 会自动选择渠道,只有在某些业务场景下需要应用来指定渠道。


以上都是我瞎扯的,实在编不下去了,欢迎大家分享真正的经验 :-p

PS:欢迎加入开源技术 Q 群 13139268,让学习和分享成为一种习惯!

  • 呼叫中心
    2 引用 • 21 回帖
  • CC
    4 引用 • 52 回帖
  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    139 引用 • 441 回帖
  • 程序员

    程序员是从事程序开发、程序维护的专业人员。

    528 引用 • 3527 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • kulou54

    透传是什么概念?就是吧电话号码显示给客服人员么?

  • 88250

    @kulou54 透传就是把主叫的号码给被叫,这个是正常的,因为符合来电显示的规则。另外有一种不大合规的就是透传成其他号码,这种情况运营商会控制比较严格。

  • kulou54

    @88250 哦原来是这样的。。现在很多电销的做法都是吧外拨的显示号码改为手机号码了。。。不过这个好像是运营商允许才能搞。。

  • 88250

    @kulou54 嗯,有的服务提供商能搞定当地运营商就能搞定这个特性

  • zonghua

    啊哈,原来你是做这个的

  • 88250

    @zonghua 我是半路出家的,需求是什么我就做什么 ....

  • R

    我们之前也搞过,都是运营商那边拉的专线,号码可以设置。
    另外,如果有营销外呼的话,要有个黑名单,有些客户接了电话后会让你不要再打了,要加入黑名单。不让业务员会被机经常被骂~

  • Chinese

    mark

  • mainlove

    还应该有拨打接通的弹屏需求

    哥以前就是开发这种平台的,可惜公司黄了

  • 88250

    @mainlove 如果是传统坐席的话弹屏交互,还有 TSS 都是需要的。要不来我厂干老本行么?

  • 我之前也做过这个,不过是呼叫系统的支持系统,我们用的是讯鸟

  • 714593351

    收藏一记!

  • 只能说看得懂,但是也不知道哪有问题。没经验~ 我是来看的。

  • mainlove 1

    @88250

  • flhuoshan

    google asterisk

  • 88250

    @flhuoshan 我们没有做软交换,实际通话都是由第三方服务商提供的

  • mainlove

    @flhuoshan freeswitch 好

  • c2y2

    opensips+ asterisk 哈哈 也可以搞 呼叫 呼叫

请输入回帖内容 ...