企智社 
前年，团队接了一个连锁服务型企业的项目。对方业务负责人一开口就说：“我们想做个小程序。”我问了一句：“解决什么问题？”他想了下：“让门店上报东西更快。”聊到第三小时，我们才慢慢摸到真实意图：他们缺的不是一个小程序，而是一条从一线到总部、从客户现场到管理后台的连接通道。这个认知偏差，决定了后面所有工作方向，也让我更确认一件事：企业服务里的“定制”，首先定制的不是代码，而是问题识别的逻辑。
第一课：需求不是“小程序”，而是连接
那家企业的场景，在很多 To B 项目里都能看到。督导巡店，拿着纸质检查表，打分、拍照、手写备注，回办公室后录入 Excel。导购做客户回访，记录散在个人微信和本子上，主管要数据只能靠截图。店长要审批优惠价，得找电脑用流程系统，可白天基本被卖场绑住。
我们没有急着出方案，而是跟着一位督导跑了两个门店。他边走边抱怨：微信里是客户群，企业微信里是工作群，两个群消息互相割裂，他每天要来回切换十几次。回到客户办公室，我们画了一张“业务触点与系统触点”的对照图：巡检、报修、回访、审批、通知，对应不同角色、不同终端、不同频率。这张图一出来，客户自己就明白了，他们需要的不是某个“好看的小程序”，而是一个按场景定制的端侧工具，让小程序和企业微信各司其职。
最终方案分三层：小程序是一线员工手上的“采集器”，做定位、拍照、签名、扫码；企业微信应用是管理层和后台的“连接器”，做待办推送、消息卡片、外部联系人管理；中间是一套接口集成层，负责把审批流、数据权限和通知模板串起来。这个结构不炫，但足够贴合真实工作方式。
第二课：把业务语言翻译成技术语言
做需求沟通时，客户会描述“新员工入职后，主管希望在企业微信里直接看到他的待办，而不是一个个拉群”。他们不会说“我需要一个 OAuth 回调”，但他们的描述里已经包含了身份映射、权限继承和消息触达。
我们按照业务动作，把需求拆成了三类关键场景。
第一类是“移动端一次性采集”。比如门店巡检，督导需要选门店、填分值、拍照、定位。我们不需要做复杂表单，但必须支持弱网。后来小程序里加了草稿箱，断网时数据先存本地，信号恢复后自动续传。
第二类是“企业微信主动触达”。待办提醒和人效通知，不能指望员工自己打开小程序刷。企业微信应用可以推送消息，但文案必须讲清楚“为什么处理”和“不处理会怎样”。我们给店长、督导、总部三类角色分别定义消息模板：店长看到的是审批待办，督导看到的是异常预警，总部看到的是今日完成率。
第三类是“客户身份打通”。导购用企业微信加客户，客户要打标签；小程序又要按标签筛选回访名单。这里需要做一套“员工 ID—小程序用户 ID—企业微信外部联系人 ID”的映射关系。没有这层设计，后面所有客户相关功能都是断头路。
我们一直提醒客户：目标不是“做一大堆功能”，而是用定制的流程引擎把这三类动作连起来。同样是巡检，A 区域要求拍照，B 区域要求录语音，这种差异可以用配置实现。但“异常事项必须关联报修单”是企业内部的硬规则，就要写进代码。哪些用配置，哪些写死，是定制开发里最需要反复确认的事。
第三课：开发进程里真正磨人的细节
如果只谈架构，这篇文章会显得轻飘飘。实际开发中，最耗时间的往往是几个看起来很小的点。
第一个是登录态和企业微信身份的互通。很多人误以为小程序用微信登录，企业微信成员也是微信，天然能打通。其实普通微信生态和企业微信成员体系是两套逻辑。我们最后这么做：企业微信应用构造 OAuth 链接拿到成员身份，再和小程序登录态绑定成会话；涉及外部客户时，再处理外部联系人 ID。第一次联调就卡了两天，原因是回调域名备案没提前做好。后来得到一条经验：做任何涉企微信的定制项目，先确认域名、ICP 备案、应用可见范围，否则后面全是返工。
第二个是消息卡片的按钮回调。企业微信可以把业务页面以卡片形式发到会话里，用户点按钮跳转对应小程序或 H5。但要注意，传参带着中文或特殊字符时如果不做 encode，点击后会直接白屏。还有，卡片在群聊里容易被刷掉，员工找不到入口。于是我们沉淀了一个双通道兜底：关键消息不仅发卡片，还在小程序首页加“待办”Tab，用红点提醒。这个改动很便宜，但效果极好。
第三个是数据同步的边界。客户一开始希望企业微信和小程序所有数据实时一致，成本高且没必要。我们引导他们区分强一致和最终一致：员工姓名、部门、审批状态要强一致；客户行为轨迹、报表统计可以延迟几分钟。边界划清楚后，开发量减了三成，系统也不会因为并发拖垮。在定制项目中，这一步特别重要，因为定制意味着要面对企业特殊的权限模型：区域经理只能看本区域，总部能看全部但不可编辑。权限不是“管理员设置”一句话，而是从接口层就做好数据隔离。
第四课：落地，不是交付代码那一刻才开始的
项目上线前，我们选了三个门店做试点。结果发现两个问题：一是督导在店里网络差，图片上传失败后没有明确提示，他以为提交成功，后台却没记录；二是店长每天要收五六条消息，直接屏蔽了应用通知。
这两个问题都不在技术规划里。我们改进了上传状态提示，把图片压缩到 100K 内，支持后台自动续传；又把同类型通知合并成每天一条汇总。这个“合并”动作，比开发一个新功能还让客户认可。后来客户提出要加小程序报表，开发同事觉得简单，产品经理却先追问了一句：“这个报表给谁看？在什么场景下看？如果只给总部电脑端看，为什么放到手机屏幕上？”客户想了想，收回了需求。
类似的取舍经常发生。定制开发里最有价值的，不是客户说什么就做什么，而是能帮他们分清“需要”和“想要”。我们后来把需求评审流程改成：每个功能都要说出具体使用时刻，说不出来就不做。
上线三个月后，客户自己改了三次巡检表单，没找我们写一行代码。这才是我们理解的定制：复杂规则写入代码，灵活部分交给配置，两边边界划清楚。
常见问题 FAQ
问：小程序和企业微信应用开发，什么时候该做定制，什么时候用现成 SaaS？
答：主要看流程是否涉及多角色、跨部门或多系统。如果只是“填表收集数据”，通用 SaaS 够用；如果数据要和现有 ERP、CRM 打通，审批按组织层级走，不同角色看的数据边界不一样，建议做定制。有一个判断标准：如果你在企业微信里找不到一个应用能同时覆盖一线采集、管理层审批和客户身份关联，那大概率需要定制。
问：定制开发会不会很慢？有没有办法分阶段落地？
答：慢不慢取决于需求边界是否清晰。我们的做法是分三期：第一期打通小程序、企业微信消息和最核心的采集审批，保证业务闭环；第二期做报表、客户标签、自动化任务；第三期再做复杂数据看板。每一期都能独立使用，而不是憋半年上一个“大而全”。第一期上线后的真实反馈，会比任何会议室里的假设都更准确。
问：如何保证企业微信上的客户数据安全？
答：首先要开启企业微信通讯录和客户联系权限隔离，设置成员对外信息展示和客户继承。第二，小程序的接口层必须做统一鉴权，不能只靠前端按钮隐藏。第三，外部联系人 ID 和员工 ID 的映射关系要加密存储，日志里不打明文。最后，员工离职时，企业微信客户分配和群主转移要提前规划，否则客户资产会随账号失效流失。这些在定制开发里都要列入验收标准。
回看整个项目，所谓“小程序与企业微信应用开发实践”，最深的体感是：技术不是瓶颈，真正难的是把散落在一线日常里的动作、规则和关系翻译成系统设计。每一次定制交付，都是一次重新认识客户业务的过程。靠谱的定制不是功能更多、界面更花，而是让企业内部的信息流动更贴近真实的工作方式。这也是企业服务从业者最有成就感的地方。
