上个月去见一个做建材批发的客户，他掏出手机给我看他们刚上线的小程序，说花了八万，做了四个月。我点开首页，要加载三秒，进去之后是一个商城，分类乱七八糟。我问他：你的业务员平时用这个干什么？他愣了一下说：他们是给我导客户用的，不常用。我就知道这八万块，又交学费了。
先搞清“业务应用”和“电商小程序”的区别
市面上大部分模板小程序，骨子里都是卖货的。商品、购物车、订单、支付，一条线走到底。但企业内部的业务应用，逻辑完全不一样。
比如一个做设备租赁的公司，他们的业务员每天要做的是：查这台设备在哪个工地、上次保养是哪天、客户欠款结清没有。这些动作里没有购物车，也不需要支付。小程序对他们来说，是一个装在手机上的内部工具，而不是一个面向消费者的店铺。
我见过最离谱的一个项目，是给一个物业公司做报修系统。开发方硬生生套了一个商城模板，把“报修”做成“下单”，把“维修工”做成“商品”。结果保洁阿姨根本找不到入口，最后还是在微信群里发语音。这就是没分清业务应用和电商的区别。前者是流程驱动，后者是交易驱动。
权限设计偷懒，后面全是补丁
业务应用绕不开角色。老板看报表，区域经理看本区数据，业务员只看自己的客户。很多开发团队为了赶进度，权限这块就写死一个“管理员”和“普通用户”。上线之后，区域经理说我能看到隔壁区的数据，不行。于是加一个字段判断。过两天财务说我也要进来看，又加一个判断。三个月后，代码里全是 if else，改一个权限要动五个文件。
我们在做建沅网络自己的客户项目时，吃过这个亏。后来定了一个死规矩：小程序立项第一周，不写页面，先把角色和权限矩阵画出来。谁，在什么场景下，能看到什么数据，能执行什么操作。这张表确认签字了，再动手。多花三天，后面省三个月。
具体怎么做？你可以让业务负责人列一张表，左边是岗位名称，上面是功能模块，交叉的地方填“可见”“可编辑”“不可见”。这张表就是开发团队的施工图。别嫌土，管用。
别把小程序当App做，但该有的离线能力要有
微信小程序的包大小限制是2M，主包超过这个数就传不上去。有些老板不懂，说我要做二十个功能模块，每个都要有。开发说做不了，老板就觉得技术不行。
其实分包可以解决一部分问题，但更关键的思路是：业务应用不需要所有功能都塞进小程序。比如复杂的报表导出、批量数据处理，完全可以放在PC后台，小程序只做现场采集和查询。一个做巡店管理的客户，业务员在小程序上只做三件事：拍照、打分、提交。剩下的统计分析全在后台。小程序包很小，打开快，业务员也愿意用。
另一个容易忽略的是网络。仓库、工地、地下车库，信号经常只有一格。如果提交表单时网络断了，数据直接丢失，业务员会骂人的。所以本地缓存和断网重提交，是业务应用的基本功。这一点在立项时就要和开发确认：断网了怎么办？数据存哪？恢复网络后怎么同步？
上线不是终点，是起点
很多企业把小程序上线当成项目结束，验收、付款、散伙。但业务应用真正的问题，都是上线之后才冒出来的。
我建议你在合同里加一条：上线后第一个月，开发方每周至少留一天做现场支持。不是远程，是到现场，看业务员怎么用。我们有个客户，上线第一周业务员反馈说“提交按钮太小，戴手套点不到”。这是个在办公室永远发现不了的问题。开发到现场，把按钮高度从40px改成56px，投诉就没了。
另外，数据埋点要从第一天就做。不需要多复杂，关键路径的点击、提交成功率、平均耗时，这三个数就够。过了一个月，你看数据就知道哪个环节卡住了，而不是靠猜。
作为管理者，你现在能做的其实不多，但很关键。第一，立项时把业务负责人拉进来，别只让IT部门对接。第二，权限矩阵表让业务负责人签字，别口头说。第三，合同里写明上线后一个月的现场支持条款。这三件事做到，项目失败的概率能降一半。
说回开头那个客户
后来我们帮他重新梳理了业务流程，把商城砍掉，只留了三个功能：客户查询、开单、欠款提醒。页面从十一个减到四个，包大小降到800K。业务员现在每天主动打开，因为确实省事。
小程序不是面子工程，它是干活的工具。工具好不好，用的人说了算。如果你手头正有一个小程序项目在推进，不妨这周先别催开发进度，把业务负责人和一线员工叫到一起，问一句：你平时最烦的操作是什么？答案往往就是你最该先做的功能。