通道与通道变量

快速阅读

本文用于统一说明呼叫中心中的“通道”和“通道变量”能力，帮助客户、业务、实施和技术团队从通信链路和话单（CDR）视角理解一次通话如何承载业务上下文，以及这些上下文如何在呼入路由、IVR、工作台弹屏、主从话单、事件推送、录音质检和外部系统之间流转。

本文的核心结论是：

• 通道可以理解为一次通话在呼叫平台中的实时承载对象，用于支撑接入、路由、通话控制、录音、事件和话单沉淀。
• 通道变量是随一次通话流转的业务扩展信息，可用于携带客户编号、工单号、订单号、线索 ID、机器人会话 ID、活动批次等上下文。
• 通道变量不是页面字段本身，而是“通话过程中的上下文载体”；是否展示、沉淀或推送，取决于后续配置。
• 从话单视角看，通道变量先随通信链路进入通话上下文，再按配置进入主话单、从话单、记录扩展字段、推送字段或导出列。
• 通道变量可来自外部请求、SIP Header 透传、IVR 节点、机器人、外呼任务、系统识别或人工配置。
• 上线通道变量前，必须统一变量命名、来源、使用范围、话单沉淀口径、脱敏规则、长度限制、验收链路和排障方法。

阅读地图

• 如果只想理解通道与通道变量是什么，重点阅读“二、产品总览”和“三、核心概念”。
• 如果要规划变量从哪里来、流向哪里，重点阅读“四、对象关系与数据流”和“五、能力地图”。
• 如果要配置弹屏、推送、话单扩展字段或 SIP Header 透传，重点阅读“六、产品功能说明”和“八、上线准备与运营建议”。
• 如果要排查变量没有展示或没有推送，重点阅读“十、FAQ”和“附录 D：常见问题速查”。

一、文档说明

1.1 文档目的

呼叫中心中的很多业务场景，都需要把电话和客户业务系统关联起来。例如：

1. 客户打进热线时，希望座席弹屏看到客户编号和订单号。
2. 座席从 CRM 点击外呼时，希望通话结束后能回写线索 ID 和工单号。
3. AI 机器人转人工时，希望人工座席能看到机器人会话 ID、客户意图和转人工原因。
4. 外部系统通过 SIP 接入时，希望把自定义 Header 中的业务字段带入通话记录和事件推送。
5. 质检或录音系统希望通过业务标识找到对应通话。

这些信息如果只停留在外部系统或单个页面中，就无法在通话全链路中稳定使用。通道变量的作用，就是在一次通话的生命周期内承载并传递这些业务上下文，并在需要时随话单、事件和记录沉淀下来。

本文用于建立通道与通道变量的统一产品说明，支撑配置、联调、验收、话单解释、客户解释和问题排查。

1.2 适用对象

• 客户业务负责人：用于理解通话与 CRM、工单、订单、机器人等业务系统如何关联。
• 运营管理人员：用于确认哪些业务字段需要在弹屏、记录、导出和推送中使用。
• 实施顾问：用于规划变量命名、配置映射、联调路径和验收用例。
• 产品经理：用于统一通道变量在呼入、外呼、IVR、推送、记录和报表中的口径。
• 技术负责人：用于理解变量来源、传递链路、字段边界和排障方法。

1.3 文档范围

本文覆盖通道、通道变量、变量来源、变量流转、变量配置、变量展示、变量沉淀、事件推送、SIP Header 透传、自定义弹屏、通话记录和实施验收建议。

本文不展开底层通信协议、代码实现和内部实现细节。涉及 SIP Header 时，仅说明产品化透传链路和实施注意事项；具体报文细节以专项实施手册为准。

二、产品总览

2.1 什么是通道

通道是一次通话在呼叫平台中的实时承载对象。客户来电、座席外呼、WebCall、预测外呼、转接、咨询、三方、机器人接待等通话过程，都需要通过通道来承载通话状态和控制动作。

人话总结：

通道就是一通电话在系统里的“实时通话载体”。电话还在进行时，系统通过通道知道这通电话是谁、在哪里、什么状态、还能执行哪些动作。

2.2 什么是通道变量

通道变量是随一次通话传递的业务扩展信息。它通常以“变量名 + 变量值”的方式存在，用于在通话过程中标记业务上下文。

例如：

通道变量本身不等于通话记录字段、推送字段或弹屏字段。只有在对应页面、记录、推送或流程中配置引用后，变量值才会被展示、沉淀或发送。

2.3 核心价值

2.4 常见使用场景

通道变量常用于以下场景：

• CRM 点击外呼携带客户 ID、线索 ID。
• 工单系统发起回呼携带工单号。
• 机器人通过 SIP 转人工携带机器人会话 ID。
• IVR 自助查询后携带订单号或查询结果。
• 预测外呼任务携带任务 ID、批次号、名单字段。
• 自定义弹屏页通过变量打开客户业务页面。
• 事件推送把通话结果和业务标识回传客户系统。
• 通话记录导出时带出客户侧业务字段。

2.5 从话单视角理解通道变量

从话单（CDR）视角看，通道变量不是“页面上临时显示的字段”，而是通话事实链路中的业务上下文。

一次通话通常会经历：

实时通话通道
  ↓
通话事件：响铃、接听、桥接、转接、挂机
  ↓
主话单 / 从话单
  ↓
通话记录、录音、推送、导出、报表

通道变量在这条链路中的作用是把客户侧业务对象带入通话事实。例如同一通电话既可以通过主话单查看整体结果，也可以通过从话单查看座席腿、转接腿或咨询腿；如果变量按配置沉淀下来，运营和客户系统就可以用客户 ID、订单号、工单号或机器人会话 ID 关联这条通话事实。

三、核心概念

3.1 通话通道

通话通道承载一次实时通话的状态和控制能力。它用于支撑呼叫、接听、挂断、保持、转接、咨询、三方、录音和事件等通话动作。

在业务解释中，可以把通道理解为“当前这通电话在系统中的实时对象”。

3.2 主通道与子通道

复杂通话可能存在多个通道或多段链路。例如 WebCall 先呼第一方再呼第二方，呼入先进入 IVR 再转队列，通话中发生咨询或三方时，也可能出现不同通话腿。

产品解释中不建议客户直接按底层通道数量理解业务结果，应结合主话单、从话单、第一方/第二方和通话类型综合解释。

3.3 主话单与从话单

主话单用于描述一通电话或一次业务会话的整体结果，适合回答“这通电话总体发生了什么”。

从话单用于描述通话中的某一段过程，例如座席腿、转接腿、咨询腿、三方腿、机器人接待或其它过程明细，适合回答“这通电话在哪一段发生了什么”。

通道变量既可能只在实时通话过程中使用，也可能按配置进入主话单或从话单的扩展字段。是否进入哪一类记录，应根据业务追溯和对账要求提前确认。

3.4 通话标识

通话标识用于把实时通道、主话单、从话单、录音、事件推送和外部业务系统串联起来。

常见标识包括：

通道变量经常和这些标识配合使用：通话标识定位“是哪通电话”，通道变量解释“这通电话属于哪个业务对象”。

3.5 通道变量

通道变量是挂在一次通话上下文中的扩展信息。它通常用于业务联动，而不是用于替代系统标准字段。

标准字段包括客户号码、座席、热线、队列、通话标识、开始时间、接听状态等。通道变量用于补充客户业务系统关心的字段。

3.6 变量名

变量名是变量的稳定识别名称。变量名应在项目上线前统一约定，并在弹屏、推送、话单、IVR、机器人等配置中保持一致。

变量名建议：

• 使用业务可读名称。
• 避免频繁变更。
• 避免使用含义模糊的名称。
• 避免多个字段使用同一个名称。
• 避免把示例变量名当作平台固定字段。

3.7 变量值

变量值是本次通话中实际携带的业务内容，例如某个客户 ID、订单号或机器人会话 ID。

变量值应注意：

• 不建议传递敏感明文信息。
• 字段长度应控制在项目约定范围内。
• 编码格式应与对接方约定一致。
• 对外展示前应考虑脱敏和权限。

3.8 变量来源

通道变量可能来自多个来源：

3.9 变量消费方

变量消费方是使用变量的能力或页面，包括：

• 工作台弹屏。
• 自定义页面或 Tab 页。
• IVR 流程判断。
• 通话记录和导出。
• 事件推送。
• 录音质检。
• 机器人转人工。
• 外部 CRM、工单、订单或数据平台。

3.10 变量生命周期

通道变量通常跟随一次通话生命周期流转：

变量产生
  ↓
进入通话上下文
  ↓
在路由、IVR、弹屏、推送等环节被读取
  ↓
按配置沉淀到记录或事件
  ↓
通话结束后用于查询、对账或复盘

并非所有通道变量都会永久保存。是否沉淀取决于通话记录、自定义字段、推送和日志配置。

3.11 话单扩展字段

话单扩展字段是通道变量沉淀到记录后的产品化结果。它用于在通话结束后继续查询、导出、对账或推送业务字段。

需要注意：

• 通道变量不一定都会进入话单。
• 进入话单的字段应提前配置并统一命名。
• 主话单和从话单可承载的字段口径可能不同。
• 进入话单后的字段才适合用于长期查询、导出和对账。
• 临时变量、敏感变量或流程内部变量不建议全部沉淀。

3.12 SIP Header 透传

SIP Header 透传是通道变量的一类常见来源。客户侧通过标准方式把业务字段放入 SIP 呼叫请求中，平台读取后映射为通道变量，再供弹屏、记录、推送等后续能力使用。

SIP Header 透传适合 SIP 呼入对接、机器人转人工、外部通信系统接入等场景。

四、对象关系与数据流

4.1 总体对象关系

外部业务系统 / 呼叫入口 / IVR / 机器人 / 外呼任务
  ↓ 生成或传入业务字段
通道变量
  ↓ 挂载到本次通话上下文
通话通道
  ├─ 实时消费：呼入路由 / IVR 判断 / 工作台弹屏
  ├─ 过程消费：机器人转人工 / 邀请第三方 / 事件推送
  └─ 结束沉淀：主话单 / 从话单 / 录音 / 导出 / 报表
        ↓
      外部系统对账 / 质检复盘 / 运营分析

4.2 从通信通道到话单的主链路

通话接入或发起
  ↓
创建实时通话通道
  ↓
写入系统标准上下文和业务通道变量
  ↓
通话过程中产生响铃、接听、桥接、转接、咨询、三方、挂机等事件
  ↓
事件链路按需读取变量并推送
  ↓
通话结束后整理为主话单和从话单
  ↓
按配置把部分变量沉淀为话单扩展字段
  ↓
记录查询、导出、报表、录音质检和客户系统对账

这条链路是理解通道变量的主线：变量先属于实时通信上下文，随后才可能成为话单字段、推送字段或页面字段。页面展示只是变量的一个消费结果，不是变量本身。

4.3 外呼场景变量流转

客户系统发起点击外呼
  ↓
提交客户号码、请求唯一标识和业务变量
  ↓
呼叫平台创建通话并写入通道变量
  ↓
座席与客户通话
  ↓
通话状态事件携带相关业务标识
  ↓
主话单或从话单按配置沉淀业务字段
  ↓
客户系统按业务标识回写结果

4.4 呼入场景变量流转

客户拨打热线
  ↓
系统识别客户号码、热线和通话标识
  ↓
呼入路由或 IVR 读取上下文
  ↓
IVR 收号、查询或识别生成业务变量
  ↓
客户进入队列并分配座席
  ↓
工作台弹屏展示客户资料和业务变量
  ↓
通话结束后主话单、从话单和推送按配置保留变量

4.5 SIP Header 透传流转

客户侧系统发起 SIP 呼叫
  ↓
按约定携带需要透传的 Header
  ↓
平台接收并读取指定 Header
  ↓
映射为项目约定的变量名
  ↓
变量进入通话上下文
  ↓
弹屏、Tab 页、记录、推送按配置引用变量

该链路中，关键不是“页面直接读取 Header”，而是 Header 先进入通话上下文，再由页面、记录或推送消费。

4.6 机器人转人工变量流转

客户与机器人通话
  ↓
机器人识别客户意图或转人工原因
  ↓
生成机器人会话 ID、意图、摘要等变量
  ↓
触发转人工
  ↓
变量随通话传递给人工座席
  ↓
座席工作台展示上下文
  ↓
记录和推送保留转人工信息

五、能力地图

六、产品功能说明

6.1 通道上下文承载

通道上下文用于在一次通话过程中保存当前通话的相关信息，包括系统标准字段和业务扩展字段。

标准上下文通常包括：

• 主通话标识。
• 分段通话标识。
• 通话标识。
• 客户号码。
• 座席。
• 热线。
• 队列。
• 通话类型。
• 当前状态。

业务扩展上下文通常通过通道变量承载。

6.2 变量写入

变量写入表示将外部或流程中的业务字段写入本次通话上下文。

常见写入方式：

1. 外部系统发起请求时传入。
2. SIP Header 透传后映射为变量。
3. IVR 节点收集客户输入后写入。
4. 机器人识别后写入意图、摘要或转人工原因。
5. 外呼任务从名单字段中带入。
6. 系统根据号码、热线、队列等自动补充。

6.3 变量读取

变量读取表示后续能力按变量名获取对应值。

常见读取场景：

• IVR 判断节点读取变量并分流。
• TTS 变量读取文本并播报。
• 工作台弹屏读取变量并展示。
• 自定义页面读取变量并拼接页面参数。
• 推送事件读取变量并发送给客户系统。
• 通话记录读取变量并写入扩展字段。

6.4 弹屏与页面参数

弹屏和自定义页面通常需要把变量转换为页面可识别的参数。

例如：

配置时应确保页面参数名、变量名和客户系统接收字段一致。

6.5 推送变量

推送变量用于在通话事件发生时，把业务上下文带回客户系统。

常见事件包括：

• 来电进入。
• 座席响铃。
• 通话接通。
• 通话挂机。
• 话单生成。
• 录音完成。
• 转人工。
• 满意度结束。

如果客户系统依赖变量对账，应确保该变量在相关事件中都能稳定返回。

6.6 记录与导出

通道变量可以按项目配置进入主话单、从话单、通话记录自定义字段或导出列。

从话单角度看，应先判断变量需要沉淀在哪个对象上：

使用建议：

• 只沉淀有业务价值的字段。
• 不要把大量临时变量全部写入记录。
• 敏感字段应脱敏或不落明文。
• 字段名称应和客户业务口径一致。
• 需要对账的字段应优先沉淀在主话单或稳定记录字段中。
• 只在通话过程中使用的临时变量，不建议作为导出字段。
• 导出前确认权限和数据范围。

6.7 IVR 与 TTS 变量

IVR 中可使用变量完成判断、播报和分流。

常见场景：

• 根据客户等级变量进入 VIP 队列。
• 根据订单状态变量播报查询结果。
• 根据机器人识别意图决定是否转人工。
• 使用 TTS 变量播报动态文本。

如果变量为空或不存在，IVR 应配置失败兜底路径，避免客户卡在流程中。

6.8 SIP Header 透传

SIP Header 透传用于 SIP 接入场景下传递客户侧业务字段。

实施原则：

1. 客户侧先明确要透传哪些业务字段。
2. 客户侧按双方约定方式发送字段。
3. 平台侧读取字段并映射为通道变量。
4. 后续弹屏、记录、推送按变量名引用。
5. 联调时先验证字段是否进入通话上下文，再验证页面展示和推送。

不建议客户把未约定、超长或敏感明文字段直接透传到通话链路中。

6.9 变量命名规范

变量命名建议遵循：

• 语义清晰：能看懂字段含义。
• 前后一致：外部系统、平台配置和页面参数保持一致。
• 稳定不变：上线后尽量不改变量名。
• 避免歧义：不要用 value、id、data 等泛化名称。
• 控制范围：不同业务线可加前缀区分。

示例：

6.10 安全与脱敏

通道变量可能包含客户业务信息，应遵循安全原则：

1. 不传身份证号、银行卡号、密码、验证码等高敏感明文。
2. 如需传递敏感标识，优先使用加密串、脱敏值或业务 ID。
3. 弹屏、导出和推送应受权限控制。
4. 变量值不应无限制放大，避免影响链路稳定。
5. 变量用于外部系统访问时，应结合页面鉴权和访问控制。

七、典型业务场景

7.1 CRM 点击外呼

座席在 CRM 客户详情页点击外呼，CRM 提交客户号码、客户 ID、线索 ID 和请求唯一标识。通话结束后，事件推送携带这些变量，CRM 根据变量回写通话结果。

建议关注：

• 请求唯一标识是否唯一。
• 客户 ID 和线索 ID 是否稳定。
• 推送事件是否返回关键变量。
• 通话记录是否能按变量查询或导出。

7.2 工单回访

售后系统发起客户回访，通道变量携带工单号和服务记录 ID。座席接听或外呼时弹屏打开对应工单，通话结束后自动关联回访结果。

建议关注：

• 工单号是否进入弹屏参数。
• 工单状态回写是否依赖通话结果。
• 录音和记录是否可按工单追溯。

7.3 AI 机器人转人工

客户先与机器人沟通，机器人识别客户意图、会话 ID 和转人工原因。转人工时，这些信息作为变量传给人工座席，避免座席重复询问客户。

建议关注：

• 机器人会话 ID 是否稳定。
• 转人工原因是否清晰。
• 座席工作台是否展示会话摘要。
• 通话记录和推送是否保留转人工信息。

7.4 SIP 呼入对接

客户侧系统通过 SIP 呼入平台，并在请求中携带业务 Header。平台读取 Header 后映射为通道变量，用于自定义弹屏、通话记录和事件推送。

建议关注：

• Header Key 是否按项目约定。
• 平台变量名是否统一。
• 弹屏、记录、推送是否引用同一变量。
• 联调时先验证变量链路，再验证页面。

7.5 IVR 自助查询

客户在 IVR 中输入订单号，系统查询订单状态后，将订单号和查询结果写入变量。后续客户转人工时，座席可看到订单上下文。

建议关注：

• 收号校验是否准确。
• 查询失败是否有兜底。
• 转人工时变量是否带给座席。
• 记录中是否需要沉淀订单号。

7.6 预测外呼名单字段传递

预测外呼任务导入名单时包含客户标签、批次号、活动编号等字段。客户接通并分配座席后，相关变量用于弹屏、记录和报表分析。

建议关注：

• 名单字段是否规范。
• 字段是否需要脱敏。
• 批次和活动编号是否能用于对账。
• 变量是否随重呼和最终记录保持一致。

八、上线准备与运营建议

8.1 上线前准备

上线通道变量前建议确认：

1. 本项目需要传递哪些业务字段。
2. 每个字段从哪里来。
3. 每个字段要流向哪里：弹屏、记录、推送、IVR、机器人或报表。
4. 变量名、页面参数名、推送字段名是否统一。
5. 字段长度、格式、字符集和是否必填。
6. 是否包含敏感信息，是否需要脱敏。
7. 哪些事件需要带出变量。
8. 哪些记录或导出列需要沉淀变量。
9. 测试通话如何验证变量链路。
10. 变量缺失时的兜底和排障责任。

8.2 联调建议

联调建议按以下顺序进行：

确认变量清单
  ↓
确认变量来源和命名
  ↓
发起测试通话
  ↓
验证变量是否进入通话上下文
  ↓
验证弹屏或页面是否收到变量
  ↓
验证推送事件是否带出变量
  ↓
验证通话记录和导出是否沉淀变量
  ↓
验证异常和变量缺失场景

不要一开始就只看页面是否展示。页面没有值时，应先回查变量是否进入通话上下文。

8.3 运营建议

• 定期检查变量命名是否混乱。
• 避免多个业务字段复用同一个变量名。
• 不再使用的变量应从页面、推送和记录配置中清理。
• 关键业务变量应保留测试用例。
• 变量变更应同步客户系统、实施和运营。
• 对外推送字段变更前应提前通知客户系统。

8.4 风险提示

九、与周边能力的关系

9.1 与呼入路由的关系

呼入路由可根据系统已识别的上下文进行分流。若某些业务条件只能在 IVR 或外部查询后获得，应在后续流程中使用变量判断，而不是强行放在入口路由阶段。

9.2 与 IVR / 语音导航的关系

IVR 可以读取和生成变量。变量可用于菜单分流、TTS 播报、自助查询、机器人接入和转人工。

9.3 与工作台弹屏的关系

工作台弹屏可使用变量打开客户资料、工单、订单或自定义页面。变量缺失会导致弹屏信息不完整或页面无法定位业务对象。

9.4 与通话记录和话单的关系

通道变量可按配置沉淀到主话单、从话单、通话记录或自定义字段中。若没有沉淀配置，通话结束后可能无法在记录中查询到该变量。

建议按以下方式理解：

• 实时通道回答“通话正在发生什么”。
• 主话单回答“这通电话整体发生了什么”。
• 从话单回答“某一段通话腿发生了什么”。
• 通道变量回答“这通电话关联了哪个业务对象或业务上下文”。
• 记录扩展字段回答“哪些变量需要在通话结束后继续查询、导出或对账”。

9.5 与事件推送的关系

推送用于把通话事件和变量同步给客户系统。客户系统如果依赖变量对账，应确认开始、接通、挂机、话单生成等关键事件是否都带出必要字段。

9.6 与机器人和 AI 转人工的关系

机器人和智能体产生的意图、会话 ID、摘要和转人工原因，可以通过变量带给人工座席和后续记录，减少重复询问并提升服务连续性。

9.7 与录音质检和智能分析的关系

录音和质检可通过变量关联业务对象，例如订单、工单、客户标签或机器人会话。这样可按业务维度抽检录音，而不只按号码和时间检索。

十、FAQ

10.1 通道变量和通话记录字段是一回事吗？

不是。通道变量是通话过程中的上下文载体；通话记录字段是通话结束后沉淀和展示的数据。变量是否进入记录，取决于记录字段配置。

10.2 通道变量和话单扩展字段是什么关系？

通道变量是实时通话中的业务上下文，话单扩展字段是通话结束后沉淀下来的记录字段。可以理解为：变量是过程中的值，话单扩展字段是被保存下来、可查询和可导出的结果。

10.3 为什么弹屏页面没有拿到变量？

常见原因包括变量没有写入通话上下文、页面参数名和变量名不一致、弹屏配置未引用该变量、页面鉴权失败或浏览器拦截。

10.4 SIP Header 已经传了，为什么页面还是没有值？

需要先确认 Header 是否被平台识别并映射为通道变量。页面通常不会直接解析原始 Header；如果变量链路未打通，页面配置不会生效。

10.5 变量名能不能随便取？

不建议随便取。变量名应在项目中统一约定，并在弹屏、推送、记录、IVR、机器人等配置中保持一致。

10.6 通道变量能传敏感信息吗？

不建议传递敏感明文。应优先传业务 ID、加密串或脱敏值，并通过权限控制页面展示、导出和推送。

10.7 通话结束后变量还在吗？

通话结束后，变量是否可查取决于是否被写入通话记录、自定义字段、推送日志或其它持久化结果。未配置沉淀的变量可能只在通话过程中可用。

10.8 变量可以用于 IVR 播报吗？

可以。IVR 可读取变量用于 TTS 播报或流程判断。但如果变量为空，应配置失败提示或转人工兜底。

10.9 同一个变量能否同时用于弹屏、推送和记录？

可以，但需要分别配置对应消费方。变量进入通话上下文后，不代表所有下游能力都会自动使用它。

10.10 外呼和呼入的通道变量有什么区别？

外呼变量通常来自客户系统发起请求、任务名单或座席操作；呼入变量通常来自号码识别、SIP Header、IVR 收号、机器人或外部查询。两者使用目标类似，来源不同。

10.11 如何验收通道变量能力？

应至少验证变量来源、通话上下文、弹屏展示、推送返回、主话单或从话单沉淀、导出字段和异常缺失场景。不要只验证一个页面展示。

十一、总结

通道与通道变量是呼叫中心业务联动的重要基础能力。通道承载实时通话，通道变量承载业务上下文，使电话、客户、工单、订单、机器人会话、主从话单、记录、推送和外部系统能够被同一条通话链路串联起来。

实施通道变量时，应优先明确变量清单、来源、命名、流向、权限、主从话单沉淀口径和验收路径。只有让变量在“产生、写入、读取、展示、推送、话单沉淀、导出、排障”各环节都可验证，才能稳定支撑客户业务闭环。

附录 A：入口与权限

A.1 常见入口

A.2 权限建议

附录 B：关键字段口径

附录 C：实施检查清单

附录 D：常见问题速查

附录 E：术语表