2023年一个思考：是否真的存在“小而美”的通信产品

一个思考：是否真的存在“小而美”的通信产品？某高管群里关于国内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）让用户来上手

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