在SaaS行业中，关于“小而美”的讨论一直存在，那么在通讯SaaS产品中，是否存在真正的“小而美”产品？这些产品大多有着什么样的特点？其发展前景又如何呢？本篇文章里，作者就发表了他的看法，不妨来看一下。

某高管群里关于国内SaaS行业是否有“小而美”的产品有过一番讨论，

不过大家不约而同给出了悲观论调，至少在国内目前这个营商环境下，确实很难看到哪一家的“小而美”SaaS产品比较出彩。

那么通信SaaS产品中，是否有“小而美”的产品存在？前景如何呢？

先说结论：通信产品中那些看上去小而美的，其实都是非常重量级的。

01

先说那些看上去“小而美”的通信产品。

1）消息类通信产品

首先如果把消息类产品也算作通信产品的话，可能很多人会认为短信是一个小而美的产品

一定程度上也没错，至少如果你只是集成短信能力，那么需要关注的就是收发接口、数据回持，有点能力的集成商用不了1-2天就可以把短信接入到自己的应用中来。

但对于短信运营厂家来说，构架短信平台所需要的关注事情，包括但不限于上游资源管理，数据调度，数据风控、上游结算，租户计费管理，代理模式设计等等。如果做的是5G消息类产品，在上游能力封装和应用设计上，还要增加更多特性。

2）云通信类产品

从最简单的语音通知、语音验证码、双向呼叫、到相对复杂一些的隐私呼叫业务。

云通信类产品的应用形式，对使用者来说算是“小而美”的，只需要简单的接口集成，即可在所需场景中嵌入通信能力。

但是同样，对于厂家来说，要做这个事情需要突破几道“次元壁”。

① 资源整合能力

没有上游资源，甚至是优势的资源，云通信这个产品的商业模式不可成立，没有人需要一套纯能力系统，本质上你提供的是基于资源的一种场景化包装，客户为之买单的也是资源的明码标价。

② 通信调度能力

有资源，也要有能力玩得转。我前篇在关于通信类产品的分类中也提到过，外行人看这个行业，最不容易看穿的技术壁垒就是厂家的通信调度能力，作为入门级要求，最少需要对软交换技术和云计算架构能力有很强的技术储备。

③ 高并发处理能力

不谈互联网类应用的2C场景高并发，云通信的高并发场景也是检验一个厂商技术能力的试金石。哪怕简简单单的一个开课前通知业务，必须限定时间内完成所有峰值通话要求，就要考验厂家们对于呼叫并发调度、通信资源管理、录音处理和转换、接口请求控制、数据生成和推送等都必须可以支撑。没有几年耕耘和排雷，打造不出来坚实的产品。

最后还有这个隐私呼叫类产品，我个人习惯把它认为是云通信产品“皇冠上的明珠”，应互联网场景而生，随互联网应用而丰富。

要实现这个产品的应用，首先是对场景的深入理解，对使用者，必须能够对隐私保护场景做好定义，然后对应到隐私呼叫的一类产品类型中。除了AXB隐私呼叫之外，这么多年的发展过去，很多模式的定义全行业仍然不能取得共识：比如这些模式：AXN，AX、XB、AXG，AXXx，AXYB？

这就导致要开展这个业务，还要和客户对一遍暗号，确认是自己人，然后再开枪。

确实没必要，本身已经不是那么美了，还要凭添认知障碍。

这些看上去“小而美”的产品们，我们可以发现一个显著特点：

主打的就是一个低毛利！

在有信息差的年代，借助上下游水位之差，还可以躺在这些产品上获利，奈何任何一个行业都有卷王们存在，现在运营这样的产品，基本上都是“毫厘之间”，所以厂商必然开始自我迭代，就应运而生那些看上去“大而不太美”的产品。

“大而不太美”的那些通信产品：

大家发现我其实还是很客气的，没有直接说大而不美，毕竟还是这个行业从业人士，不想成为全员公敌，行业冥灯。

而且毕竟这么多年来，无数有理想艰苦奋斗的公司前仆后继，还是打造出了一代代传奇产品。

但是总体来看。通信类产品中这些顶级产品类型，大部分情况下还是“不美”

说的就是你们，通信产品御三家：云电销、呼叫中心、在线客服，外加一个新贵：AI机器人！

为什么，我们先拷问下这些应用型SaaS通信产品，本质上是什么？

其本质设计是管理需求，产出物必然是反人性的。

1）电销产品

必须要监管使用者的电话量，通话时长，还要用批量任务让他们定时定量的完成，发现大家还是习惯性摸鱼，那就上预测式外呼加机器人，最好让使用者每一分钟都有效工作，持续产出。

2）呼叫中心

企业处理热线和在线咨询是有指标约束的，从服务水平到进线平均等候时长，从空闲时长到小休状态、从摘机时间到挂机满意度调查。你看每一项的设置都是针对你的，你完成的工作有没有问题，你做的事情有没有结果，让客户评价一遍，质检人员再评价一遍。而且现场随时有在线监控，有人能随时监听你的通话和会话，最后每天早会晚会分析复盘数据情况，排个榜单出来，排名靠后出来吊打一番。

3）在线客服

使用者和呼叫中心一样，必须带着响应率，响应时长，解决率、满意度的压力来完成，现在前面加个机器人，帮助你们把客户筛选一遍，经过那些不是太会说人话的机器人信息处理后，仍然执意转人工进来的客户，情绪一般来说都不会太稳定。你就说这压力大不大吧。

在这样的前提下，厂商要提供的产品，你觉得是迎合使用者，还是监管者呢？一定是谁付费迎合谁。

那么对应的功能设计，产品迭代，一贯紧跟管理需求，只是这些产品最大的那些用户群体？他们的使用体验和声音，优先级是不是要低一些呢？这些天天都在高强度使用的用户，如何去评价你“美还是不美”？

通信产品的深厚底座，叠加了行业多年积累的通用性管理经验，共同打造出了复制的通信应用类产品，

而随着管理需求的深入，随着AI能力的进步，产品本身也变得越来越重：

当前你打开任何一个产品，琳琅满目的功能、不知所谓的用语、语焉不详的帮助、前后矛盾的流程，

从入门到精通需要点心态和毅力，心态崩了，从入门到放弃后，就需要厂商的贴身服务了。这样的产品“美还是不美”呢？

02

产品人应该做什么事？

在这个行业，要做通信类SaaS产品，我建议大家先秉持以下原则：

1）少抄同行，眼光向外

圈子越小的地方，技能越是封闭，大家如果做什么，都去高仿下友商，知其然不知其所以然，你怎么知道别人是不是瞎捉摸的凑工期的产物呢？抬头多看看窗外的好风景。

2）细节入手，关注人性

用户在使用你的系统，你推出的产品，如果做不到让他们眼前一亮，最少也不要添堵。

把专业用语做规范了，把页面操作逻辑理清楚了，把提示信息做清楚了。这些要求不过分吧。

基于此，你考虑到让使用者少滚动些鼠标，少设置些开关，能省一步的操作就省一步。

你把屁股坐到用户身上去才能发现和看到这些问题。多往客户那边跑跑，挨骂多了自然就进步了。

3）少谈功能，多谈价值

功能是死板的，用户使用中带来什么价值。必须能够通过各种方式量化和展示。

一组功能的使用，要从最终使用场景去倒推设计方式，而不是和用户抬杠：我不要你觉得，我要我觉得。

你能给你的用户创造多少带来实际真金白银利益的价值，你提炼的产品就越强大。

4）让用户来上手

有一个不好的趋势：越是复杂，设计的功能越是庞大臃肿，最后搞得用户实在用不起来了。这时候必须得配个技术支持，一个客户成功，搞不好还得搭上产品经理，美其名曰：项目化服务，其实是糟糕的设计需要人力成本来擦屁股。

一个公司要投多少人力成本去运营这些，人均单产就是这样被一步步拉低的。

说了这么多不小和不美，只提出问题，不解决，站着说话不腰疼，那你说怎么办才好？

其实开立这个号的初衷，就是想和行业同仁分享一些产品思路的。就是想把这些年做产品踩过的坑，遇到的问题，想到的困惑整理下，包括我一直想做的一些事情。