Webhook 监控

快速阅读

Webhook 监控用于查看呼叫中心向客户系统推送事件的执行结果，帮助实施和技术人员判断事件是否推送成功、失败原因是什么、是否进入重试、客户系统是否正常响应。

本文的核心结论是：

• Webhook 监控回答“平台推给客户系统的事件是否送达并被正确响应”。
• 核心关注推送事件、推送时间、目标地址、响应结果、失败原因、重试次数和响应耗时。
• Webhook 监控不等同于话单。推送失败不代表通话事实丢失，通话事实仍应通过话单核对。
• 排查推送问题时，应先确认推送配置，再看推送结果、客户响应、重试记录和话单事实。

阅读地图

• 如果只想理解 Webhook 监控定位，重点阅读“二、产品总览”。
• 如果要设计字段和失败分类，重点阅读“六、产品功能说明”和“附录 B：关键字段口径”。
• 如果要做联调和上线保障，重点阅读“七、典型业务场景”和“附录 C：实施检查清单”。

一、文档说明

1.1 文档目的

呼叫中心会在通话开始、响铃、接听、挂断、话单生成、机器人转人工、满意度完成等节点向客户系统推送事件。客户系统依赖这些事件完成 CRM 弹屏、工单关联、订单状态更新、数据同步和质检分析。

如果缺少 Webhook 监控，常见问题包括：

1. 客户不知道事件是否推送。
2. 实施不知道失败是平台未推送、客户未接收、客户响应异常还是网络问题。
3. 客户系统和话单之间无法快速对账。
4. 推送失败后是否重试、重试是否成功讲不清。

本文用于建立 Webhook 监控的统一产品说明。

1.2 适用对象

• 客户技术负责人：用于确认客户系统是否正常接收事件。
• 实施顾问：用于联调、上线值守和推送异常排查。
• 产品经理：用于设计推送监控字段、筛选条件和失败提示。
• 运营负责人：用于理解事件推送失败对业务流程的影响。

1.3 文档范围

本文覆盖 Webhook 事件推送监控，不覆盖完整推送配置说明、客户系统接口开发、内部异步链路和底层重试实现。

二、产品总览

2.1 Webhook 监控是什么

Webhook 监控是面向事件推送链路的健康监控能力。它展示平台向客户系统推送事件的时间、类型、目标、结果、响应、失败原因和重试情况，帮助双方定位推送异常。

人话总结：

Webhook 监控让客户知道“平台有没有推、客户系统有没有收、收了之后有没有正确响应”。

2.2 主要解决的问题

• 某个通话事件是否推送。
• 推送到哪个客户接收地址。
• 客户系统返回了什么结果。
• 推送失败是否重试。
• 重试后是否成功。
• 推送失败是否影响客户业务流程。
• 如何通过通话标识与话单核对。

2.3 页面定位

Webhook 监控属于对接健康监控。它关注事件送达和响应，不负责判断通话最终业务结果。

三、核心概念

3.1 Webhook

Webhook 是平台在业务事件发生后，主动向客户系统发送通知的一种对接方式。客户系统需要提供可接收事件的地址，并按约定返回响应。

3.2 推送事件

推送事件表示平台需要通知客户系统的业务变化，例如通话开始、响铃、接听、挂断、话单完成、机器人转人工等。

3.3 推送结果

推送结果表示本次事件是否成功送达并获得符合约定的响应。失败时应展示客户可理解的失败原因。

3.4 重试

重试表示推送失败后，平台按策略再次尝试推送。是否支持重试、重试次数和间隔应以项目配置和实际能力为准。

3.5 响应耗时

响应耗时表示平台从发起推送到收到客户系统响应的时间。耗时过长可能影响事件处理及时性。

四、对象关系与数据流

通话 / 机器人 / 满意度 / 业务事件发生
↓
平台生成推送事件
↓
向客户系统 Webhook 地址推送
↓
客户系统接收并返回响应
↓
Webhook 监控记录结果、耗时、失败原因和重试情况
↓
结合话单、客户系统记录和日志完成核对

推送是对业务事件的通知，不是业务事实本身。即使推送失败，通话话单仍可能正常生成。

五、能力地图

六、产品功能说明

6.1 概览指标

建议展示：

6.2 明细字段

建议展示：

• 推送时间。
• 事件类型。
• 推送目标。
• 推送结果。
• 响应状态。
• 失败原因。
• 响应耗时。
• 重试次数。
• 最后一次推送时间。
• 通话标识。
• 业务标识。

6.3 筛选条件

常见筛选条件包括：

• 时间范围。
• 事件类型。
• 推送结果。
• 失败原因。
• 推送目标。
• 通话标识。
• 业务标识。
• 是否重试。

6.4 失败原因分类

建议使用客户可理解的分类：

七、典型业务场景

7.1 客户系统未收到通话结束事件

实施可按通话标识查询 Webhook 监控，确认是否产生推送、推送目标是否正确、客户系统是否响应成功。如推送成功但客户仍称未收到，应由客户侧排查接收和业务处理逻辑。

7.2 推送连续失败

技术负责人可按目标地址筛选失败记录，查看是否为地址不可达、响应超时或客户返回失败，并通知客户系统负责人处理。

7.3 重试后成功

Webhook 监控应展示首次失败和后续重试结果，方便客户理解事件最终是否送达，以及是否存在延迟。

7.4 上线联调

联调时可触发测试通话或测试事件，观察 Webhook 监控是否记录推送、客户系统是否按约定响应、字段是否能与客户业务记录关联。

八、上线准备与运营建议

8.1 上线准备

1. 确认客户接收地址。
2. 确认推送事件范围。
3. 确认鉴权或签名方式。
4. 确认客户系统成功响应标准。
5. 确认失败重试策略。
6. 确认通话标识和业务标识对账方式。
7. 准备成功、失败、超时、重试等验收用例。

8.2 运营建议

• 联调期重点看推送明细和客户响应。
• 上线初期重点看失败率、响应耗时和重试情况。
• 稳定期重点关注连续失败、目标地址变更和客户系统发布影响。
• 推送失败后应同时查看话单，确认通话事实是否正常沉淀。

九、与周边能力的关系

十、FAQ

10.1 推送失败是否代表通话失败？

不代表。推送失败只表示事件通知未成功送达或响应异常，通话事实应通过话单核对。

10.2 推送成功是否代表客户业务处理成功？

不一定。推送成功通常表示客户系统返回了约定的成功响应，客户内部业务处理是否完成需客户侧确认。

10.3 是否可以重新推送？

是否支持人工重推取决于实际产品能力和项目配置。若支持，应受权限控制并记录操作。

十一、总结

Webhook 监控是事件推送链路的排障入口。它帮助客户和实施确认事件是否送达、是否响应成功、是否重试成功，但通话事实仍应以话单为准。

附录 A：入口与权限

附录 B：关键字段口径

附录 C：实施检查清单

• 是否配置推送目标。
• 是否确认推送事件范围。
• 是否验证客户系统成功响应。
• 是否验证客户系统失败响应。
• 是否验证响应超时。
• 是否验证重试策略。
• 是否验证通话标识与话单关联。
• 是否确认敏感字段脱敏。

附录 D：常见问题速查

附录 E：术语表