呼叫中心推送产品

面向客户、业务、实施与技术协同的统一说明文档

快速阅读

如果您时间有限，建议先看这 5 部分：

1. 二、产品定义与定位：快速理解“推送”是什么
2. 四、产品能力地图：快速看懂推送产品能做什么
3. 五、推送业务主流程：快速看懂配置和执行怎么串起来
4. 六、典型推送场景说明：快速判断是否适合自己的业务
5. 十一、预期收益：快速评估建设价值

阅读地图

这份文档兼顾客户沟通、方案说明、实施落地和技术协同。不同角色可按下面的方式阅读：

1. 管理层 / 决策层

建议重点看：

• 二、产品定义与定位
• 三、建设背景与核心价值
• 五、推送业务主流程
• 十一、预期收益
• 十四、结论

2. 业务负责人 / 运营负责人

建议重点看：

• 四、产品能力地图
• 六、典型推送场景说明
• 七、具体产品功能说明
• 八、适用行业与适用边界
• 九、建设原则

3. 项目经理 / 实施顾问

建议重点看：

• 五、推送业务主流程
• 七、具体产品功能说明
• 十、上线前准备与上线后运营
• 十三、实施与系统实现说明
• 附录 A：推送类型清单、参数类型与示例

4. 技术负责人 / 对接负责人

建议重点看：

• 七、具体产品功能说明
• 十、上线前准备与上线后运营
• 十三、实施与系统实现说明
• 附录 A：推送类型清单、参数类型与示例

一、文档说明

本文档用于统一说明呼叫中心“推送”产品的定位、能力、配置方式、执行逻辑、典型场景及落地方式。

本文档重点回答四个问题：

1. 推送产品在呼叫中心中解决什么问题
2. 推送产品如何把电话、座席、话单、录音、转写等事件发送到企业自己的系统
3. SaaS 管理端如何配置推送，PaaS 运行端如何执行推送
4. 企业上线推送能力前后，需要如何规划、建设与运营

二、产品定义与定位

在呼叫中心中，“推送”可以理解为：系统在关键事件发生时，把相关数据自动发送到企业指定系统或前端界面。

这些关键事件可能包括：

• 来电进入
• 座席响铃
• 通话接通
• 通话挂机
• 话单生成
• 录音完成
• 转写完成
• 座席状态变化
• 满意度调查结束
• IVR 交互结束

简单理解：

• 电话系统知道发生了什么
• 推送系统决定“要不要发、发给谁、发什么、失败后怎么办”
• 企业自己的 CRM / 工单 / BI / 外部平台收到消息后继续处理

如果用一句话概括：

推送产品，就是呼叫中心和外部系统之间的自动同步能力。

从产品定位看，推送能力是呼叫中心的“对外连接层”与“系统联动层”。

它的角色可以概括为四个方面：

• 事件出口：把呼叫中心内发生的关键事件输出到外部
• 系统桥梁：连接 CRM、工单、订单、录音、AI、短信等业务系统
• 自动触发器：让很多动作不再依赖人工手动同步
• 运营闭环支点：通过日志、重推、统计，保证推送结果可追踪、可补偿、可优化

三、建设背景与核心价值

当企业的呼叫中心与外部系统越来越多地联动时，如果没有统一的推送能力，通常会遇到以下问题：

• 电话事件发生后，业务系统拿不到实时信息
• 座席需要手动复制或登记通话结果
• CRM、工单、报表、录音系统彼此割裂
• 非实时同步导致客户弹屏、工单创建、状态更新不及时
• 推送失败后难以追查、难以补发
• 不同类型事件分散配置，维护复杂

因此，推送产品的核心价值主要体现在四个方面：

• 实时联动：电话事件发生后，外部系统可以第一时间收到通知
• 减少人工同步：把原本依赖人工操作的同步动作自动化
• 支撑业务闭环：从来电到通话、从话单到录音、从转写到分析，都能串起来
• 提升可控性：通过日志、重试、重推和开关控制，保证推送可靠可管理

从业务上看，企业最直接感受到的变化通常是：

• 关键事件会更快进入业务系统
• 人工同步动作会明显减少
• 推送失败时能查到原因，也能补发

四、产品能力地图

从业务和产品角度看，推送能力可以拆成六类。

1. 推送对象管理

决定“发到哪里去”。

核心内容：

• 目标接口名称
• 目标 URL
• 请求方式（GET / POST）
• 内容类型（表单 / JSON）
• 超时时间

也可以理解为：先把“接收方”建好。

2. 推送动作管理

决定“什么事件发生时发、发什么内容、是否启用”。

核心内容：

• 推送类型
• 启用状态
• 目标接口
• 推送参数
• 条件规则
• 重试策略
• 延迟推送
• 是否同时推送到座席前端

也可以理解为：把“发送规则”建好。

3. 事件推送能力

决定“系统里哪些事件可以被推送出去”。

常见事件包括：

• 来电类事件
• 外呼类事件
• SIP 接入事件
• 座席状态事件
• 录音状态事件
• 话单事件
• 转写与分析结果事件
• 满意度、按键、IVR 结束等业务事件

也可以理解为：明确“哪些时刻需要发消息”。

4. 数据加工与安全控制

决定“推送出去的数据长什么样，是否要做安全处理”。

核心内容：

• 参数映射
• 变量取值
• 数据加工脚本
• 加密规则
• 挂机推送变量
• 条件过滤

也可以理解为：把“要发的数据”整理成对方系统能直接使用的格式。

5. 可靠性保障能力

决定“推送失败后怎么办”。

核心内容：

• 同步 / 异步推送
• 重试次数
• 重试间隔
• 延迟推送
• 企业级兜底重推开关
• 推送日志
• 批量重推

也可以理解为：保证“发得出去，也补得回来”。

6. 运营与审计能力

决定“推送配置和推送结果是否可查、可审、可导出”。

核心内容：

• 推送日志查询
• 日志导出
• 当前页重推 / 全量重推
• 配置导入导出
• 类型分组查看

也可以理解为：让推送能力真正能长期运营，而不是一次性配置。

五、推送业务主流程

一个典型的推送业务流程可以概括为：

业务人员在 SaaS 管理端配置推送
│
├── 配置目标接口
├── 配置推送动作
├── 选择推送类型
├── 配置参数与条件
├── 配置重试和延迟
└── 启用推送
│
▼
呼叫中心运行时发生事件
│
├── 来电
├── 外呼
├── 通话接通
├── 通话挂机
├── 话单生成
├── 录音完成
├── 转写完成
└── 座席状态变化
│
▼
PaaS 推送引擎判断
├── 是否有匹配的推送动作
├── 是否满足条件
├── 是否需要加工或加密
├── 是否同步 / 异步
└── 是否延迟发送
│
▼
发送到企业目标系统
├── CRM
├── 工单系统
├── 订单系统
├── BI / 数据平台
├── 录音或转写平台
└── 自有业务系统
│
▼
写入推送日志
├── 成功
├── 失败
└── 支持重推

用最直白的话说：

先配规则，再等事件发生；事件一发生，系统自动把数据按规则发出去；如果失败，还能查日志和补发。

如果从建设顺序理解，也可以分成三步：

1. 先配置“发给谁”
2. 再配置“什么事件发什么数据”
3. 最后通过日志和重推保障可靠性

六、典型推送场景说明

场景一：来电实时推送到 CRM

适用于希望在客户来电时，CRM 或客服工作台第一时间弹出客户信息的场景。

客户来电
│
▼
呼叫中心产生来电事件
│
▼
推送系统把来电信息发送到 CRM
│
▼
CRM 弹出客户资料 / 历史记录 / 跟进信息

价值：

• 座席无需手动搜索客户
• 提高首呼处理效率
• 减少座席准备时间

场景二：挂机后自动推送话单

适用于需要在通话结束后自动沉淀通话结果的场景。

通话结束
│
▼
生成主话单 / 从话单
│
▼
推送系统发送话单数据
│
▼
CRM / 工单 / 报表系统接收

价值：

• 自动同步通话结果
• 降低人工登记成本
• 便于后续统计和追溯

场景三：录音完成后推送录音地址

适用于企业需要把录音结果同步给外部质检、存档或业务系统的场景。

录音完成
│
▼
系统生成录音文件地址
│
▼
推送录音状态 + 录音访问地址
│
▼
外部质检 / 存档 / 业务平台接收

价值：

• 录音可快速进入后续处理流程
• 便于质检和合规管理
• 减少人工传递录音文件的工作

场景四：转写或分析结果推送

适用于希望把 ASR / RASR / 智能分析结果同步到业务系统的场景。

通话录音 / 实时对话完成转写
│
▼
生成文本或分析结果
│
▼
推送到外部系统
│
▼
用于质检、摘要、标签、AI 分析或后续业务处理

价值：

• 把语音数据快速变成可用业务数据
• 支撑质检、分析、智能体等后续能力
• 提升语音数据利用效率

场景五：座席状态推送

适用于需要把座席登录、置忙、通话、整理等状态同步到第三方系统的场景。

座席状态变化
│
▼
系统产生状态事件
│
▼
推送到外部管理系统

价值：

• 第三方平台实时掌握座席状态
• 便于统一监控和资源调度
• 支撑更复杂的多系统协同

场景六：推送失败后的日志与重推

适用于对可靠性要求高的企业场景。

事件触发推送
│
▼
推送失败
│
▼
记录日志
│
├── 查询失败原因
├── 重推当前页
└── 重推全部

价值：

• 推送失败可追踪
• 推送结果可补偿
• 保障业务同步的完整性

七、具体产品功能说明

为了让客户在理解业务价值的同时，也能了解产品本身由哪些能力组成，下面对呼叫中心推送中最常见的具体功能做简要说明。

为了便于理解，也可以把这些功能看成三个层级：

• 基础能力：先把推送配置好、发出去、查得到
• 增值能力：让推送更灵活、更可靠、更贴近业务
• 智能协同能力：让推送与更复杂的系统处理和智能流程结合

一、基础能力

这部分能力适合绝大多数呼叫中心优先建设，是推送产品最先落地的一层。

1. 目标接口

目标接口决定“数据发到哪里”。

可配置内容包括：

• 接口名称
• 请求 URL
• 请求方式（GET / POST）
• 内容格式（表单 / JSON）
• 超时时间

典型用途：

• 对接 CRM 回调地址
• 对接工单系统入口
• 对接自有业务平台接口

从配置角度看，这是推送产品的第一步。

2. 推送动作

推送动作决定“什么事件触发推送”。

可配置内容包括：

• 推送名称
• 推送类型
• 目标接口
• 启用状态

典型用途：

• 建一条“来电推送”
• 建一条“挂机话单推送”
• 建一条“录音状态推送”

从产品角度看，推送动作是整套推送能力的核心配置对象。

3. 推送日志

推送日志用于查看“有没有发成功，失败原因是什么”。

常见用途：

• 查询成功 / 失败记录
• 按时间、类型、URL、重试次数筛选
• 排查推送异常

这是实施和运营阶段最常使用的功能之一。

4. 批量重推

当推送失败或外部系统短时不可用时，可通过日志页面进行补发。

常见用途：

• 重推当前页
• 重推全部
• 对失败推送做补偿处理

它解决的是“偶发失败后如何快速恢复”。

二、增值能力

这部分能力帮助企业把推送做得更细、更稳、更贴合业务，通常会在基础能力稳定后逐步建设。

5. 推送类型分组

推送产品支持按业务类型分组查看和配置，不需要把所有推送混在一起。

常见分组包括：

• 来电推送
• 外呼推送
• SIP 接入推送
• 座席状态推送
• 录音状态推送
• 话单推送
• 转写结果推送
• 其他业务推送

这样做的好处是，业务人员更容易找到自己要配置的类型。

6. 条件推送

并不是每个事件都必须推送。系统支持根据条件判断是否推送。

常见用途：

• 只有 VIP 客户才推送
• 只有某个热线号码才推送
• 只有满足特定结果才推送

这项能力适合有精细化运营要求的企业。

7. 推送参数映射

推送出去的数据，不一定原样照搬系统字段，可以重新组织成更适合外部系统接收的格式。

常见用途：

• 把内部字段名转换为外部系统字段名
• 指定哪些变量需要推送
• 统一参数命名

这项能力决定了推送产品是否容易与第三方系统对接。

8. 数据加工脚本

在正式推送前，系统支持对数据做加工处理。

常见用途：

• 补充自定义字段
• 按规则拼装文本
• 生成适合业务系统接收的结构

9. 加密规则

对于敏感数据，系统支持在推送前进行加密或脱敏。

常见用途：

• 电话号码脱敏
• 特定字段加密
• 按规则处理隐私信息

这项能力通常在金融、政务、医疗等行业更重要。

10. 延迟推送

有些场景不需要实时秒发，而需要等待几秒后再发。

常见用途：

• 等待数据完整后再推送
• 避免过早触发下游系统

11. 重试策略

当推送失败时，系统可按策略自动重试。

常见用途：

• 网络抖动时自动补发
• 外部系统短时不可用时继续重试

12. 企业级兜底重推开关

系统支持企业级配置“是否开启兜底重推”。

常见用途：

• 统一开启推送补偿策略
• 降低关键业务推送丢失风险

三、智能协同能力

这部分能力适合希望把推送与更复杂的数据处理、语音分析、智能服务串起来的企业。

13. 转写结果推送

把离线转写（ASR）、实时转写（RASR）或智能体文本结果同步到外部系统。

常见用途：

• 发送转写文本到质检系统
• 发送实时文本到智能分析平台

14. 录音与语音结果推送

把录音状态、录音地址、双声道录音地址等信息推送给下游。

常见用途：

• 推送录音给质检平台
• 推送录音结果给合规存档系统

15. 话单轨迹与业务闭环推送

把主话单、从话单、满意度、IVR 交互结束等数据推送出去，形成完整业务闭环。

常见用途：

• 通话结束后更新客户服务记录
• 满意度结束后回写业务系统
• IVR 结束后做下游业务触发

如果用最直白的方式来区分这三层：

• 基础能力：先把推送建起来、发出去、查得到
• 增值能力：让推送更稳、更细、更贴近业务
• 智能协同能力：让推送和录音、转写、分析、AI 服务串起来

八、适用行业与适用边界

适用行业

推送产品特别适合以下类型的呼叫中心：

• 电商客服中心
• 金融客户服务中心
• 物流查件中心
• 医疗预约中心
• 物业服务中心
• 政务服务热线
• 教育咨询热线
• 企业售后服务中心

这些行业通常具备以下共同特征：

• 需要和 CRM、工单、订单、报表等系统联动
• 电话事件发生后，需要外部系统实时感知
• 对服务闭环和数据沉淀要求较高

适合的场景

• 希望把来电、挂机、话单等事件同步给外部系统
• 希望把录音、转写、分析结果自动同步
• 希望减少人工登记和人工同步
• 希望通过日志和重推提高可靠性

不建议过度依赖推送的场景

• 外部系统接口不稳定且没有重试或补偿策略
• 业务完全不依赖实时联动
• 对外部系统字段和数据规则没有明确约定

简单说：

• 适合：需要实时联动、自动同步、可追踪补偿的场景
• 不适合：业务没有联动需求，或外部系统完全不具备接收能力的场景

九、建设原则

为了保证推送产品的实际效果，建议遵循以下原则：

• 先明确推送目标：先想清楚“为什么推、推给谁、推了之后谁来用”
• 先做关键事件：优先上线来电、挂机、话单、录音等价值最高的推送
• 参数尽量统一：减少不同系统间的字段理解偏差
• 推送必须可追踪：日志、重推、失败排查要一起建设
• 安全优先：对敏感字段做好脱敏与加密控制

十、上线前准备与上线后运营

上线前准备

企业在建设推送能力前，通常需要确认以下事项：

• 哪些事件要推送
• 推送给哪些系统
• 接口地址、方式、认证方式是什么
• 需要哪些字段
• 哪些字段要脱敏或加密
• 失败后要不要自动重试

如果从项目启动角度看，企业至少要先回答 4 个问题：

1. 什么事件必须实时同步
2. 哪些系统要接收这些数据
3. 数据字段和安全规则怎么约定
4. 推送失败后谁来处理、如何补偿

如果这四个问题没有先确认清楚，后续联调和上线通常都会反复返工。

上线后运营

推送能力上线后，也需要持续运营和观察：

• 业务运营侧：关注哪些推送真正被业务使用
• 实施或管理员侧：维护目标接口、推送动作、参数和日志
• 技术支持侧：处理接口联调、异常排查和复杂数据加工

也就是说，推送产品不是“配完就结束”，而是一个需要持续维护的协同能力。

十一、预期收益

企业建设推送能力后，通常可在以下方向获得收益：

• 效率收益：减少人工同步，缩短业务系统拿到数据的时间
• 协同收益：让 CRM、工单、录音、转写、AI 等系统形成联动
• 可靠性收益：通过日志、重推和补偿机制降低数据丢失风险
• 管理收益：推送规则统一配置、统一维护、统一追踪

如果用最直白的方式总结，企业通常最容易感受到的是三件事：

• 关键数据会自动到达该去的系统
• 人工少做很多重复同步工作
• 推送失败时能查得到、补得回

从管理视角看，推送产品最大的意义是把“系统之间靠人工传递信息”升级为“系统之间自动同步信息”。

十二、常见问题

Q1：推送产品和普通接口回调有什么区别？

普通接口回调通常是一条一条临时接入；推送产品是统一管理多类事件、多目标接口、多参数规则和重试补偿的体系化能力。

Q2：是否必须实时推送？

不一定。系统既支持实时推送，也支持延迟推送，还支持同步和异步两种方式。

Q3：是否可以只推送部分字段？

可以。推送参数可以按业务需要进行筛选、映射和组织。

Q4：是否支持敏感字段保护？

支持。系统提供加密规则和字段控制能力，可用于脱敏或加密处理。

Q5：推送失败后怎么办？

系统支持日志查询、自动重试、企业级兜底开关以及人工批量重推。

Q6：是否可以同时推送到外部系统和座席前端？

可以。部分推送动作支持“不推送 / 仅推座席端 / 同时推送外部系统与座席端”三种模式。

Q7：是否支持录音、转写、话单等不同类型数据？

支持。推送类型覆盖来电、外呼、状态、话单、录音、转写、满意度等多类事件。

Q8：配置推送是否一定要开发参与？

不一定。大部分目标接口、推送动作、参数和重推策略可以由运营或实施通过配置完成。涉及外部系统联调、复杂加工或安全要求时，通常需要技术参与。

十三、实施与系统实现说明

前面的内容主要面向客户、业务负责人和售前沟通。以下内容在不进入源码细节的前提下，补充说明推送能力在前端 SaaS 配置、后端 PaaS 执行、日志补偿和系统协同中的实现逻辑，便于项目经理、实施顾问、技术负责人统一理解。

1. 系统整体组成

从实现角度看，推送产品不是一个单一页面，而是一套“前端配置 + 后端执行 + 日志记录 + 重推补偿”的完整系统。

SaaS 管理端
├── 目标接口管理
├── 推送动作管理
├── 重推开关
├── 参数与条件配置
└── 推送日志查询
│
▼
PaaS 运行端
├── 来电/外呼事件
├── 话单事件
├── 录音事件
├── 转写事件
├── 状态事件
└── 智能分析事件
│
▼
推送引擎
├── 匹配推送动作
├── 判断条件
├── 组装参数
├── 安全处理
├── 同步/异步发送
└── 日志记录与补偿

2. SaaS 管理端主要负责什么

从系统实现上看，SaaS 侧主要承载的是“配置”和“管理”能力。

主要入口包括：

• 推送目标接口配置
• 推送动作管理
• 传统 HTTP 推送配置
• 推送日志查询与重推页面

业务人员或实施人员主要通过 SaaS 完成这些动作：

1. 创建目标接口
2. 创建推送动作
3. 选择推送类型
4. 配置参数、条件、加密、脚本和重试
5. 启停推送
6. 查询日志并重推

3. PaaS 运行端主要负责什么

PaaS 侧主要负责“事件发生时，真正把推送跑起来”。

运行逻辑大致如下：

业务事件发生
│
▼
按事件类型查找匹配的推送动作
│
▼
判断动作是否启用、条件是否满足
│
▼
组装推送数据
│
▼
按同步/异步/延迟/重试策略发送
│
▼
记录推送日志

4. 推送产品中的三个核心对象

从配置角度看，推送产品主要围绕三个对象展开：

4.1 推送目标接口

回答“发到哪里去”。

关键属性包括：

• 名称
• URL
• GET / POST
• 表单 / JSON
• 超时时间

4.2 推送动作

回答“什么时候发、发什么、怎么发”。

关键属性包括：

• 推送类型
• 推送名称
• 启用状态
• 目标接口
• 参数列表
• 条件规则
• 重试策略
• 延迟策略
• 是否推送到座席端

4.3 推送日志

回答“发成功没有，失败了怎么办”。

关键能力包括：

• 列表查询
• 条件筛选
• 导出
• 当前页重推
• 全量重推

5. 推送类型是如何组织的

从代码实现上看，推送类型不是散乱配置，而是按业务分组组织的。

常见分组包括：

• 来电组：来电到达、来电响铃、来电接通、来电挂机、排队日志等
• 外呼组：预览外呼、主叫外呼、预测外呼、WebCall 等
• SIP 接入组：SIP 来电、响铃、接通等
• 状态组：座席状态、号码状态、录音状态等
• 转写 / 分析组：ASR、RASR、智能分析、智能体文本等
• 话单组：主话单、从话单、话单明细等
• 其他业务组：按键、满意度、IVR 交互结束等

这样做的好处是：

• 前台配置更清晰
• 业务人员更容易理解
• 实施时更容易分阶段上线

6. 推送是如何保证可靠性的

从代码逻辑上看，推送产品并不是“发一次就算了”，而是带有明显的可靠性设计：

• 支持同步推送与异步推送
• 支持延迟推送
• 支持重试次数与间隔配置
• 支持企业级重推开关
• 支持日志查询和人工重推
• 支持当前页 / 全量重推

也就是说，推送产品不是单纯的“调用一次 HTTP 接口”，而是包含了完整的补偿机制。

7. 数据是如何被组装后推送出去的

在运行时，系统并不是原样把内部事件直接扔给外部系统，而是会先做一层数据组装。

这一层通常包括：

• 从事件中提取标准字段
• 根据推送动作选择需要的参数
• 处理字段映射
• 执行脚本加工
• 按规则加密或脱敏
• 生成最终的请求体或请求参数

这也是为什么同一个事件，可以同时满足不同系统的不同接收要求。

8. 话单、录音、转写推送是怎么衔接的

在运行中，推送最典型的三类深度数据是：

8.1 话单推送

通话结束后生成主话单或从话单，再按配置推送到外部系统。

8.2 录音状态推送

录音完成后，系统会生成录音地址、预签名 URL、双声道地址等，再推送给下游系统。

8.3 转写或分析结果推送

当 ASR、RASR 或智能分析结果产生后，系统会继续把文本或分析结果推送到外部系统。

这三类推送一起，能够把“通话结果、录音结果、文本结果”完整串起来。

9. 日志页面在产品中的作用

前端日志页面不是辅助工具，而是推送产品中非常重要的一环。

它承担三类职责：

• 排查：看某次推送是否成功、失败原因是什么
• 补偿：对失败推送进行人工重推
• 审计：查看一段时间内的推送执行情况

当前前端日志页支持的典型能力包括：

• 按时间查询
• 按结果查询
• 按 URL 查询
• 按推送类型查询
• 导出当前页或全部日志
• 重推当前页或全部日志

10. 项目实施时通常怎么落地

如果从项目角度看，推送能力的落地通常按以下顺序推进：

确认业务同步目标
│
▼
梳理要推送的事件
│
▼
确认接收系统和接口能力
│
▼
设计推送字段和规则
│
▼
配置目标接口和推送动作
│
▼
联调与试推送
│
▼
上线观察日志
│
▼
根据失败情况优化重试与补偿策略

常见实施分工如下：

• 业务方：确认哪些事件要同步、同步给谁、同步后做什么
• 实施方：完成推送配置、联调、日志验证和上线支持
• 技术方：提供外部接口、处理复杂字段、脚本、安全和异常补偿

11. 这一部分应该怎么读

如果您是不同角色，建议重点关注：

• 客户管理层：看前半部分的价值、场景、收益
• 业务负责人：看能力地图、功能说明、上线准备
• 项目经理 / 实施顾问：重点看本章的系统组成、三个核心对象、实施落地
• 技术负责人：重点看 PaaS 执行、数据组装、日志补偿以及与技术版文档的对应关系

十四、结论

从呼叫中心产品建设视角看，推送能力是连接呼叫中心与外部系统的关键产品能力。

它的价值不只是“把数据发出去”，而是把电话事件、话单、录音、转写、状态变化等关键业务结果，稳定、可控、可追踪地送到正确的系统中。

对任何希望建设更高协同效率、更低人工同步成本、更完整业务闭环的呼叫中心而言，推送能力都是非常重要的基础能力之一。

以下内容作为实施、联调与对接参考附录使用。

附录 A：推送类型清单、参数类型与示例

为了便于业务方、实施方和对接方快速理解“每类推送到底发什么”，本章补充说明：

• 每个推送类型的业务含义
• 建议推送参数
• 常见参数类型
• 接收方返回示例

需要特别说明的是：

1. 推送产品支持自定义参数映射，因此实际推送字段可按企业配置调整
2. 下表中的参数是推荐参数/常见参数，用于帮助理解和对接
3. 返回示例为建议接收方返回格式，便于双方联调和问题排查

A.1 参数类型说明

推送产品支持的参数类型主要包括以下几类：

简单理解：

• 变量 负责“从系统里拿值”
• param/header/body 负责“放到 HTTP 请求的哪个位置”
• body(覆盖) 负责“按外部系统要求重新组织整个请求体”

A.2 推送实施参考维度

在实际项目中，除了“推什么内容”，实施和对接方通常还会关注以下四个维度：

• 触发时机：什么业务动作发生时触发
• 实时性建议：建议实时发送，还是可延迟发送
• 是否支持重试：是否建议配置自动重试或人工补偿
• 推荐接收系统：哪些系统最适合接收这类消息

需要说明：

1. 大多数推送类型都支持配置重试，但是否启用、重试几次、间隔多久，可由企业按业务要求决定
2. “实时 / 准实时 / 可延迟”属于实施建议，不代表固定系统限制
3. 推荐接收系统是常见实践，不是唯一接收方

来电推送组

外呼推送组

SIP 接入组

状态推送组

转写 / 分析组

其他业务组

A.3 建议接收方返回示例

推送是呼叫中心主动向外部系统发消息，因此这里的“返回示例”指的是接收方接口建议返回内容。

成功返回示例

{
"code": 0,
"message": "success"
}

失败返回示例

{
"code": 500,
"message": "invalid parameter"
}

建议：

• 成功时返回 HTTP 200
• 返回体尽量简单明确，便于日志排查
• 如有业务失败原因，建议写入 message

A.4 来电推送类型

A.5 外呼推送类型

A.6 SIP 接入推送类型

A.7 状态推送类型

A.8 转写 / 分析推送类型

A.9 其他业务推送类型

A.10 推送参数示例

下面给出一个更接近实际项目的“完整请求示例包”，便于实施、对接和联调时参考。

需要说明：

1. 下面示例默认采用 POST + application/json
2. 实际项目中也可以配置为 GET、表单或带 header
3. 示例字段以“常见字段”为主，实际仍以企业配置为准

示例一：来电到达推送

适用类型：

• 来电到达推送
• 来电响铃推送
• 来电接通推送

{
"event": "incoming",
"enterpriseId": 1001,
"uniqueId": "1699999999.123",
"mainUniqueId": "1699999999.123",
"hotline": "4008008888",
"customerNumber": "13800138000",
"customerAreaCode": "010",
"callType": "ib",
"cno": "8001",
"eventTime": "2026-03-11 10:20:30"
}

示例二：来电挂机推送

适用类型：

• 来电挂机推送
• 来电转移接通推送
• 来电咨询接通推送

{
"event": "hangup_ib",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"hotline": "4008008888",
"customerNumber": "13800138000",
"cno": "8001",
"bridgeTime": "2026-03-11 10:21:01",
"hangupTime": "2026-03-11 10:24:07",
"duration": 186,
"endReason": "customer_hangup",
"queueQno": "9001"
}

示例三：主话单推送

适用类型：

• 主通话记录推送

{
"event": "master_cdr",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"cno": "8001",
"customerNumber": "13800138000",
"callType": "ib",
"startTime": "2026-03-11 10:20:30",
"bridgeTime": "2026-03-11 10:21:01",
"hangupTime": "2026-03-11 10:24:07",
"duration": 186,
"cdrStatus": "success",
"endReason": "customer_hangup",
"hotline": "4008008888"
}

示例四：从话单推送

适用类型：

• 从通话记录推送

{
"event": "slave_cdr",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.456",
"cno": "8001",
"customerNumber": "13800138000",
"calledNumber": "02188886666",
"callType": "ob",
"duration": 52,
"cdrStatus": "success",
"sipCause": 16
}

示例五：录音状态推送

适用类型：

• 录音状态推送

{
"event": "record_status",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"recordFileStatus": 1,
"recordFileIndex": "20260311/1699999999.123.wav",
"recordDuration": 186,
"preSignUrl": "https://example.com/record/xxx",
"preSignWavUrl": "https://example.com/record/xxx-stereo",
"preSignClientUrl": "https://example.com/record/xxx-client",
"preSignAgentUrl": "https://example.com/record/xxx-agent"
}

示例六：实时转写推送

适用类型：

• 实时转写（RASR）结果推送
• 智能体对话文本推送

{
"event": "rasr",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"speaker": "customer",
"content": "我要查询订单状态",
"eventTime": "2026-03-11 10:21:18",
"sentenceIndex": 12
}

示例七：离线转写结果推送

适用类型：

• 离线转写（ASR）结果推送
• 对话分析结果推送

{
"event": "asr_result",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"recordFile": "20260311/1699999999.123.wav",
"asrText": "客户咨询订单发货时间，座席已答复",
"analysisResult": "物流咨询",
"score": 87
}

示例八：座席状态推送

适用类型：

• 座席状态变更推送

{
"event": "agent_status",
"enterpriseId": 1001,
"cno": "8001",
"status": "pause",
"statusDesc": "置忙",
"statusTime": "2026-03-11 10:35:20"
}

示例九：满意度结果推送

适用类型：

• 满意度调查结果推送

{
"event": "investigation",
"enterpriseId": 1001,
"mainUniqueId": "1699999999.123",
"uniqueId": "1699999999.123",
"customerNumber": "13800138000",
"score": 5,
"option": "非常满意",
"eventTime": "2026-03-11 10:24:30"
}

示例十：GET 方式推送示例

适用场景：

• 外部系统仅支持 query 参数接收
• 推送字段较少

GET /push/incoming?enterpriseId=1001&uniqueId=1699999999.123&customerNumber=13800138000&hotline=4008008888

示例十一：带 Header 的推送示例

适用场景：

• 外部系统要求鉴权
• 需要传业务签名或租户标识

POST /third-party/receive/push HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer xxxxx
X-Enterprise-Id: 1001

{
"event": "master_cdr",
"mainUniqueId": "1699999999.123",
"customerNumber": "13800138000",
"duration": 186
}

示例十二：form 表单方式推送示例

适用场景：

• 外部系统使用传统表单接口

enterpriseId=1001
&event=incoming
&uniqueId=1699999999.123
&customerNumber=13800138000
&hotline=4008008888

核心字段说明

下面补充几个最常见推送示例的字段说明小表，便于实施和对接时快速理解字段含义。

A. 来电类推送字段说明

B. 话单类推送字段说明

C. 录音类推送字段说明

D. 转写 / 分析类推送字段说明

E. 座席状态类推送字段说明

推荐配置模板

下面给出几类最常见场景的“推荐配置模板”，方便实施人员快速起步。

模板一：来电弹屏推送模板

适用场景：

• 来电时需要 CRM 立即弹屏
• 业务侧希望第一时间拿到客户来电信息

推荐配置：

模板二：挂机后同步话单模板

适用场景：

• 通话结束后同步 CRM / 工单 / BI
• 需要沉淀主话单或从话单结果

推荐配置：

模板三：录音状态推送模板

适用场景：

• 录音完成后需要同步给质检、合规或存档平台

推荐配置：

模板四：实时转写推送模板

适用场景：

• 需要把通话中的实时文本同步给外部系统
• 需要做实时辅助、实时分析

推荐配置：

模板五：离线转写 / 分析结果推送模板

适用场景：

• 录音完成后生成全文转写或分析结果
• 需要给 AI、质检、知识库平台使用

推荐配置：

模板六：座席状态同步模板

适用场景：

• 第三方系统需要掌握座席登录、置忙、置闲、通话等变化

推荐配置：

模板七：满意度结果回写模板

适用场景：

• 满意度调查结束后需要自动回写到 CRM 或回访系统

推荐配置：

模板八：接口调试最小模板

适用场景：

• 项目刚开始联调
• 需要先验证网络、鉴权、字段格式

推荐配置：

建议联调顺序

如果项目实施时要做接口联调，建议按下面顺序推进：

1. 先确认接收方返回格式
2. 先用最简单的来电推送做联调
3. 再联调主话单和录音状态
4. 最后联调转写、分析、满意度等扩展类型

这样做的好处是：

• 更容易先跑通主流程
• 更容易定位字段问题
• 更适合分阶段上线

实施检查清单

为了让推送能力在项目中真正落地，建议在实施阶段按下面三个阶段逐项确认。

A. 上线前检查

在正式联调前，建议确认以下内容：

B. 联调中检查

在测试环境联调时，建议确认以下内容：

C. 上线后检查

在正式上线后，建议继续确认以下内容：

D. 项目交付建议

如果项目准备进入验收阶段，建议至少完成以下确认：

1. 至少 1 类基础推送已成功联调并稳定运行
2. 至少 1 类核心业务推送已成功进入目标系统
3. 推送日志可查、失败可定位
4. 重推能力已验证
5. 接收方返回格式已固定
6. 关键字段说明已形成书面材料

这样做的好处是：

• 上线更稳
• 问题更容易定位
• 后续交接更顺畅