猫拽智库
结论先行：低代码推不动，通常不是技术问题，而是上线那天就没人打算真正用它。员工不用的六个原因很稳定：需求做给领导看、双系统并存、流程节点变多、移动端难用、数据不归业务部门、上线后没有运维 owner。判断推广是否成功只看两个数：周活跃人数，以及被真正替代掉的 Excel 和微信群。
一、先别看开通数，看最后一次登录
项目验收时最常汇报的指标是「账号开通率」，这个数字几乎是 100%，因为账号是批量导入的。它证明不了任何事。
真正该看的是两个数：过去七天里有多少人至少打开过一次；这些人里有多少人在系统内完成了原本要发微信、要填 Excel 的那件事。前者是触达，后者是替代。只有替代发生，系统才算活下来。
如果周活跃人数在第二个月开始下滑，说明种子用户的新鲜感已经用完，而普通员工从未被说服。这时候加培训、发通知都没用，得回到需求本身查原因。
二、六个原因：症状、根因与对策
下面六条是按出现频率排序的。前三条决定员工「愿不愿意开始用」，后三条决定员工「能不能一直用下去」。
| 症状 | 根因 | 对策 |
|---|---|---|
| 领导很满意，一线只在被检查时打开 | 需求来自汇报场景，不是日常工作流 | 把需求评审搬到工位上，让实际操作的人描述一天的动线，按动线重排表单顺序 |
| 旧系统还在，两边都要填 | 迁移只做了一半，或旧系统因合规原因无法下线 | 先划一条明确的切换日，旧系统改为只读；确实不能下线的，做单向同步而不是双填 |
| 原来三步审批，现在七步 | 上线时把「管控诉求」全部塞进流程 | 按金额和风险分级，低风险单据走单节点；节点数写进流程规范，超过五个要评审 |
| 员工宁愿在微信里说一句 | 移动端要登录、要跳转、要等加载，路径比微信长 | 做移动端闭环：免密进入、消息卡片直接处理、结果回推到群 |
| 填完的数据业务部门拿不到 | 数据归 IT 或平台方管理，业务方没有导出和使用权 | 明确数据 owner，给业务部门开放查询与导出权限，报表由业务方自己定义 |
| 出问题没人管，工单在群里石沉大海 | 上线后没有指定的运维负责人 | 指定一名 owner，公布响应时限和问题入口，每周公示处理结果 |
三、四个最容易被低估的细节
流程节点是员工用不用的一票否决项
上线一个新系统，最常见的副作用是审批变多。原因是每个部门都借这次机会把自己的管控要求写进流程：多一个复核、多一个抄送、多一个附件要求。对管理者来说是「规范」，对员工来说是「更麻烦」。
可控的做法是按风险分级。低金额、低风险的单据走一到两个节点，高风险才走完整链路。流程设计的通用方法可以参考 OA 审批流的三个实战案例，那篇对节点合并与条件路由讲得比较细。
移动端不是「能打开」就算完成
很多低代码应用在手机浏览器里能显示，但登录要输账号密码、列表加载要等三秒、审批要点进详情页再点提交。员工在微信里说一句「批了」只要两秒，走系统要两分钟，选择不言而喻。
移动端闭环的最低要求是三条：一次登录长期有效、待办消息能直接跳到处理页、处理结果能回推到原来的群聊。三条缺一条，员工就会退回微信。
数据归属决定业务部门是否维护它
如果业务部门填完数据却查不到、导不出、改不了，他们会认定这是「给 IT 填的表」，录入质量立刻下降。数据归属要在上线前就写清楚：谁负责录入、谁能查询、谁能导出、错误数据由谁修正。
没有运维 owner，前三条都会失效
系统上线后的问题分为三类：数据填错、权限不对、功能异常。三类问题如果没有明确的分流入口，全部会涌向项目负责人，两周后他就不再回复了。指定 owner 并公布响应时限，比再做一个功能更能保住使用率。
owner 的归属要看部署方式。自托管平台（例如 Apache-2.0 的猫拽低代码 CatPull）由 IT 运维承担；SaaS 平台则要确认厂商的工单响应时限已经写进服务协议。
四、30 天推广节奏
推广不是发通知，是按周推进的四个动作。每周都有可验收的产出，做不完就不要进入下一周。
| 周次 | 动作 | 产出 | 验收方式 |
|---|---|---|---|
| 第 1 周 | 找 3 个种子用户，坐在他们旁边看一天的工作 | 三条真实使用动线，每条不超过五步 | 种子用户能独立完成一次完整业务，不需要人在旁边指导 |
| 第 2 周 | 砍流程节点，合并重复审批与冗余抄送 | 核心单据节点数下降，平均处理时长缩短 | 同一张单据的审批步数比旧流程少 |
| 第 3 周 | 做移动端闭环：免密登录、消息直达、结果回推 | 手机端可完成提交与审批全流程 | 种子用户连续三天只用手机处理待办 |
| 第 4 周 | 公布使用数据与问题响应机制 | 周活跃看板、问题处理时限、owner 名单 | 提过问题的员工能在承诺时限内收到反馈 |
这套节奏的关键在第 1 周。种子用户不是「关系好的部门」，而是愿意提意见、且业务量真实的人。选错种子用户，后面三周都会变成自嗨。
五、衡量指标：两个数就够
推广期的指标体系不要复杂，复杂了就会被挑数字。只看两个，其余作为辅助。
- 周活跃人数：过去七天有实际业务操作的去重人数，剔除只登录不操作的账号。连续四周上升才算站稳。
- 替代量：统计被停用的 Excel 模板数量、解散或停止更新的业务微信群数量，以及这些渠道原来的日均消息量。
辅助指标可以看首次完成时间、单据平均处理时长、问题平均响应时长。但不要用「累计注册用户」和「功能使用次数」来汇报，这两个数只会上升，不会告诉你真相。如果系统需要多人协作编辑同一张表，还要额外关注并发编辑时的冲突率，相关判断标准见多人协作能力的评估要点。
推广三个月后如果周活跃仍然靠运营推送维持，说明产品没有进入工作流。此时正确的动作是缩小范围，只保留一个真正被替代的场景做深，而不是继续扩大功能覆盖面。让一线员工自己搭应用，是另一种更彻底的推广方式，但需要配套的模板库与审核机制。
FAQs
Q1：员工说「不好用」，但说不出哪里不好用，怎么办？
A：跟着他做一次真实业务，计时并记录每一次页面跳转和输入。把总耗时拆成登录、查找、填写、提交四段，最长的那段就是问题所在。员工的感受是准确的，描述是不准确的。
Q2：旧系统不能下线，是不是就没法推广？
A：仍可推广，但要改策略：把新系统做成旧系统的上游，数据单向流入旧系统，员工只在新系统录一次。双填是死路，单向同步才有机会。
Q3：推广期要不要设考核指标？
A：不建议把登录次数写进考核，这会催生大量无效点击。可以考核业务单据的线上化率，例如某类报销必须走系统才受理，用流程规则代替行政指标。
