01-从三个痛点出发：我们为什么做一套跑在浏览器里的呼叫中心

从三个痛点出发：我们为什么做一套跑在浏览器里的呼叫中心

这个项目立项之前，我们跟不少中小企业销售团队聊过。聊下来发现电话这个最古老的沟通工具，在多数公司里的使用方式还停留在十年前：员工用自己手机打客户电话，客户资料记在 Excel 或者干脆记在脑子里，老板想知道团队这个月打了多少电话、接通率多少，只能靠人挨个问。

归纳起来就是三个痛点：

工具散。 个人手机打电话，通话记录和客户跟进完全无法沉淀。销售离职，客户资源跟着走，公司连个交接的凭据都没有。就算有人认真记录，也是各记各的，格式五花八门，最后谁都用不起来。

管不住。 管理者看不到坐席的话务量、接通率，更谈不上话术合规审查。出了客诉，找不到录音，双方各执一词。

门槛高。 传统呼叫中心要采购话机、板卡，本地部署，数万到数十万起步，还要养一个懂通信的运维。对几十人的销售团队来说，这套投入完全不成比例。

所以我们想做的东西其实很具体：一套多租户 SaaS 云呼叫中心——不采购硬件话机，打开浏览器就能接电话、跑外呼，客户资料、通话记录、录音、报表全部沉淀在系统里。目标说大不大：一家企业一天内开通、一周内用起来。

「浏览器接听」是整个产品的锚点

早期讨论产品形态时，最大的一个决策是坐席端到底用什么。

装客户端是最省事的技术路线，但对销售团队来说，"装个软件"就是一道实实在在的门槛——尤其是坐席流动性大的电销团队，新人入职第一件事不是培训而是装环境，体验很糟糕。最终我们把这个产品最重要的形态定死在：浏览器 WebRTC 接听。坐席打开管理后台，签入，软电话就在页面里，来电弹屏、通话、挂断、标记客户，一气呵成。

这个决定影响了整个架构。浏览器媒体是 DTLS-SRTP，运营商线路是普通 RTP，中间必须有媒体桥；SIP 信令要过 WSS，还要处理证书和 NAT。后面讲 Kamailio 和 RTPEngine 的那篇文章，根子都在这里。Android 端后来补了一个 Flutter APP（用 sip_ua），但 PC 浏览器始终是第一等公民——软电话是坐席的生产工具，不是演示件，这条写在 PRD 里。

五类角色，各取所需

系统里的角色比想象中多，每类人在意的东西完全不同：

• 平台运营（我们自己）：开通租户、分配号码、定费率、对账。最在意多租户隔离和计费准确——计费错一分钱都是事故。
• 企业管理员（客户公司的 IT/行政）：配技能组、IVR、坐席账号、外呼任务。要的是配置简单、权限可控。
• 班长/主管：盯监控大屏（15 秒自动刷新）、在线调任务并发、强制离线挂断违规坐席。要实时数据准、干预动作快。
• 坐席：签入、接听、外呼、标记客户、公海领客户。要求就一个：好用不卡。
• 质检/数据分析：听录音、导话单、看报表。检索要快，导出要全。

权限粒度做到了按钮级，权限串统一 callcenter:<资源>:<动作> 格式。比如"改任务并发"这个动作，班长只能改自己技能组绑定的任务，管理员不限——这类差异全部落在权限矩阵里，而不是靠前端藏按钮。

十二个模块，一条主线

功能上划分成 M1~M12 共十二个模块：知识库、客户管理、坐席管理、外呼管理、呼入配置、数据查询、报表、工单、AI 任务、终端黑名单、数据推送、软电话。

听起来像功能堆砌，但内在有一条主线：客户生命周期闭环。客户从公海领取变成私海，坐席跟进、外呼触达、通话录音留证、挂机标记状态、工单跟进、回收再分配——所有模块都挂在这条链上。单独的电话系统或单独的 CRM 市面上一抓一大把，把两者拧在一起且以"电话"为核心动线的，才是这个产品真正的定位。

举两个例子说明这种"拧"法：

• 外呼任务支持自动/预测/预览三种模式。预测外呼按近 15 分钟接通率滑动窗口动态调并发（接通率低就自动降速），预览外呼则是先弹客户资料给坐席确认再拨号——同一套引擎服务两种完全不同的使用习惯。
• 挂机后坐席进入整理事务（ACW），处理完自动回闲继续接下一通；客户状态由坐席标记（意向/成功/无效……），报表里的"成功率 = 成功数 ÷ 呼叫总数"直接取这个口径。

数字先想清楚，架构才有边界

立项时我们写了一组规模假设，现在回头看，这些数字基本决定了后面所有的架构取舍：

• 租户数 ≤ 200，总坐席 ≤ 2000（单租户 ≤ 500）；
• 峰值并发通话 ≤ 300 路，日呼叫量约 4 万通；
• 日新增话单（CDR）约 4 万行，一年 1500 万行；
• 录音按平均 90 秒、Opus 16kbps 算，一天 7GB，一年 2.5TB。

1500 万行和 2.5TB 直接催生了两个决定：话单表按月分区、在线只留 6 个月热数据，冷数据转 parquet 归档到对象存储；坐席实时状态不查库，权威放 Redis（2000 个坐席被监控页 15 秒一轮地刷，数据库扛不住这种放大）。

质量目标也提前定了：录音完整率 ≥ 99.9%，CDR 入库延迟 P95 < 5 秒，月度可用性 ≥ 99.5%，话单 Webhook 推送成功率（含重推）≥ 99%，系统原因重复外呼率为 0。最后这条是红线——对客户来说，同一个号码被系统打两遍，比一次接通失败严重得多。后面讲外呼引擎和计费的文章里会反复看到为这条红线堆出来的五层防重。

诚实地说说现状

介绍文不打算只挑好的说。截至 2026 年 10 月：

• 呼出主链路（点击拨号、任务外呼、录音、计费对账、数据推送）已在生产打通，支撑灰度试运行；
• 呼入方向代码就绪，但生产端到端联调还没完成，是当前最高优先级的欠账；
• AI 外呼的对话引擎已能跑通，但媒体面编排还缺一块；
• APP 端的 WebRTC 通话还没通。

这些欠账都记在 TODO 和开发计划里，逐个消化。做 SaaS 和做 demo 的区别就在这里：demo 演通一条 happy path 就算完，生产系统要回答的是"每一通电话都计对费、每一段录音都找得回、每一个租户的数据都串不了"——这也是这个系列后面九篇文章真正想讲的东西。

---

本文是「云呼叫中心技术内幕」系列第 1 篇。