最近工作涉及到一些外呼系统的开发，正好借这个机会把外呼系统分类和原理梳理下，如果有不足或者错误之处欢迎大家指出来；
外呼系统的分类：
- 手动外呼
- 预览式外呼
- 预占式外呼
- 渐进式外呼
- 预测式外呼
- 自动外呼
手动外呼
这种模式的要点主要是名单分配。管理者把名单分配给座席（或业务员），业务员自己决定名单的拨打顺序。由业务系统记录呼叫结果和通话时间（拨打时间、接通结果、接通时间、挂断时间）。 系统一般难以获得接不通原因，需要业务员标注（忙线、拒接、停机、错号、欠费等等）。实现这种模式，不需要软交换和CTI做开发，不经过ACD分配任务，CTI也不统计外呼任务，座席状态一般设置为AUX-outbound，呼叫结束时没有ACW状态。
手动外呼直接在业务系统层面实现。但软交换应该尽量获得准确的呼叫结果码（1）（呼不通的原因码），反馈给软电话接口，传给业务系统记录。
这种模式座席的自由度最大。
手动外拨不需要专用的外拨平台支持。
核心业务逻辑在于名单分配、名单使用的跟踪、名单回收和再分配、
已知的SIP结果码： https://blog.csdn.net/kafeiwuzhuren/article/details/7242791 包括 603 拒接、404 Not Found ， BUSY 等。
预览式外呼
这种模式的特定是，通过服务器推送拨打任务到座席，座席预览之后确认外呼或放弃外呼，超时后，设置座席状态（Not Ready）回收任务。这里服务器主要作用是调度任务，以下称之为Scheduler。座席要做外呼任务，前提是要登录到ACD。 Scheduler通过ACD监控座席状态、推送消息（ 预测外呼也是按照技能来分配任务）。这里ACD是通用的按技能来分配任务（包括呼叫、IM、EMail，标准说法叫workItem）的机制。
每种外呼活动，都要定义一个独立的Skill。外呼活动通过Scheduler来调度任务。Scheduler通过一个名单管理机制来获取合格的名单。名单管理机制有一个或多个名单表。座席要参与外呼活动，必须先分配相关的技能。
Scheduler监控对应的技能组，这样可以得到所有相关座席的登录、登出、改变座席状态的事件。Scheduler也可以获得修改座席状态的权限（在座席超时回应时，踢出座席）。Scheduler在座席登录后，监控座席分机，监控座席拨打外呼任务的过程。
Scheduler根据座席拨打情况，可以按某些规则（可以扩展的策略），分配外呼任务。外呼任务有的有调度时间区间的要求（如此号码只能在9AM到10AM之间拨打），有的没有。Scheduler的不同外呼活动有开始结束的日志和每天的工作时间段（如9-12AM, 2-6PM）。
预览式外呼任务结束之后，ACD应该设置座席状态为ACW。座席要继续下一个任务，必须设置状态为Ready，触发Scheduler发起一次任务分配。（前端设计时，可以有个完成按钮，自动就绪触发分配）。Scheduler向ACD发送Preview外拨任务，ACD分配给空闲座席。外拨任务信息包括客户ID（或URL）、被叫号码、活动名称等。CTI记录有关Preview的呼叫类型（包括活动名称），完成呼叫模型，以及监控和报表统计。ACD依据呼叫类型设置座席的ACW。如果外呼没有成功，座席选择失败类型，Scheduler记录失败类型，依据外呼策略，重新调度。
预占式外呼
这种模式跟预览式类似，外呼活动通过Scheduler来调度任务时候，先预占坐席（通过将坐席状态改为预占），然后开始外呼名单，根据名单规则，找到接通的名单转移给呼叫，预占坐席一般先将坐席拨通，然后等名单接通再和坐席桥接；
预占式外呼需要检测外呼状态，要具有空号检测的功能；坐席挂断电话后进入ACW状态，座席要继续下一个任务，必须设置状态为Ready；Scheduler自动检测坐席状态，然后预占坐席，发起外呼，预占坐席可以提高坐席的外呼效率，同时也可以保证不存在呼叫呼入没有坐席接听的情况；
渐进式外呼
这种模式是一种简单的自动外呼模式。自动外呼都是有Dialer的模式。
渐进式也分为agent based 和 skill-based。前者直接分配到坐席，后者分配给技能组。
Agent-Based:
Scheduler监控每个座席的状态。当某个Agent空闲时，Scheduler获取一个名单，给Dialer生成一个外拨任务，通知Dialer去外拨。 Dialer把拨打最终结果通知Scheduler。最终结果包括接通和未接通，未接通的原因有：拒接、忙线、未接听、故障等等。如果未接通，Scheduler检查原因码，并按调度规则回收号码或者再次调度。 如果接通，Scheduler通知Dialer转接呼叫给agent。（scheduler内部存所有外拨任务和agent的map）。
这种模式下外呼过程不需要座席参与，只有接通的通话才会转接到Agent。和预览式不同，不会先给座席推送任务信息，需要座席的确认。
这是一种简单的基于座席状态的自动外呼。只有在座席Ready后，才会为座席发起外呼的任务。呼叫不通过ACD分配，但ACD要标记呼叫的类型信息（包括活动名称）。Dialer转接成功或失败，都要通知Scheduler。Scheduler应该有转接失败的处理策略。
Skill-Based:
和上述模式的不同在于，Scheduler监控技能组是否有空闲座席，如果有，生成一个外呼任务，发送给Dialer去拨号，Dialer拨通后，转接给ACD。
预测式外呼
就是带有预测能力的自动外呼模式。这种模式下，Scheduler按照监控的座席统计数据（座席数、平均通话时长、ACD时长、接听速度、接通率等等），通知Dialer发起一个或者多个外呼任务，根据Dailer反馈的接通结果或IVR按键信息，决定是否转接到座席或技能组。按监控和预测的对象不同，我把预测式又分为agent-based和skill-based。
Agent-base预测外呼：
和渐进式非常类似，只是统计单个座席的平均通话时长、整理时长和平均接听速度，提前一定量发起外呼。如果平均通话时长+整理时长=100s，呼叫和接听速度为10s，那么在座席接听90s后自动发起外呼任务。
这种模式只适合非常简单固定的外呼模式。 由于算法过于简单，一般来说，基于统计的预测，和设置一个经验值的效果难分高低。那么实际的实现，可以让客户自行为每个活动设定一个提前多少时间拨打的经验值。这个值要求在运行时，可以调整。
Skill-Based预测外呼
这种模式Scheduler监控和统计的范围包括了整个技能组的所有座席，呼叫任务的发起不是为某个座席而发起，而是预测技能组在未来n秒内，有m个可用座席，提前发起x个外呼任务。 外呼接通的呼叫会被转接的ACD。
实时统计的对象有两方面：1）平均座席通话时长+整理时长；可用座席数量； 2）外呼接通率；外呼平均接通速度；
预测的目的是，外呼任务和座席处理能力相匹配。既要避免座席多余空闲，也要避免过于疲劳，更要避免拨通后无法分配，对客户骚扰。（业界要求骚扰率小于3%，尽量减少出现ACD排队的机率）。 一般座席利用率应该80%左右，允许座席有一定空闲时间。
反馈修正机制：当座席空闲率太高或出现超拨形成骚扰时，应该及时调整参数，提高或降低呼叫速度。
边界条件： 各种参数的初始值设定。
算法：M/G/m/m 队列模型
工作时长 = 平均通话时长+平均整理时长（AHT+ACW）= t
可用座席数量 = m （不含AUX）
Pacing：调度预测步长：5 - 30s
综上，Skill-based的外呼，都是通过监控ACD的技能组来决定什么时候、生成几个外呼任务，给Dialer去拨打，拨打成功后，转接到技能队列去分配呼叫。
自动外呼
自动外呼是从2018年初才开始流行的一种外呼，主要是伴随着人工智能应用的兴起（TTS、ASR、文本机器人技术），对于自动外呼来说，最大的特点是无坐席干预，名单外呼后转给IVR，由IVR跟客户完成交互，从简单的按键交互到现在复杂的拟人交互，目前拟人交互主要有两种实现模式 1、手动编写语料库 （srgs 语法等） 2、对接文本机器人， 总体来说这种方式和之前的集中差别还是比较大的，技术难点也比较多，但是目前客户越来越接受这种外呼方式
最后总结下各个算法的优缺点（个人观点）
1、从系统复杂程度来说 手动 外呼 < 预览 < 预占 < 渐进 < 预测 < 自动外呼
2、从坐席利用率上来说（单纯的从呼叫中心角度来说）外呼 = 预览 < 预占 = 渐进 < 预测 < 自动外呼
3、各个系统有适合的场景，比如对外呼量不大，其实手动外呼、预览外呼比较合适了，如果客户比较重要，不希望出现接通客户后没有坐席处理的场景，可能预占、渐进都比较合适； 对于外呼名单比较多，对坐席的利用率高和名单处理速率 预测可能更合适；所以说根据不同业务场景可能不同的技术更合适。
4、在特定的场景下自动外呼的优势会很大，毕竟无坐席可以大大降低成本，而且极其没有情绪工作效率会很高，但是对于复杂的场景，可能目前还不能很好的支持。