当互联网产品方法论撞上武装押运行业，竞品、报告、访谈全部失灵。作者从通读法规、跟车拆解流程到重构五种终端，用324个菜单的教训换回一条铁律：B端产品比的不是功能多，而是入口少。本文复盘了那些撞墙后才想明白的事，告诉你数字化如何让对账、扯皮和客服电话都变少。

做互联网产品，动手前有三件事：拉竞品、读行业报告、约用户访谈。两年前我开始负责武装押运行业的数字化产品，第一周就把这三件事全做了——每件都没做出结果。

应用商店里搜不到能参考的押运系统；行业报告里，“武装押运”通常只在安防产业报告的角落里占一段；用户访谈倒是约得上，但一位干了十几年的车长听完我的问题，反问了一句：“你们做系统的，能不能先搞清楚我们一天是怎么过的？”

这句话成了我做这个行业产品的分水岭。下面这些事，都是撞了墙才想明白的。

一、需求的一半，写在法规里

接手产品后我做的第一件“不像产品经理”的事，是把两部法规打印出来通读：《专职守护押运人员枪支使用管理条例》和《保安服务管理条例》。

起因是一场需求评审。客户要求系统里加“出勤酒测”，我当时的反应是：这不就是考勤管理的锦上添花？客户的安全负责人把条例翻到第十二条念给我听——严禁携带枪支、弹药饮酒或者酒后携带枪支、弹药。

酒后不能碰枪，不是哪家公司的管理创新，是国家层面的红线。落到产品里，酒测就不是可选项，而是涉枪岗位排班的前置校验：酒测不合格的人，当天自动退出涉枪任务的候选名单。这条逻辑不是产品经理设计的，是条文翻译成系统的结果。

类似的例子还有很多。枪支管理是每天领、每天还：出勤前从枪库领，任务结束立即交还，枪弹分离存放、双人双锁。系统要做的就是让这笔账清楚——今天出了几支枪、回了几支枪，每一支对应哪个任务、哪个押运员，差异当天可见。以前这靠手写登记簿，月底盘点对不上，只能一支支往回翻记录。

所以在这个行业做需求，我的习惯变了：拿到需求先问一句“这条是哪个条文、哪次事故定的”。背后有依据的，字段和流程照着做，别自作聪明简化；答不上来的，再和客户一起确认它到底要解决什么问题。法规是这个行业最硬的需求文档，只是它不会告诉你交互怎么做。

二、一趟押运，拆成八个阶段

没跟过车之前，我对押运的理解是“取钱、送钱、回来”。跟着车队跑了一周，才知道这趟活拆开是八个阶段：线路创建激活、队员考勤酒测、领取枪支钥匙物品、金库出库、网点预扫、网点交接、金库入库、归还枪支钥匙物品。

每个阶段拆出来都有理由。比如网点预扫——押运车到网点前，网点人员先对交接箱扫码确认。最早的设计里，我觉得这步和“网点交接”重复，砍掉了。上线一个月，交接错箱的纠纷多了起来：网点说送错了箱，车队说箱是按单送的，谁也拿不出证据。把预扫加回来，交接前先扫箱号、系统校验任务单，错箱当场拦住，而不是第二天对账时扯皮。

这件事给我的教训很具体：流程里看起来冗余的环节，很多是事故换来的，动它之前先问清楚来历。行业老师傅一句“一直都是这么干的”，背后可能是一次被抢的经历、一场对不上账的纠纷。产品经理要做的不是删环节，是搞清楚这个环节防的是什么。

还有一件小事加深了这个印象。金库出库的时间比大多数人上班早得多，凌晨库里就要开始点箱、核封签。我们原以为交接拍照会拖慢流程，一线却主动要求加：出了纠纷，照片就是押运员自证的证据。留痕不是管理者要管的工具，也是一线要用的护身符。

三、五种终端，五种场景

这个产品的角色复杂度也超出了我之前的经验。同一场押运业务，牵涉的角色有：公司调度、车长、押运员、司机、金库管理员、网点人员、银行客户，外加公安监管要求。

一开始我们想用“一个后台加权限树”解决所有人，很快发现行不通。同样是“交接”这个动作：

押运员在网点门口，一手拎箱一手警戒，操作必须单手、扫码、几秒内完成；网点人员要的是核对快，箱号、封签、金额一眼看完；公司调度要的是证据链，谁交的、谁接的、几点几分、有没有拍照；银行要的是可查询的记录和报表。

最后产品落成了五种终端形态：调度后台（Web）、押运员APP、网点助手、指挥中心大屏，加上智能枪柜、交接柜这些物联网终端。权限树只是底座，真正的设计是按场景拆交互——同一个业务动作，不同角色看到的字段、按钮、流程深度都不一样。

数据大屏这块我们走过弯路。第一版大屏做得很炫，领导参观时效果好，日常没人开。后来指挥中心提了个需求：盯网点交接准点率——早送晚接，哪家网点经常超时、超时两次就预警。这个功能没有任何视觉设计可言，就是几张趋势图加一个预警列表，但它是调度每天真用的东西。大屏的价值不在展示，在有人盯着它做决策。

四、324个菜单给我的警告

去年我们梳理过一套在行业里跑了多年的押运系统，把菜单树完整拉了一遍：16个一级分组，324个叶子菜单。

其中“人员统计表”分组和“图形报表”分组的11项功能完全重复；“合同管理”有两个同名入口，指向两套不同的页面；统计报表一个分组下面堆了89张报表，没有分类。而新功能还在源源不断往里加——客户的合理诉求永远存在，“能不能再加一张表”，谁也拒绝不了。

但功能堆砌的成本，最后都压在最一线的用户身上。押运行业一线人员年龄结构偏大，菜单层级深一层、入口换个位置，客服电话就多一批；培训一个新调度，面对324个菜单，光记入口就要半个月。

这件事之后我们给自己定了两条规矩。

一是信息架构定期体检。重复的合并、没人用的下线，拿操作日志说话——一个菜单半年没人点，就有足够的理由和客户谈下线。拿数据和客户谈，比自己拍脑袋说服力强得多。

二是新需求默认先问“能不能并进已有入口”。把“新开一个菜单”从默认动作，变成需要论证的例外。

B端产品做到后面，比的不是谁功能多，是谁的入口更少。

五、数字化到底改变了什么

这两年复盘，我尽量不说颠覆、重塑这类词。数字化在这个行业带来的变化，具体到有点朴素：

交接从手写三联单变成电子留痕，纠纷从各说各话变成看记录；枪弹领还逐支逐发对账，账实差异从月底盘点才能发现，变成当天可见；网点交接有了准点率数据，“哪家网点总超时”从吵架时的印象，变成双方可以坐下来一起看的东西。

做C端产品的时候，我看日活、留存、转化漏斗。做这个行业的产品，我看三件事：对账平不平、扯皮少没少、客服电话降没降。

让一个跑了二十多年、靠手写登记簿和老师傅记忆支撑的行业，把账放进系统里，这个过程每一步都很慢。慢有慢的道理——每一笔账背后都是责任。责任面前，系统跑得比纸快就够了，比纸可靠才是关键。