业务系统如何通过API触发AI外呼？定时任务与结果回调流程

不接API，业务系统和外呼之间隔着一道"人手搬运"的墙

假设一个场景：某企业售后系统里有一个规则——"安装完成后第7天自动回访"。这条规则在系统里运行了三年，但执行方式始终是：每天早上管理员登录售后系统，导出"安装日期=7天前"的客户名单，另存为Excel。然后打开外呼平台，点击导入，选中刚才的Excel，等待校验完成。再手动选择话术模板，点击启动。外呼结束后，打开外呼平台的统计页面，导出通话结果Excel，回到售后系统，逐条更新客户回访状态。

这个流程中，售后系统"知道"该外呼谁，但它没有直接告诉外呼平台的能力；外呼平台"知道"通话结果，但它没有直接回写售后系统的能力。两套系统之间的数据流动，靠的是一个人每天做搬运工。

问题是，当外呼量从几十条增长到几百条、上千条时，搬运工的工作量线性增长，但准确率不会线性增长——漏传、错传、延迟传的概率会同时上升。而且，一些关键的业务场景被"搬运"卡住了：比如客户在安装后第3天主动来电取消了回访，但第7天的外呼名单已经在第6天导出了，系统不知道这个变化，仍然会拨出电话。

API接入要解决的就是这道墙。不是说"有了API就不需要人工了"，而是把"名单下载→导入→启动→导出→回写"这条手工链路，替换成"规则触发→API下发→自动执行→回调回写"的数据自动流动。

两条数据流：下发和回调

整个API触发的方案，可以拆成两条方向相反的数据流：

下发流（业务系统 → 外呼平台）：业务系统把外呼名单、话术变量、触发规则和回调地址打包成API请求，推送给平台。平台接收后，按规则调度外呼任务。

回调流（外呼平台 → 业务系统）：外呼结束后，平台把通话状态、结果标签、采集字段和通话摘要打包成回调数据，推送给业务系统。业务系统接收后，按规则更新状态、创建任务、触发后续动作。

两条流的关键设计原则是：下发流要"带齐上下文"，回调流要"给足结构化数据"。下面分别拆解。

下发流：业务系统需要传什么，平台怎么接收

名单不是"姓名+电话"，而是"身份+业务上下文+触发规则"

一条有质量的API下发记录，应该回答三个问题：这个人是谁、为什么要外呼他、什么时候打。

身份层。客户ID是业务系统和外呼平台之间关联数据的主键。这条ID在回调时要原样返回，这样业务系统才能把通话结果关联到正确的客户记录上。电话号码是外呼的执行对象，但在号码之外，客户姓名、会员等级、语言偏好等字段也需要一并传递，因为Agent在通话中需要用这些信息做个性化播报。

业务上下文层。这是人工外呼中坐席"看了订单再打电话"的环节，在API触发中需要变成字段传递。例如：订单号、产品型号、安装日期、服务类型、上次联系记录。这些字段在通话中会作为Agent的话术变量被播报和追问，也会作为Agent判断客户意向的参考依据。

触发规则层。除了"立即执行"，更常见的是按业务时间偏移触发。比如"安装日期+7天"而不是"2025年8月15日"，因为每台设备的安装日期都不同。这种规则需要业务系统在API请求中传递偏移量的计算基准字段（如install_date）和偏移天数（如+7），由平台在每条记录上独立计算触发时间。

这三层字段的完整性，直接决定了外呼Agent在通话中能说多少"有信息量的话"——如果只传了姓名和电话，Agent就只能说"您好，我是售后回访"；如果传了产品型号和安装日期，Agent就能说"您好，您上周安装的XX型号产品使用情况怎么样"。

API请求的核心结构

一个典型的API下发请求可以这样组织：

• 任务级参数：任务批次号（用于回调关联）、话术模板ID、全局回调URL、默认重试次数。

• 记录级参数：每条记录包含客户ID、电话号码、客户姓名、业务字段映射（订单号、产品型号、业务时间等）、本条记录的触发规则（可覆盖任务级默认值）、本条记录的回调URL（可覆盖任务级默认值）。

• 认证与格式：API Key或Token、请求格式（JSON）、字符编码。

合力亿捷MPaaS平台作为API网关，接收请求后做三件事：校验字段格式和鉴权、把任务写入调度队列、按触发规则发起外呼。如果单条记录校验失败（如号码格式错误），该条记录标记失败并立即回调告知业务系统，不影响同批次其他记录。

这里需要说明：API字段、鉴权方式和接口格式需要按项目实际对接条件确认。合力亿捷MPaaS提供API接入能力，但具体字段映射和权限控制取决于双方接口约定。

回调流：平台需要返回什么，业务系统怎么消费

回调数据结构不是"通话记录"，而是"业务系统可以编程消费的结构化数据"

一次外呼执行完毕后，平台向业务系统回调的数据，应该让业务系统不用再解析文本、不用再人工判断、不用再打开外呼平台查看详情。这意味着回调数据必须是结构化的，且每个字段都有明确的业务含义。

回调数据的核心字段：

业务系统收到回调后做什么

回调不是"通知你一声"，而是触发业务系统内部的后续动作链。典型场景：

• 高意向且客户要求回电 → 更新CRM状态为"待跟进"，创建销售任务，分配跟进人，设置跟进截止时间。

• 未接通且重试次数已达上限 → 自动触发短信通知，内容包含回电号码和业务说明。

• 客户表示不满或投诉 → 自动创建服务工单，标记优先级，通知客服主管。

• 客户确认预约/安装 → 更新订单状态，触发派单流程，通知安装团队。

• 客户表示"不需要再联系" → 更新客户订阅状态，加入免打扰名单，后续外呼任务自动跳过。

这些动作在传统人工外呼中靠坐席手动操作，在API触发方案中靠业务系统编程执行。回调数据的结构化程度越高，业务系统能自动完成的动作就越多。

回调失败怎么办

如果业务系统的回调地址不可用——返回5xx、超时、DNS解析失败——平台会按预设重试策略重新推送。重试策略通常包括重试间隔（如5分钟、15分钟、1小时）和最大重试次数（如3次）。如果全部重试失败，结果保留在平台侧，业务系统可以通过主动查询接口拉取未回调的结果。

这里有一个反直觉的设计建议：业务系统不应该假设回调永远不会失败，而应该同时支持"被动接收回调"和"主动拉取结果"两种模式。被动接收是常态，主动拉取是兜底。

三种触发模式：什么时候让外呼跑起来

API触发不等于"业务系统调一次API就立刻打一通电话"。实际业务中，触发模式通常有三种：

立即触发。 业务系统下发后，平台立即发起外呼。适合实时性要求高的场景，比如客户刚提交了售后申请，系统立即外呼确认信息。

定时触发。 业务系统指定一个绝对时间点，平台到点执行。适合固定时间窗口的场景，比如每天上午10点执行前一天的回访任务。

偏移触发。 业务系统指定一个业务时间字段和一个偏移量，平台为每条记录独立计算触发时间。这最接近真实业务需求——"安装后7天回访"中，每条记录的7天基准不同，100条记录可能分散在100个不同的触发时间点。合力亿捷MPaaS平台的调度引擎支持这种按记录和时间偏移的触发方式，而不是把100条记录绑在同一个时间点一下子打出去。

三种模式可以混合使用：同一个任务中，大部分记录按偏移触发，少数紧急记录标记为立即触发。

系统协同中的角色分工

把整条链路拆成三个角色的分工，比笼统地说"系统对接"更清晰：

合力亿捷在这条链路中的角色分布在平台层和通信层：MPaaS作为API网关和任务调度引擎，承接业务系统的下发请求并编排外呼流程；Synerow通话Agent和呼叫中心执行实际外呼和对话；通话结果通过MPaaS的回调能力推回业务系统。三方各司其职，数据在API层面按约定格式流动。

边界与兜底

API接口边界。 本文描述的链路是通用架构参考，不是具体接口文档。API字段、鉴权、限流和回调格式需按项目实际对接条件确认。

外呼类型边界。 API触发适用于服务型外呼——售后回访、预约确认、满意度调研、政策通知、信息核实。API下发的每条外呼记录，都应能在业务系统中追溯到明确的业务触发原因。

数据一致性边界。 业务系统名单更新和平台外呼执行之间存在时间差。如果业务系统在名单下发后、外呼执行前更新了客户状态（如客户取消订单），已下发的名单不会自动撤回。需要在前端配置免打扰名单或外呼前状态校验来兜底。

短信/通知联动。 如果业务系统在回调处理中需要触发短信通知，短信通道、模板审核、短链接、手机号授权、发送接口和到达统计需要实施确认。这不是"回调后自动发短信"的默认能力，而是需要短信通道和业务系统联动。

评估建议。 在启动API对接前，建议先确认：业务系统是否有可用的API开发资源？外呼名单的生成规则是否明确？最需要回调驱动的后续动作是什么？能否接受分钟级的数据延迟？回调失败时人工兜底方案是什么？

合力亿捷在这条链路中的角色，不是提供一套API文档就结束，而是把API接入、任务调度、外呼执行、结果回调和运营监控连成闭环。先从一个业务场景跑通下发和回调的完整链路，验证字段映射、回调稳定性和业务系统联动逻辑，再用真实运行数据优化触发规则和重试策略——这比一开始就对接所有业务场景，更接近系统集成的真实落地节奏。