不用等报告，每天都能看到客户打电话来问什么；数百万用户的数据也只留在公司系统内。
电信运营商与 ISP “我们的呼叫中心每天有好几万通电话，网络工单每个技术员写法都不一样。想让 AI 来总结，可无论按牌照要求还是 PDPA，用户数据都不能往外送。”
我们常见的问题
运营商的呼叫中心每天要接好几万通电话，客服写的通话后记录有长有短，各个技术团队写的网络工单格式也各不相同。某个地区一出故障，网络运营中心（NOC）就得一路往回翻，看以前有没有发生过；服务团队知道投诉在增加，可等汇总成报告已经到了周末。
用户数据受牌照条件和泰国《个人数据保护法》（PDPA）约束，不能送到别人的云上分析；以这样的数据量，按请求次数付费给外部服务商也不划算。团队只能对删除了姓名的数据使用 AI，实际上几乎派不上用场。
我们的解决方法
我们把语言模型部署在运营商数据中心的 Kubernetes 上，或公司掌控的云账号中，规模按每天的通话量配置，再对接现有的客服中心、计费和工单系统。每通电话结束后，系统把来电原因、处理结果和未结事项总结写入 CRM；客户再次来电时，客服接听前就能看到摘要。
在网络这一侧，NOC 可以问某个交换局以前是否出现过这种故障现象，系统会给出历史工单和当时的解决办法。一切都在运营商自己的网络内运行，权限按团队和地区划分，个人数据按权限级别遮盖，每次提问都有审计日志，供合规部门和 DPO 检查。
系统负责总结、检索和起草；调整账单、取消服务和派技术员上门，仍由客服和团队主管决定。系统不会自行向客户发送任何内容。
系统如何运行
工作来源
- 呼叫中心通话与通话后记录
- 网络工单与故障报告
- 计费系统和 CRM 中的号码数据
- 各渠道的投诉
AI 做什么
- 按权限遮盖个人数据
- 总结每通电话并归类问题
- 检索历史工单和解决办法
- 为客服起草回复
结果去向
- 客户再次来电前，摘要已写入 CRM
- 附历史工单的答复发给 NOC
- 每日投诉报告发给网络团队
- 供合规部门查阅的审计日志
使用前后对比
使用前
使用后
通话后记录看不懂，客户再次来电只好从头讲一遍
客服接听前就能看到这位客户上次通话的摘要
故障发生时，NOC 自己翻历史工单
NOC 输入故障现象，当场拿到历史工单和解决办法
投诉报告到周末才汇总出来
投诉每天自动归类，异常地区立即通知网络团队
您将获得
- 01
部署在运营商数据中心的模型，把呼叫中心的每通电话总结为来电原因、处理结果和未结事项
- 02
嵌入客服界面的助手，按权限读取该号码的套餐、欠费和使用记录，再起草回复
- 03
用日常提问检索历史网络工单和故障报告，帮助网络运营中心（NOC）找出以前解决过的同类故障
- 04
每天把投诉归类，标出来电量异常增加的地区，发给网络团队和服务团队
- 05
按权限级别遮盖身份证号和个人使用数据，每次提问都有审计日志
各方的收获
部署在您数据中心的 Kubernetes 上，规模按通话量配置，通过 API 对接客服中心和计费系统，权限沿用 Active Directory，每次提问都有审计日志。
客服不用再写长篇通话后记录，也不用再问客户之前是什么问题；NOC 不用再一张张翻历史工单。
适合哪些企业
移动通信运营商互联网与宽带服务商数据中心与云服务商有线电视与数字服务商企业通信服务商
对接您现有的系统
计费系统CRMGenesysServiceNowActive DirectoryKubernetes
开发流程
- 1
需求梳理
明确需求、用户与成功指标，开工前锁定范围与价格。
- 2
设计
设计 UX 与系统架构，原型确认后才进入开发。
- 3
开发
AI 加速的迭代冲刺，每周演示，资深工程师评审。
- 4
测试
按约定范围验证质量、安全与性能。
- 5
上线与维护
生产部署、团队培训与月度维护计划。
