家政工单系统开发指南：工单流转、服务回访、售后处理逻辑

上门家政O2O业务中，工单是整个业务的核心载体，不仅承载预约下单、技师上门履约全流程，还需要支持服务回访、客诉售后处理。如果工单状态管控不严，容易出现流程错乱、纠纷无凭证、售后无法闭环等问题。本文围绕工单状态机流转、回访机制、售后工单处理三大核心，讲解家政工单系统完整开发实现。

本文将从系统整体架构、工单数据表、工单流转、回访实现、售后处理、关键代码、地图能力、支付回调、后台统计、技术选型、后期扩展方向，完整讲解家政工单系统落地方案。

一、家政工单系统整体架构设计

系统分为用户小程序、技师小程序、平台管理后台，后端统一提供工单服务，通过消息队列完成消息推送，工单变更同步给用户端与技师端。

1. 用户端小程序

• 服务预约提交生成工单、查看工单进度
• 服务验收、提交评价、发起售后申诉
• 接收服务回访通知，填写回访反馈

2. 技师服务端小程序

• 接收工单、接单、上门签到、更新履约状态
• 上传服务完工凭证照片
• 查看本人工单，处理售后协商

3. 平台管理后台

• 全部工单监控，人工干预改派工单
• 回访任务管理，回访记录查看
• 售后工单审核、纠纷处理、退款审批
• 工单、回访、售后数据统计分析

整体架构示意：

 用户小程序
      |
技师端 ---- API服务层 + 消息队列 ---- 管理后台
      |
MySQL + Redis

二、工单核心数据表设计

包含主工单表、工单操作日志表、回访记录表、售后申诉子表。每一次状态变更留存操作日志，作为纠纷举证凭证。

工单主表：

CREATE TABLE work_order (
 id INT PRIMARY KEY AUTO_INCREMENT,
 user_id INT COMMENT '下单用户ID',
 technician_id INT COMMENT '接单技师ID',
 service_id INT COMMENT '服务项目ID',
 appoint_time DATETIME COMMENT '预约上门时间',
 address VARCHAR(255) COMMENT '上门地址',
 amount DECIMAL(10,2) COMMENT '工单实付金额',
 status TINYINT COMMENT '工单主状态',
 create_time DATETIME
);

工单操作日志表：

CREATE TABLE work_order_log (
 id INT PRIMARY KEY AUTO_INCREMENT,
 order_id INT COMMENT '关联工单ID',
 before_status TINYINT COMMENT '变更前状态',
 after_status TINYINT COMMENT '变更后状态',
 operator_id INT COMMENT '操作人ID',
 operator_type TINYINT COMMENT '1用户 2技师 3管理员',
 remark VARCHAR(500) COMMENT '操作备注',
 create_time DATETIME
);

服务回访记录表：

CREATE TABLE order_revisit (
 id INT PRIMARY KEY AUTO_INCREMENT,
 order_id INT COMMENT '工单ID',
 revisit_type TINYINT COMMENT '1自动消息回访 2人工客服回访',
 satisfaction TINYINT COMMENT '1满意 2一般 3不满意',
 feedback TEXT COMMENT '用户反馈内容',
 operator_id INT COMMENT '回访客服ID，自动回访为null',
 create_time DATETIME
);

售后申诉子表：

CREATE TABLE order_aftersale (
 id INT PRIMARY KEY AUTO_INCREMENT,
 order_id INT COMMENT '原工单ID',
 apply_user_id INT COMMENT '申诉人id',
 apply_reason TEXT COMMENT '申诉原因',
 aftersale_type TINYINT COMMENT '1退款 2返工重服务',
 status TINYINT COMMENT '0待审核 1审核通过 2驳回',
 refund_amount DECIMAL(10,2) COMMENT '申请退款金额',
 create_time DATETIME
);

服务项目查询接口示例(Node.js)

router.get('/service/list', async(req,res)=>{
   
    const serviceList = await ServiceItem.findAll({
   
        where:{
   
            status:1
        }
    })
    res.json({
   
        code:200,
        data:serviceList
    })
})

三、工单流转状态机实现

采用状态机约束工单流转，禁止非法状态跳转。完整状态常量定义：

const workOrderStatus={
   
    WAIT_PAY:1,        //待支付
    WAIT_DISPATCH:2,   //已支付待派单
    TECH_ACCEPT:3,     //技师已接单
    ON_WAY:4,          //技师出发上门
    ARRIVED:5,         //上门签到
    SERVICING:6,       //服务进行中
    WAIT_CHECK:7,      //待用户验收
    FINISHED:8,        //工单已完成（可触发回访）
    AFTER_SALE:9,      //售后处理中
    CANCEL:10          //工单已取消
}

业务约束示例：只有状态为WAIT_CHECK才可以流转至FINISHED；只有FINISHED已完成工单才允许发起售后申诉。

创建预约工单函数：

async function createWorkOrder(userId,serviceItem,params){
   
    const workOrder = await WorkOrder.create({
   
        user_id:userId,
        service_id:serviceItem.id,
        appoint_time:params.appointTime,
        address:params.address,
        amount:params.amount,
        status:workOrderStatus.WAIT_PAY
    })
    return workOrder;
}

工单状态变更接口（附带日志记录）：

router.post('/order/updateStatus',async(req,res)=>{
   
    const {
   orderId,afterStatus,operatorId,operatorType,remark}=req.body;
    const orderInfo = await WorkOrder.findByPk(orderId);
    const beforeStatus = orderInfo.status;
    //状态机简单校验，非法跳转直接拦截
    if(!checkStatusTransform(beforeStatus,afterStatus)){
   
        return res.json({
   code:400,message:"不允许当前状态跳转"})
    }
    await WorkOrder.update({
   status:afterStatus},{
   where:{
   id:orderId}});
    //写入工单操作日志
    await WorkOrderLog.create({
   
        order_id:orderId,
        before_status:beforeStatus,
        after_status:afterStatus,
        operator_id:operatorId,
        operator_type:operatorType,
        remark:remark
    })
    //消息队列推送状态变更通知
    await mqProducer.send("order‑status‑change",JSON.stringify({
   orderId,afterStatus}));
    res.json({
   code:200,message:"状态更新成功"})
})

完整工单主业务流转：

待支付
 |
已支付→待派单
 |
技师接单→技师出发上门→上门签到→服务进行中→待用户验收
 |
用户确认验收 → 工单已完成【触发回访任务】
 |
（已完成工单可发起售后申诉）→售后处理中

四、服务回访模块逻辑

工单状态流转至FINISHED已完成之后，系统自动生成回访任务，支持自动消息回访和人工客服回访两种模式。

1. 自动回访：工单完成N小时之后推送小程序订阅消息，引导用户提交满意度与反馈；
2. 人工回访：后台生成回访待办列表，客服逐条打电话记录回访结果；
3. 回访不满意的工单自动标记，可直接跳转售后处理流程。

保存回访记录接口示例：

router.post('/order/revisit/save',async(req,res)=>{
   
    const {
   orderId,revisitType,satisfaction,feedback,operatorId}=req.body;
    const revisit = await OrderRevisit.create({
   
        order_id:orderId,
        revisit_type:revisitType,
        satisfaction:satisfaction,
        feedback:feedback,
        operator_id:operatorId
    })
    //回访不满意自动标记工单，推送后台告警
    if(satisfaction ===3){
   
        await mqProducer.send("revisit‑bad‑notify",JSON.stringify({
   orderId}))
    }
    res.json({
   code:200,data:revisit})
})

回访业务流转：

工单已完成
↓
系统生成回访任务
├─自动模式：推送小程序消息，用户线上填写反馈
└─人工模式：客服后台查看待回访列表，录入回访结果
↓
判断满意度
├─满意：工单闭环归档
└─不满意：转入售后待处理队列

五、售后申诉处理逻辑

用户仅可以对已完成的工单发起售后，支持退款或者返工重服务；售后独立生成子工单，不修改原始主工单记录，保留原始履约数据。

售后申请提交接口：

router.post('/order/aftersale/apply',async(req,res)=>{
   
    const {
   orderId,userId,applyReason,aftersaleType,refundAmount}=req.body;
    const mainOrder = await WorkOrder.findByPk(orderId);
    //校验：只有已完成工单允许发起售后
    if(mainOrder.status !== workOrderStatus.FINISHED){
   
        return res.json({
   code:400,message:"该工单不可发起售后"})
    }
    const aftersale = await OrderAftersale.create({
   
        order_id:orderId,
        apply_user_id:userId,
        apply_reason:applyReason,
        aftersale_type:aftersaleType,
        status:0,
        refund_amount:refundAmount
    })
    //主工单标记为售后处理中
    await WorkOrder.update({
   status:workOrderStatus.AFTER_SALE},{
   where:{
   id:orderId}});
    //推送后台售后待处理提醒
    await mqProducer.send("aftersale‑new‑task",JSON.stringify(aftersale));
    res.json({
   code:200,data:aftersale})
})

售后审核处理逻辑：

用户提交售后申诉
↓
平台后台收到售后待办
├─审核驳回：填写驳回理由，主工单恢复【已完成】状态，通知用户
└─审核通过
    ├─类型为退款：调用退款接口，退款完成闭环售后
    └─类型为返工重服务：重新生成子工单派给技师重新上门，返工完成关闭售后

六、地图LBS上门服务能力

家政工单依赖地理位置，实现：

• 用户预约地址解析经纬度存入工单
• 根据工单位置筛选匹配范围内可接单技师
• 技师端导航至用户上门地址

路线调用示例：

function getServiceRoute(start,end){
   
    return axios.get(
        "[https://api.map.com/direction](https://api.map.com/direction)",
        {
   
            params:{
   
                origin:start,
                destination:end
            }
        }
    )
}

七、微信支付订单处理

用户预约提交工单，完成支付后工单进入待派单。

支付业务流程：

用户提交预约工单
↓
生成业务工单记录
↓
调用微信支付接口
↓
用户完成小程序支付
↓
接收微信异步回调
↓
更新工单状态为待派单，触发派单任务

支付回调示例代码：

router.post('/pay/notify', async(req,res)=>{
   
    let orderId=req.body.orderId;
    await WorkOrder.update({
   
        status:workOrderStatus.WAIT_DISPATCH
    },{
   
        where:{
   
            id:orderId
        }
    });
    res.send("success");
})

八、后台工单回访售后统计功能

运营人员统计工单总量、回访满意度、售后申诉占比，评估服务质量。

统计每日工单数量SQL：

SELECT 
DATE(create_time) AS day, COUNT(*) AS order_count
FROM work_order
GROUP BY day;

回访满意度统计：

SELECT satisfaction,COUNT(*) AS cnt
FROM order_revisit
GROUP BY satisfaction;

售后工单统计：

SELECT status,COUNT(*) AS aftersale_count
FROM order_aftersale
GROUP BY status;

通过统计数据，运营可以掌握工单履约质量、用户满意度、售后申诉率，优化技师服务管理。

九、开发技术选型

小程序端

• 微信小程序原生开发
• UniApp
• Taro

后端

• Java Spring Boot
• Node.js
• PHP Laravel

数据库 & 缓存 & 消息队列

• MySQL：工单、回访、售后、操作日志持久化存储
• Redis：缓存技师位置信息
• 消息队列：处理工单变更、回访任务、售后消息推送

服务部署

• Linux服务器
• Nginx
• Docker

SpringBoot项目目录参考：

housekeeping‑workorder‑system

├── workorder      主工单模块
├── order‑log      工单操作日志
├── revisit        服务回访模块
├── aftersale      售后申诉处理模块
├── dispatch       技师派单模块
├── payment        支付模块
└── admin          平台后台

十、后期扩展方向

基础工单、回访、售后搭建完成，还可以迭代更多业务能力。

工单流程增强

• 工单改约、改期完整流程，变更记录留痕
• 多技师协同工单，一个工单分配多名技师上门
• 工单超时自动提醒、超时自动取消机制

回访能力扩展

• 回访问卷自定义，增加多维度调研项
• 回访结果关联技师绩效，满意度纳入技师评分

售后体系增强

• 售后仲裁流程，技师、用户双方上传举证图片
• 售后工单定时巡检，超期未处理告警

数据运营

• 售后原因分类统计，定位高频服务问题
• 工单履约时长统计，技师工单完成率报表

总结

家政工单系统，核心不只是完成预约下单，要实现完整工单状态机流转、服务回访闭环、售后申诉处理流程。

开发中要重视工单操作日志留存，所有状态变更留下凭证，便于处理用户纠纷；工单、回访、售后数据表相互关联，售后不直接修改原始工单数据，保证业务可追溯。在此基础上可以继续扩展改约改期、多技师协同工单、自定义回访问卷，适配不同家政上门业务场景。