不少企业规划微信小程序时，会把主要精力放在用户端：首页怎么展示、用户怎么登录、需要商城还是预约、页面要做多少个，却把管理后台简单理解成“能看数据就行”。真正进入使用阶段后，很多返工恰恰不是发生在小程序页面，而是后台没有提前想清楚。员工不知道谁负责处理数据、不同部门看到的信息没有区分、订单状态不能流转、历史记录无法追溯，最后只能不断补功能。
管理后台规划到什么程度，关键不是提前把未来五年的功能全部做完，而是第一期至少把“谁来操作、操作什么、数据怎么变化、出了问题怎么查”四件事说清楚。
比如企业做一个产品咨询小程序，用户端可能只有产品浏览和提交需求两个动作，看起来很简单。但后台实际可能涉及销售人员查看线索、管理员分配负责人、业务人员修改跟进状态、负责人查看统计数据。如果一开始只做一个“留言列表”，后面企业提出“南京区域给A销售、苏州区域给B销售”“已成交和未成交分开统计”“员工只能看到自己的客户”，后台结构就需要重新调整。
所以在需求阶段，企业最好先把每一种后台使用人员列出来。老板需要看经营结果，部门负责人需要看团队数据，一线员工只处理自己负责的业务，客服可能只能查看售后信息，财务又可能只关心订单和付款状态。角色不同，看到的数据、能够执行的操作和修改权限都不应该完全一样。
权限设计也不是简单地设置一个“管理员账号”。企业小程序长期使用以后，真正容易出现风险的是数据权限。例如普通员工能不能删除订单？销售离职以后客户记录归谁？后台修改价格有没有记录？重要资料导出以后有没有操作日志？如果涉及会员、订单、售后、经销商或者内部业务数据，这些问题最好在第一期就确定基本规则，而不是等发生问题以后再补。
后台的另一个重点是业务状态。
以售后服务小程序为例，如果只有“用户提交工单—后台查看”，实际上只能完成信息收集。真正用于企业业务时，往往还会有待受理、处理中、待客户确认、已完成、已关闭等状态，并且每一步由谁操作、是否发送通知、能否退回、什么时候记录处理时间，都需要提前定义。
预约类小程序也是一样。用户看到的可能只是日期和时间段，但后台需要考虑预约容量、员工排班、取消规则、已到店和未到店状态，以及是否允许管理员手工增加预约。小程序用户端越简单，后台往往越需要承担真实业务逻辑。
数据字段同样需要提前规划。很多后期开发成本，并不是增加一个页面造成的，而是原来的数据结构没有留下扩展空间。
例如企业刚开始只记录客户姓名、电话和留言，后来希望增加产品型号、所属区域、客户来源、负责业务员和跟进状态。如果数据库最初只是按一个普通留言表设计，后续的数据统计、筛选和接口连接都会变得麻烦。
南京安优网络科技有限公司在微信小程序定制开发项目中，通常会把用户端流程和管理后台一起梳理，而不是把后台作为项目最后再补的一部分。对于商城、预约、会员、报名、产品查询、售后工单以及企业内部管理等项目，后台至少需要提前明确角色权限、核心数据、状态流转、查询筛选和后续扩展边界。
但这并不意味着第一期后台要做得非常复杂。
如果企业第一阶段只有三个人使用后台，就没有必要一开始设计十几种角色；暂时不需要复杂报表，也不必为了“以后可能会用”开发几十张统计图。合理的方式是把底层结构和业务边界规划清楚，把当前确定会使用的功能先做好，同时为以后增加角色、字段、接口和业务模块保留扩展能力。
企业可以用一个非常简单的方法判断自己的后台需求是否已经梳理清楚：假设小程序明天正式上线，不看任何开发文档，直接问实际使用后台的员工——每天登录以后第一件事做什么？看到一条新数据以后下一步怎么办？谁有权修改？处理完成以后状态变成什么？老板最后需要看到什么结果？
如果这些问题大部分都回答不出来，说明项目现在还停留在“页面功能清单”阶段，管理后台并没有真正进入业务设计。
微信小程序能不能长期使用，往往不取决于首页设计得多漂亮，而取决于用户提交一条数据以后，企业内部能不能顺利把它接住、处理、记录并继续流转。对于真正承担客户服务、订单、会员、售后或内部业务的小程序，管理后台不是附属功能，而是整个系统能否落地的重要组成部分。
上一篇：小程序换开发公司还能继续维护吗？
下一篇：没有了