CCPaaS客户选型指南

一、易混淆的名词解释

CPaaS，CCaaS，CCPaaS傻傻分不清？先看看定义

• CPaaS（ Communication Platform as a Service ）。通信平台云服务，是PaaS形式的云通信产品服务，其核心是对运营商通信能力API封装和云化。
• CCaaS（ Contact Center as a Service ）。呼叫中心云服务，是SaaS形式的云服务产品，一般也称为云呼叫中心。
• CCPaaS（ Contact Center Platform as a Service ）。呼叫中心能力平台云服务，是云呼叫中心CCaaS能力的API封装和云化。

以上概念，常用于对齐国外产品标准化名称，国内的各厂商往往名字起的五花八门，注意自行鉴别。

二、产品形态

CPaaS的产品形式，基本全部是API接口，用户需要自行组装，等于是建筑材料。

CCaaS是即开即用的云呼叫中心产品，厂商提供从通信资源到全部功能的产品，用户即开即用，拎包入住，相当于精装修房。

CCPaaS，厂商有完整的云呼叫中心，全部或大部分以API接口的方式提供用户，用户拿到后，需要根据接口再二次开发集成，相当于毛坯房。

三、CCPaaS客户典型特征

1. 行业龙头或新锐

一般各细分领域的Top客户和新贵企业，常常是CCPaaS的潜在客户。

对于小型初创阶段的企业来说，选择CCaaS型云呼叫中心是更佳的选择：不必投入研发资源，快速验证业务，提供满足当前客户量的服务和营销能力。

但是当企业已进入快速发展期，企业管理精细化、数字化，常常会转向CCPaaS选型。

2. 数据私密性

有自研或者自购的业务系统，一般包括CRM，ERP、OA、业务系统，订单系统等等。

对数据保密要求高，不想放到厂商的CCaaS系统上。这种情况下，会选择本地保存数据，使用CCPaaS完成云呼叫中心功能的集成。

3. 业务规模大

选择使用CCPaaS集成的客户，业务发展快速、体量一般比较高。如果是外呼型，规模常常数百到几千座席。

正因为体量大，所以一般都需要完善的数字化系统进行管理，对任何接入的服务，都需要纳入企业管理系统。

4. 自研能力强

常常都有自己的专属研发团队，选型阶段，客户的产品研发部门便会参与进来，对厂商的CCPaaS接口进行评估。

进入开发阶段会按照业务方的需求确定产品设计和开发工期，与厂商配合对CCPaaS接口进行开发、联调、测试和上线。

并且在上线后，持续监控、维护、优化和迭代。

5. 技术要求高

对厂商的公司实力、技术能力、行业地位都有要求，讲究一个门当户对。

同时在技术层面上，对架构设计、接口能力、安全性、网络情况、服务支撑能力都有更高的要求。

以上都有可能是选型阶段重要评分标准。

6. 多服务商并行

还有一个重要的特征：那就是当一个成熟的CCPaaS用户在进行系统应用时，绝不会将鸡蛋都放到一个篮子里，最少需要两家能提供同等全量支撑能力的服务商同时接入。

业务体量巨大的，往往需要更多并行的服务商。

通过CCPaaS接口的整合，向上封装成供应商控制功能，可以根据不同业务、不同地域、不同人员分配给不同的服务商进行使用，支持随时切换。

所以一般遇到某一家服务商故障时，客户不会坐等服务商解决，而是立刻启动切换机制，几分钟之内将业务恢复。

四、客户的两类对接方式

1. 松耦合模式

客户有时候会明确提出需求，希望采用简单对接方式，实现快速上线。

如关键敏感数据信息不传输给供应商，仅做iframe弹屏对接和通话记录数据回传。

这种方式一般常见于客户业务初期，自研系统不完善，甚至是第三方采购系统，要求速度胜于质量，先把业务跑起来再说。

厂商提供2-3个接口供对接使用即可。

松耦合模式下，客户其实使用的是CCaaS系统，大部分功能还是使用CCaaS系统的现成功能，仅部分涉及客户管理模块做一下简单对接。

有时候还要协调多家SaaS系统供应商做配合实现对接。

所以如果是这种模式，其实是CCaaS系统的客户，借助CCaaS系统的标准API接口来实现，而不是典型CCPaaS型的客户。

2. 紧耦合模式

这一种方式才是CCPaaS客户典型场景。

客户希望通过全面的集成，将CCPaaS接口融入到自有系统中来。基本不会使用CCPaaS的任何产品功能。全部要自给自足。

对接的场景包括这几类能力：

1）系统管理类

实现对人员账户的集成控制管理；包括技能组（队列、班组）的管理、座席的管理等。

2）通信资源管理

查询账户中的呼入、外呼资源，用于对应外呼，呼入的接口化调用。

也能支持部分的资源控制功能，比如对外呼号码的配置等。

3）呼叫控制管理

这个是最关键的对接场景，厂商一般会提供标准API和工具条SDK两种模式。

一般来说，客户采用服务端对服务端方式，会选择标准API对接，内部的服务端进行消息分发和控制。

而更简单一些。就用工具条SDK，直接终端集成，借助工具条SDK的功能和消息事件直接实现功能。

两种模式没有优劣之分，客户会根据自己本身产品的架构设计来选型。

4）数据管理

CCPaaS的数据需要通过事件推送回调和标准API查询接口来获取。

如果客户要求实时性较高的获取数据，会使用事件推送或者工具条的实时事件，如果是任务型非实时获取的，比如批量获取通话记录和录音、查询某一个指定座席，某一个指定ID的数据，那可能会用到查询接口。不同的业务场景和集成需求，决定何时使用何种CCPaaS接口能力。

5）产品功能接口

CCPaaS系统的一些功能，如果客户希望集成到自己的产品中使用，也会单独调用这些功能的API来实现。

通常这些功能都是独立的，如外呼任务、智能质检、AI外呼机器人管理等，不使用这些也不影响基本功能的实现。

这类功能都会提供单独的一套接口，客户集成时，会根据这个功能的特点，考虑结合到自己的产品中实现，并向上封装集成。

CCPaaS的大型客户一般都是外呼型，呼入型CCPaaS客户比较难以对接的原因：因为呼入IVR功能相对复杂，很多功能必须结合CCPaaS提供的界面操作来完成。通过CCPaaS接口完整集成难度很大，而且呼入的路由切换难度高。一般需要有非常特殊的技术方案来实现。

<五、CCaaS和CCPaaS合二为一

大家一定有一种疑问：如果CCaaS和CCPaaS，从功能层面上完全一致，那么是不是就是一种产品，两种表现形式呢？有没有必要单独做CCPaaS产品呢？

我们从几个方面来看：

1. 客户群体

CCaaS主要面向中小型企业。

CCPaaS主要是大型企业。

从客户分层、公司资源、收入重要性角度，可以用完全不同的产品线，不同的团队资源投入来单独实现。互不干扰。

看企业的定位，如果是中小为主，CCPaaS需求较少，那么CCaaS优先，反之亦然。

2. 历史沿革

很多企业，其实是完全独立的团队，分别演进，一个是面向SaaS，一个面向PaaS

两个产品，可能从底层架构，实现方式、功能设计都是完全不同的。那么自然就是两种完全不同的产品类型。

3. 演进路径

技术型公司，往往演进到CCPaaS型产品容易，演进到CCaaS型产品会更困难一些。因为后者需要更庞大的组织资源投入。

如果前者可能需要几名行业精英KA级销售、一个技术实力强大的产研团队和实施团队，就可以直接支撑整个产品。

但是CCaaS型产品，需要企业拥有完整的市场营销、产品销售、客户成功、客户服务、技术支持、产品管理、研发测试等等来支撑。

所以很多公司其实就是走到CCPaaS这一步不打算继续前进。

反过来，从CCaaS型有没有到CCPaaS型，如果首先可以解决架构的问题，既可以支撑CCPaaS超级客户的使用，也能够满足大量长尾中小型客户日常使用，互相不会干扰；其次又可以解决企业运营问题，一套平台服务不同的客户都可以高效运转，那也是可以兼容CCaaS和CCPaaS共存的。

技术选型和产品规划没有绝对的正确错误，视你所处的阶段，所拥有的客情，资源情况而定。

以上内容，可以是CCPaaS客户选择供应商的一些标准，当然也是厂商选择CCPaaS型客户的一种手段，欢迎大家对号入座。

本文作者 @通信产品的那些事 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！