技术帮助 · 发布时间：
云号码接入工单平台后，通话事件与工单状态关联的关键，不是把每通电话都变成一张新工单，而是准确判断电话属于哪个客户、哪项业务，以及通话结果应如何影响工单。可按以下五步建立规则，并在正式启用前用不同通话情形验证。
第一步：确定要接收哪些通话事件
先向云号码服务商确认可提供的事件字段和推送方式。常见信息包括通话唯一标识、主叫与被叫号码、呼入或呼出方向、开始与结束时间、接通结果和通话时长；实际字段名称及事件种类因服务而异，不能直接假定名称统一。
优先接收创建、接通、结束等必要事件，明确每种事件代表的事实。未接通不等于客户问题已解决，通话结束也不代表工单应该关闭。用webhook推送时，还要确认鉴权方式、失败重试规则和事件保留情况。
第二步：用稳定标识匹配客户与工单
先根据号码查找客户或联系人，再结合工单状态、号码方向和时间判断应关联哪张工单。若同一客户有多张未结工单，仅凭电话号码匹配容易挂错，应优先采用拨号时携带的工单编号、坐席当前打开的工单等明确上下文。
号码比较前可统一国家或地区码、空格和连接符等格式；但不要擅自删除可能有意义的号码前缀。匹配结果不唯一时，将通话记为待人工确认，比自动关联到错误工单更稳妥。
第三步：建立通话结果与工单状态映射
在工单平台配置状态映射表，把电话结果与工单动作分开定义。例如，已接通可以追加“已联系”记录，但是否转为“处理中”，应取决于现有工单状态和业务规则；未接通可记录联系失败，不应自动关闭；明确完成且符合关闭条件时，才执行关闭动作。
至少检查呼入、呼出、未接通、通话中断和重复来电等情况。若平台不支持细分状态，可先追加通话记录或备注，再由经办人决定是否变更工单，避免状态被自动化规则覆盖。
第四步：防止重复事件造成重复更新
事件可能因网络或服务端重试而再次送达，也可能先收到结束事件、后收到较早的状态通知。以通话唯一标识作为去重依据，并保存已处理的事件类型或版本信息；同一事件重放时，不重复创建记录、发送通知或关闭工单。这类机制称为幂等处理。
如果接入方提供事件时间，应检查时间顺序；无法确认先后时，避免用旧事件覆盖工单当前状态。接口处理失败时保留错误原因和重试结果，便于定位是鉴权、字段缺失还是工单匹配失败。
第五步：用真实流程试运行并定期核对
- 准备测试号码和测试工单，分别拨打接通、未接通及中途挂断等情形。
- 核对平台收到的通话记录、号码方向、时间和关联工单是否一致。
- 重复提交同一事件，确认不会生成重复记录或重复通知。
- 验证无匹配工单、多个候选工单和接口暂时不可用时的处理方式。
- 正式启用后，抽查通话记录与工单时间线；对无法自动匹配的记录设置人工处理入口。
还要限制通话详情和录音的访问权限。录音是否保存、保存多久，应依据实际业务需要、适用规定和服务配置确定，不要把“接入了通话事件”误认为“可以长期保存录音”。
常见问题
通话结束后是否应自动关闭工单？
通常不应。结束事件只能说明通话结束，是否解决问题需要结合处理结果或人工确认。
一个电话号码对应多张工单怎么办？
用工单编号、当前办理上下文或明确的筛选规则辅助匹配；仍有歧义时转人工确认。
事件重复送达会影响工单吗？
使用通话标识去重，并让重复事件不重复执行状态变更和通知。
哪些内容值得优先核对？
重点检查通话方向、事件时间、匹配依据、状态映射和异常记录。做好这些环节，云号码接入工单平台后的通话事件与工单状态关联才更可靠，也更容易追查问题。
