项目速览
- 行业：家政与本地生活服务
- 交付内容：用户端小程序 + 服务人员端 + 运营后台 + 售后工单模块
- 周期：8 周；团队 5 人
- 技术栈：uni-app、PHP + MySQL、Redis、对象存储、短信与微信订阅消息
背景：纠纷比订单更耗人
客户做的是日常保洁、深度保洁、家电清洗与育儿嫂四类服务，日均 300 单上下。下单流程本身没有难度，真正吃人力的是售后：客户说「玻璃没擦」「东西碰坏了」，服务人员说「擦了」「不是我弄的」。没有过程记录时，客服只能靠印象判断，双方都不服气。
另一个隐性问题在派单：早期靠客服手工在群里派，什么人在哪个片区、会不会做空调清洗、当天已经接了几单，全靠记。结果是有的人连做 5 单疲劳作业，有的人一天没活。
目标
- 派单可解释：按片区、技能、评分、当日已接单量自动匹配，支持改派并保留改派原因
- 服务过程留痕：到场打卡、服务前照片、服务后照片、客户确认签字，四件事一次做完
- 售后有流程：投诉分级、责任归属、返工与赔付走工单，处理时长可统计
- 价格模板化：按时长、面积、人数、是否含家电组合计价，运营可自行维护
方案要点
① 服务项与价格模板
把「保洁」拆成可计算的基本项：面积（㎡ 分段）、时长（小时）、人数、是否含玻璃/油烟机/地毯，再叠加会员折扣与首单券。运营在后台维护一张模板表，新服务类型不用开发介入就能上线。
② 派单：技能 + 片区 + 负载
每个服务人员有一张能力卡（技能标签、服务片区、评分、当日已接单数）。派单时先按技能与片区过滤，再按「当日负载最低 + 评分最高」排序，客服可手工改派，改派必须填原因，系统按月统计改派率与原因分布——这个数据后来成了调整片区划分的依据。
③ 过程留痕
服务人员到场必须打卡（定位 + 时间），拍摄服务前照片（至少 2 张，锁定为「前」），完成后拍服务后照片并请客户在小程序上确认。照片带时间水印与顺序不可调整，售后时按时间线回看，责任判定从「印象」变成「证据」。
④ 售后工单
投诉分三级（咨询 / 需返工 / 需赔付），每级有固定的处理时限与升级路径。工单直接关联订单与服务人员，返工记录会计入服务人员质量分，避免同一个人反复出同类问题。
技术实现中的注意点
- 照片不可篡改：上传时服务端记录原始拍摄时间与上传时间两个字段，前端不允许删除已提交的「前」照片，只允许追加。
- 定位漂移：早期用单次定位，出现过「打卡地址在隔壁小区」的争议。后改为连续 3 次采样取中位数，并在距离超出 300 米时要求补充说明。
- 订阅消息的到达率：微信订阅消息需用户主动授权，一次性授权只能推一条。我们把「派单成功」「上门提醒」「服务完成」做成三次独立授权点，并在小程序首页给出开启引导。
结果与复盘
售后从线下沟通转为系统工单，处理时长与责任归属都有据可查；派单从「凭印象」变成「看负载」，人手忙闲不均的问题明显缓解。具体投诉率与复购数据由客户掌握。
复盘时客户提了一件我们没想到的事：服务人员愿意用系统，是因为「照片能证明我做了」。这说明过程留痕不只是给客户看的，也是给一线人员的保护——这类「双向价值」在需求阶段往往被忽略，值得在后续项目里主动设计。
发表回复