案例/注塑装备
注塑装备售后服务云平台
把散落在电话与微信里的售后过程,收进一条可追溯的工单流。
- 行业
- 注塑装备
- 服务
- 软件开发RISEMAP
- 交付物
- 服务云 · 数据可视化工程师端 · 客户端 · 管理端
- 参与角色
- 软件业务负责人 · 前端工程师高级交互设计师 · 项目经理
01 BACKGROUND
售后不是成本中心——前提是它先变成一条能被看见的流程。
项目背景
注塑设备一旦停机,损失按小时计算。可现实里的报修往往始于一通电话或一条微信:故障描述靠转述,备件是否在途靠追问,工程师进行到哪一步只有他自己知道。
信息不落到系统里,管理者就只能凭印象判断服务质量,客户也无法预期什么时候能恢复生产。平台要做的第一件事,是让每一次报修都留下结构化的痕迹。
02 CHALLENGE
设计挑战
三端的使用场景差得很远,但背后必须是同一套数据——否则系统很快会分裂成三个互相不认账的表格。
- 一线工程师在车间用手机,网络与光线都不稳定
- 客户侧要看得懂进度,但不需要看到内部细节
- 备件、设备档案与工单必须来自同一个数据源
- 管理者关心的是趋势,不是单条记录
03 APPROACH
我们的解法
我们围绕「一次服务的完整生命周期」组织系统:报修、派单、到场、处置、备件、回访,每一步都有明确的责任人与状态。工程师端做成移动优先的极简表单,弱网下先存本地再同步;客户端只暴露进度与预计恢复时间。
数据回流到管理端之后,才有了可分析的对象:哪类故障最常发生、哪些机型的备件周转最慢、响应时长集中在哪个区间。可视化不是为了好看,是为了让下一次决策有依据。
弱网优先,而不是网络理想
车间常常是信号最差的地方。表单在本地先落盘、恢复网络后自动补传,工程师不需要为了提交一张单子走到厂房外面。同一条工单里,客户能看到的只有三个节点:报修受理、工程师到场、服务完成。
04 CRAFT
05 PROCESS
业务梳理与流程建模
把线下的服务动作映射成系统状态机,明确每一步的责任人。
产品设计与界面系统
分别为工程师端、客户端与管理端设计与之匹配的信息密度。
全栈开发与集成
打通设备档案、备件库与工单数据,形成单一数据源。
上线与迭代
随真实工单量调整表单字段与提醒策略。
能被看见的流程,才谈得上被改进。
BRAND MARK / 标识构造
两段弧,
一次咬合。
上杠向右收,下杠向左收,收在同一条 R122 的弧上,互相咬住。中间留 21.5 的缝——那是人和机器之间的距离。上面这个案例,做的就是同一件事:把这道缝再做窄一点。
- 杠高 BAR
- 148
- 咬合缝 GAP
- 21.5
- 半径 RADII
- 122 / 90.25 / 57.75
- 错位 OFFSET
- 150
SAVE HMI · 英特费斯







