前两天跟一个做电商的朋友聊天，他给我看了一张照片。
一整个抽屉，塞满了手机。
不是什么好手机，全是那种百来块的老年机、备用机，插着各种运营商的卡，一台绑一个店。我数了一下，光这个抽屉里就四十多台。
他说这还只是一部分，公司里还有两个这样的抽屉。
我当时就乐了，我说你这是开手机博物馆呢。
他苦笑，说没办法啊，三百多个店，拼多多、抖音、小红书、公众号，每个店注册的时候都要手机号，每个店隔三差五都要收验证码，登录要码、改价要码、提现要码、解封还要码。不绑手机号没法活，绑了手机号就得有人盯着收码。
我说那你们怎么收的。
他说，能怎么收，群里喊呗。运营要登录拼多多某店，就在群里吼一声「谁拿着那个号，码发我一下」，然后管手机的那个人翻抽屉、开手机、看短信、截图发群里。
有时候码到了没人看，等想起来的时候过期了，得重新发。
有时候两个人同时要不同店的码，管手机的一个人手忙脚乱。
有时候员工离职了，手机跟着人走了，号也带走了，那个店就失联了。
他说最离谱的一次，一个运营离职之后，用带走的号把店铺提现账户改了，等公司发现的时候钱已经走了。
说到这儿他叹了口气，说我也知道这么搞不是办法，但你给我个方案啊，几百个店，几十个员工，我总不能给每个人配几十台手机吧。
我当时没接话，因为我确实也没现成的答案。
回来之后我就一直惦记这个事儿，顺手搜了一圈。
还真让我翻到一个东西。
叫 N+SMS Routing，中文名讯路由。说实话第一眼看到这个名字我是有点懵的，路由？短信还要路由？短信不就是手机收到、人看一眼就完了吗，路由个啥。
但我往下看了一眼它的思路，突然就反应过来了。
这玩意儿不是手机，是一个专用硬件盒子。你把几百张 SIM 卡分别插进盒子，插上电，它就替你收所有短信。然后它后面挂一个 SaaS 后台，你在网页上写规则，告诉它哪条短信该送去哪儿。
送到哪儿呢，送到企业微信、钉钉、飞书的群里，或者通过 Webhook 推到你自己的系统里。
我给你捋一下它跟那个「一抽屉手机」的区别。
抽屉手机方案，是每个店绑一台手机，每个手机绑一个人，人去找手机，手机等短信。这是「一对一硬绑」，店越多手机越多，人越多扯皮越多。
讯路由的思路完全反过来。卡全部集中到一个盒子里，物理上不分给任何人，但逻辑上用规则把短信分流到不同的群、不同的人眼前。
你想想看，这事儿是不是有点眼熟。
像不像邮局。
邮局不会给每个人配一个专属邮递员，邮递员也不认识你。邮局干的事儿是，所有信先堆到一个分拣中心，然后按邮编、按地址、按规则，分到不同的投递段。邮编对上了就往这条线送，地址对上了就往那条线送。
讯路由干的就是这个事儿，只不过分拣的对象从信件变成了短信，分拣的依据从邮编变成了正则和关键词。
我跟你说，想到这儿的时候我有点兴奋。
因为我朋友那个问题，突然就有解了。
我接着往下看，发现这个「规则驱动」比我想的还要细。
它路由规则可以按好几个维度来写。
按平台分，短信内容里包含「拼多多」三个字，推到拼多多运营群；包含「抖店」，推到抖音客服的飞书群。
按店铺编号分，比如你给每个店编个号，【店A-8841】开头的短信推给 A 组，【店B-5520】开头的推给 B 组。
按业务分，金蝶云、阿里云这种验证码推到技术群或者财务群。
而且一张卡可以同时命中好几条规则，物理上集中，逻辑上切到不同的群。
说到这儿可能有人纳闷，一张卡同时命中多条规则，不会乱吗？
不会。规则的优先级是你自己定的，谁先谁后后台里排得清清楚楚，命中的就推，没命中的就不推，跟写代码里的 if-else 一个道理，只不过它把这个 if-else 做成了可视化拖拽，不用你真去敲正则，点点鼠标的事儿。
我朋友那个场景，三百个店，按平台建一级群，拼多多群、抖音群、小红书群、公众号群，群里面再用店铺编号关键字二次分流到子群。SIM 卡命名规范一下，PDD-001 到 PDD-120 是拼多多的，DY-001 到 DY-080 是抖音的，路由规则引用前缀就行。
新增一个店铺怎么办？加一张卡，加一条规则，架构不用动。
我朋友那个抽屉，以后大概可以锁起来了。
但光把短信送到群里还不够，我朋友真正头疼的另一半是权限。
你想啊，三百个店，几十个运营，不可能每个人都看所有店的码。小张负责拼多多 1 到 50 号店，他不该看到抖音的码；老王是主管，要看全盘；新来的实习生只管三个店，其他的碰都不该碰。
传统 ERP 的思路是，给每个子账号勾选他能看哪些店铺，三百个店勾一遍，光配置就够你喝一壶的，而且每加一个店、每换一个人都要重新勾。
讯路由这块儿走的是另一条路。
它不靠「子账号绑店铺 ID」这种硬绑定，而是靠两层东西把权限圈住。
第一层是 IM 群本身。
你不是按店铺建了群吗，小张只在「拼多多店 1-50」这个群里，那他天然就只能看到这 50 个店的码，因为别的群他压根进不去。群成员身份就是第一道权限墙，不需要你在后台一个个勾。
而且这一层是毫秒级推送的，短信到了盒子，盒子匹配规则，推到群，平均 1.5 秒。员工连后台都不用登，群里直接看，比登系统查还快。
第二层是 SaaS 后台的子账号。
群解决的是「日常收码」，后台子账号解决的是「审计和回填」。后台把三个权限拆开了，收短信是硬件层干的事儿，员工控制不了；看短信是后台的查看和搜索权限；改路由规则只有管理员能碰。
你可以建员工子账号，限制他登录后台之后只能筛某些标签、某些分组的短信。A 员工登录筛 tag 等于店群 A，B 员工筛 tag 等于店群 B，互相看不见对方负责的店。
专业版往上还开放 Webhook 和 API，你们开发团队可以直接把某店铺的短信以 JSON 推到内部系统，验证码自动回填到你们的 ERP 里，员工连短信原文都不用看，机器对机器就闭环了。
我跟我朋友讲到这儿的时候，他插了一句，说那员工离职怎么办。
这个问题问得好，也是我最想聊的一点。
传统的抽屉手机方案，员工离职是个灾难。手机在他手上，号在他手上，短信记录在他手上，他走了这些东西跟着走，你拦都拦不住。
讯路由这套架构底下，员工离职就三步。
把他从 IM 群里移出去，码他再也收不到了。在后台禁用他的子账号，历史短信他也登不进去看了。实体卡呢，一动不动还在机房那个盒子里插着，信息带不走，号码丢不了。
后台还有风控审计，谁在什么时间看了哪条短信，全有记录。出了事儿能追到人。
还有一个细节我觉得挺狠的。
它从硬件固件层面把发送功能锁死了，这盒子只能收短信，不能发短信。
你可能会想，收就收呗，干嘛非要锁死发送。
我给你讲个背景你就懂了。手机号码集中管理这件事，最怕的是什么，是灰产。一堆号攥在手里，要是能发短信，拿去群发、拿去搞诈骗、拿去注册灰号，运营商一监测到异常直接停机，你这几百个店的号全废了，而且可能还要担责任。
它从源头把这个口子堵死了，只能收不能发，你想拿它干坏事都没门。这个设计我觉得是站在企业主的角度想的，不是站在极客觉得酷的角度想的。
我朋友听完这段沉默了一会儿，说，那这玩意儿贵不贵。
我说我查了一下，它是硬件加订阅的模式，专业版 99 块一个月，硬件要买或者租。你算算你现在养那几十台手机、养那个专门管手机的人、再加上丢号丢钱的风险，哪个贵。
他没说话，我知道他在算账。
聊到这儿我其实想往深了说两句。
我朋友那个抽屉，表面上看是个工具问题，背后其实是个组织问题。
几百个店、几十个人，验证码这件事的本质是信息要在对的时间到对的人手里。抽屉手机方案是用「物」来解决这个问题的，一个店一台手机一个人，物越多接口越多，接口越多越容易出岔子。
讯路由是用「规则」来解决的，物集中在一起，靠规则把信息分流到该去的地方。
你想想看，这个转变是不是有点眼熟。
早年打电话，是电路交换。你拨一个号，电话局给你拉一条专线，从你这儿一直拉到对方那儿，这条线在你们通话期间归你们独占，别人用不了。线不够了就占不上，打不通。
后来互联网起来了，用的是分组交换。所有数据打成小包，混在一起跑，到了节点按地址分流，各走各的，谁也不独占一条线。线路利用率一下子上去了，网络也才能撑住今天这个规模。
电路交换是「为每对通话配一条专线」，分组交换是「所有包共享网络，靠地址路由」。
抽屉手机是电路交换，一店一线，一线一人。
讯路由是分组交换，卡集中，规则路由。
通信行业花了几十年从电路交换走到分组交换，才有了今天的互联网。我朋友那个抽屉，不过是还停在几十年前罢了。
这不是他的错，绝大多数小公司都停在那儿，因为没有工具，只能用最笨的「一对一硬绑」去扛。工具没出现之前，你没法怪人用蛮力。
但工具出现之后，还用蛮力，那就是选择问题了。
我有时候觉得，很多老板对「管理工具」这件事有个误区，觉得工具就是买个软件、装个系统、大家学着用。
但其实好工具改变的不是「效率」，是「结构」。
抽屉手机那个结构，是「人盯物」，加一个店就加一台手机加一份盯的功夫，线性增长，人迟早盯不过来。
讯路由那个结构，是「规则盯物」，加一个店加一条规则，规则是写一次跑无数次的东西，它不随店铺数线性膨胀。
你从「人盯物」切到「规则盯物」，加店铺的边际成本就从一个人变成了一条正则。这才是工具真正的价值，不是让你干得更快，是让你干得不再那么累。
我跟我朋友说，你要是真有几百个店，别一上来就一店一规则写死，按我说的来，先按平台建一级群，群内用店铺编号二次分流，SIM 卡命名规范好，子账号分角色，运营只看、组长能筛、管理员改规则加审计、开发对接 Webhook。架构搭对了，后面加店就是加卡加规则的事儿，不用重构。
他说明白了，回头让技术去试试。
我说你先别急着上几百个店，先拿十来个店跑通，把规则调顺了，把群和子账号的权限边界摸清楚了，再往里灌。这玩意儿跟写代码一个道理，先跑通再优化，一上来就铺满容易翻车。
他笑了，说你这话跟产品经理一个味儿。
我说我就是被产品经理折磨过才学会的。
最后说几句掏心窝子的话。
我写这篇不是给讯路由打广告，我跟这产品没任何关系，纯粹是朋友那个抽屉把我戳到了，然后我顺手挖出来一个还不错的解法，觉得可能不少做电商、做 MCN、做矩阵号的朋友都有类似的痛，就写出来分享。
这工具也不是没毛病。我查的时候看到几个点你得心里有数，一个是它依赖 SIM 卡自带的基础流量联网推送，一个月大概 10 到 30 兆，你要是用的那种纯零月租保号卡可能流量不够，得确认一下。另一个是硬件要买或者租，有一笔前期投入，店少的话可能算下来不如继续用笨办法，它真正划算是在规模起来之后，几十张卡往上才明显。还有它后台配置规则虽然做了可视化，但正则这东西对完全没接触过的人还是有点门槛，刚开始可能得摸索一阵子。
我自己还没亲手部署过这套东西，以上都是基于它的公开资料和我自己理解的架构推演出来的，具体延迟、稳定性、规则边界这些，得你们真上手跑了才知道。我说「理论上」是因为我自己还没完全跑通，不敢把话说满。
但方向我是认的。
从「人盯物」到「规则盯物」，这个方向我坚信是对的。不是因为讯路由这个产品多牛，是因为这个思路本身就跟通信行业几十年前走过的路是一样的，从专线到路由，从硬绑到解耦，凡是这么走的行业，最后都撑住了规模，凡是死扛一对一硬绑的，最后都被规模压垮。
我朋友那个抽屉，迟早要被收起来。
问题只是他自己收，还是被规模逼着收。
/ 注意，本项目仅在 SyncMein 的500人小群分享。
/ 谢谢你看完了我的文章，我们下次再见吧。
/ 作者：明察
/ 投稿或爆料，请联系邮箱：mingcha@gqmg.com
暂无评论内容