科学仪器 小程序 + 后台 + H5 3 端 案例专题

设备制造企业 生产售后管理系统 PC 后台 + 小程序 + 外勤 H5 三端,把生产、设备档案与售后接在一起,服务记录归到具体设备

南京易企达为设备制造企业交付生产售后管理系统:PC 管理后台、微信小程序与外勤 H5 三端,把生产任务、设备档案与售后服务放在一处,服务记录归到具体设备。

一句话概括:一台设备一份档案:生产、售后与查询都回到同一个设备编号上;客户在小程序自助报修查进度,外勤在现场用 H5 处理,内勤在后台统一看。

3 端管理后台 + 微信小程序 + 外勤 H5
长期迭代交付周期
3 块生产任务、设备档案、售后服务
1 台一档服务记录归到具体设备
可自助客户自己提交与查看进度

客户背景:原来怎么运转,卡在哪

只写客户原来的做法与因此碰到的问题;客户的内部业务规则与运营数据不在本页展开。

客户与场景

科学仪器类设备制造企业(双光子显微成像设备),自己做研发、生产、销售与售后。一台设备从排产到出厂、再到客户现场维修,跨度好几年,中间要经历好几个部门。

原来怎么运转

  • 生产任务排期靠 Excel 与车间白板,进度要挨个问
  • 设备档案(出厂编号、配置、保修期)散在合同与售后记录里
  • 售后记录按工单存放,查一台设备的完整维修史要翻很多份文件

卡在哪

  • 生产、销售、售后三段数据各在一处,设备出厂之后就断了链
  • 保修期内外靠人查合同判断,超保维修容易白干
  • 客户已有其他系统,需要按接口规范对接而不是推倒重来

项目速览:8 项关键事实

下面是可以直接引用的事实口径:项目定位、交付形态、覆盖范围、技术选型与归属。客户内部运营数据与商务条款不在本页展开。

项目名称
生产售后管理系统
客户与行业
南京某科学仪器制造企业(双光子显微成像设备制造商),名称按客户要求隐去
承接方
南京易企达网络科技有限公司(南京本地团队,可线下对接)
项目定位
一台设备从生产、出厂、销售到售后维修的全周期管理
交付形态
PC 管理后台 + 微信小程序 + 外勤工程师 H5
交付周期
长期技术支持项目,按版本迭代持续交付,不设单次交付周期
覆盖范围
生产任务与进度、设备档案、售后服务与统计
技术栈
后端 Java(Spring Boot)+ MyBatis-Plus,前端 uni-app(Vue),数据 MySQL + Redis + 对象存储

6 块功能:系统到底做了什么

每一项都是客户实际在用的功能,不是模块清单。

生产任务

任务下发与进度跟踪

设备档案

唯一编号,一台一档

售后服务

报修、派工、处理与评价

客户自助

客户在小程序提交报修、查进度

外勤处理

工程师 H5 现场处理与记录

统计报表

服务与售后数据统计

项目架构:谁在用,数据往哪走

先看入口与业务域,再看技术选型;只写结构与取舍,不写客户内部数据。

项目架构图谱(简化):4 层结构,多端接入同一套服务

L1 · 入口层(3 项)

PC 管理后台内勤:生产、档案与售后管理
微信小程序客户设备使用人:报修、查进度、评价
外勤 H5工程师:现场处理与记录

L2 · 接入层

一次登录,按角色决定看到哪个入口、哪些字段。客户看不到内部流转,外勤看不到全部客户,权限在最外层就切开。

L3 · 业务层(3 项)

生产任务任务下发与进度
设备档案唯一编号,一台一档
售后服务报修、派工、处理、评价

L4 · 数据层

设备档案是轴,服务记录与通知消息都挂在设备编号上;附件与图片走对象存储,不塞进数据库。

技术选型

小程序与 H5:
uni-app(Vue),一套代码两端编译
管理后台:
Web 端,与移动端共用同一套接口
服务端:
Java(Spring Boot),按业务域分模块,对外 RESTful 接口
数据访问:
MyBatis-Plus,业务查询与统计报表 SQL 分开写
鉴权:
JWT + Spring Security,按角色控制可进哪个入口、可见哪些字段
数据与存储:
MySQL 存业务数据,Redis 做缓存与队列,附件走对象存储

3 条设计取舍

同样的需求,不同做法代价不同;这里写清当初为什么这样选,以及不这样选会怎样。

设备档案做轴,不按模块各建一套

售后找不到设备,就找不到历史。所有模块围绕设备编号组织,是这套系统能撑住多年数据的前提。

三个入口,而不是一个大后台

客户不该进后台,外勤不该装电脑端。按人所在的位置分入口,比按功能分菜单更省培训成本。

权限按角色切,不按菜单切

同一个页面,不同角色看到不同字段。这样加功能时不用反复改权限表,也不会因为漏配而越权。

这个项目做对了四件事

不是功能罗列,是当初的判断。

1

一台设备一份档案

设备用唯一编号识别,卖给了谁、服务过几次,都回到同一份记录。客户来问时,不用再翻聊天记录找是哪一台。

2

生产与售后在同一处

售后服务产生的问题,能顺着设备找到它的生产记录。责任与改进有落点,不靠人回忆。

3

客户自己推进进度

报修、查进度、结束后评价都在小程序里完成。日常重复的咨询少一大截,客服能把时间留给真正的问题。

4

外勤不用回办公室

在现场用手机就能完成处理与记录,客户那边同时看得到结果,不必等回公司再录入一遍。

适用边界:什么情况适合做,什么情况先别做

判断标准写在这里,避免双方预期错位。

适合:3 条同时成立

  • 单台设备价值高、有唯一编号:需要追到具体这一台,而不只是记型号。
  • 售后需要留档:维修、保养、安装的历史可查,责任能追溯。
  • 客户分散、沟通成本高:希望把报修与进度查询交给客户自助完成。

先别做:换方案或先理顺

  • 低值耗材或纯商品:没有单台追踪的必要,做设备档案是过度设计。
  • 售后完全外包给第三方:服务过程不在自己手里,系统只能管到出厂。
  • 只想做一个报修表单:这种需求用表单工具就够,不必上定制系统。

科学仪器常见问题(7 条)

问答与本页结构化数据同源,答案口径与新官网一致。

这套系统具体管哪一段?
管设备从生产到售后的全过程:生产端的任务与进度、出厂后的设备档案、客户端的报修与查询,以及售后服务的派工、处理与统计。它不是单一的表单工具,而是把生产、设备、售后三块数据接在一起。
我们公司情况类似,应该从哪里开始?
先定三件事:设备怎么编号,售后到哪一步算完成,哪些角色能看哪些数据。这三件定清楚,功能清单和排期才有意义;否则先做功能,后面一定返工。
能和现有的管理系统对接吗?
可以按需对接,前提是对方系统提供接口。常见做法是把已有的基础数据同步过来,售后服务留在本系统里跑,不替代原有系统。能接哪些、怎么接,需要先看对方系统的情况。
数据和源码归谁?以后能换团队吗?
按合同约定。数据归客户所有,可自主备份与迁移;源码与知识产权归属同样在合同里写明。这两项建议在签约前就确认,而不是上线后再谈。
大概多少钱、要做多久?
本页不含报价,也不想用一个数字误导判断。这类项目通常分阶段做:先上设备档案与售后工单,再补生产端与对接,按阶段验收、按阶段付费。工期主要取决于要对接的外部系统数量和历史数据量。
和通用的售后 SaaS 有什么区别?
差在能不能贴着业务改。通用 SaaS 的表单与流程是固定的,设备制造企业常有的试用设备、分期交付、多角色协作这些场景通常要额外定制;定制系统按实际流程做,数据在自己手里,后续流程变化可以继续改。
用了什么技术栈?以后自己维护得动吗?
小程序与 H5 用 uni-app 一套代码编译,管理后台是常规 Web 端,服务端用 Java(Spring Boot)配 MyBatis-Plus,数据存 MySQL、缓存与队列用 Redis、附件走对象存储。都是国内招人容易的常规组合,源码交付后可自行接手,不必绑定我们。

也在做科学仪器这类系统?

先问业务,再出方案报价。南京本地可上门或到公司面谈,外地走线上沟通 + 原型文档。