报修派单系统怎么落地？工单流转、师傅接单与结算的实操要点

先说结论：难点不在"派单"这两个字

上门维修、家电家居安装、物业报修这类业务找我们做系统时，需求描述往往是"要一个能派单的小程序"。派单这个动作本身，技术上就是把一条工单的负责人字段从空改成某个师傅，一天就能做完。做完之后系统仍然跑不起来，原因是真正难的部分没被讨论。

难的是这些：客户描述"漏水"到底该派水电还是防水；派出去半小时没人接怎么办；师傅到现场发现要多修两处，价钱谁定；上门了但客户不在家，这趟算不算完成、算谁的责任；月底和师傅结账，是按单结、按比例抽成，还是客户买了年卡免人工费的那些单怎么算。

这些问题在纯靠电话调度的年代是靠老板一句话拍定的。换成系统就必须写成明确规则，因为系统不会临场判断。规则没定就开工，最后交付的是一个更麻烦的记账界面 —— 派单还是靠打电话，系统只是事后补录。

报修入口决定后面所有环节的顺畅程度

一张工单的质量在客户提交那一刻就定了。入口问得含糊，后面每个环节都要补问：派单时不知道派谁，师傅出发前不知道带什么工具，到了现场发现干不了，白跑一趟还得重新派。所以报修表单不是"越简单越好"，而是要在客户愿意填的范围内，把决定派单和备料的信息问全。

• 故障类型做成分类选择而不是一个大文本框。分类直接对应师傅的技能标签，这是自动派单的前提
• 必须要照片或视频。维修类需求用文字描述极易失真，一张照片能省掉三轮电话
• 地址要能定位到楼栋单元，并单独留出门牌与楼层。没有电梯、需要爬六楼，会影响师傅接不接这一单
• 期望上门时段做成可选区间，不要让客户填具体时刻。时段才是能和师傅日程匹配的粒度
• 紧急程度单独一栏。漏水和换个把手不该走同一条响应流程，房帮帮就把应急服务单独设了专区

抢单还是指派：两种模式各有适用边界

这是需求阶段最常争论的一处，而争论的原因通常是把它当成了二选一。实际上成熟的做法是两种都要有，按场景切换，后台可配置哪类工单走哪种模式。

派不动的兜底规则，比派单算法本身更重要

不管选哪种派单模式，有一条必须单独设计：工单派不出去的时候怎么办。工单在某个状态停留超过设定时长，就应该自动升级 —— 转给调度、通知管理员、放宽抢单的区域或技能限制、或者提高该单的可见优先级。

没有这条兜底，系统上线后最常见的事故就是一张单静静躺着没人管，直到客户打电话来投诉才被发现。这类事故的杀伤力比功能缺失大得多：客户的感受是"我在你们平台上报了修，你们没人理我"，而在纯电话调度的年代，这单至少有人接起过电话。

兜底规则要能配置时长，并且区分紧急程度。应急类工单的超时阈值可能是十分钟，普通保养类可以是几小时。把这个参数写死在代码里，业务节奏一变就得找开发改。

一张工单的状态要覆盖那些"不顺利"的情况

很多方案的工单状态只有"待接单、进行中、已完成"三个。这三个状态描述的是一切顺利的路径，而上门服务的现实是相当比例的工单走不完这条路。状态设计得不够，这些情况就会被硬塞进某个状态里，数据从此失真。

白跑率和返修率，是靠上面那两个状态换来的

异常关闭和返修是最容易在需求评审里被省掉的两个状态，理由通常是"这种情况不多"。但它们恰恰对应着运营真正该盯的两个指标：白跑率和返修率。前者直接是成本 —— 师傅一趟往返的时间和路费；后者直接是质量与口碑。

省掉这两个状态的后果不是少了两个按钮，而是这两个数字永远只存在于老板的印象里。客户不在家的单被标成已完成，白跑率就是零；返修单被当成新单录入，师傅的返修责任无法归集，考核也就无从谈起。

这两个状态还牵着一个必须提前谈的规则：白跑了，师傅的上门费给不给、谁承担。是客户责任（不在家、地址错误）还是平台责任（派错技能、信息没问清），处理方式不一样。规则定下来，系统才知道这笔钱该记在谁头上。

明码标价之后，现场加项才是纠纷的真正来源

把服务项目明码标价挂在小程序里，是这类平台建立信任的基础动作，房帮帮和小漆匠都是这么做的。但明码标价只解决了下单前的预期，维修行业的纠纷绝大多数发生在下单之后：师傅到现场，发现实际情况比客户描述的严重，需要加项、换配件、加收高空作业费。

这一步如果没有系统流程，就会退回到线下 —— 师傅口头报个价，客户当场答应或者不答应，收现金或者扫师傅个人的码。平台在这一刻既失去了控制也失去了凭证：客户事后投诉说被加价，你拿不出客户同意的证据；师傅少报收入，你也无从核对。

正确的做法是把改价做成一个必须客户确认的环节：师傅在现场提交加项明细和照片，客户在小程序里点确认，确认后订单金额才变更，全过程留痕。客户不同意就走取消或者只做原定项目，同样有记录。这个流程会让师傅觉得多两步操作，但它保护的其实首先是师傅 —— 有客户确认记录在，事后翻脸的成本就高了。

师傅端能不能在楼道里单手用完

师傅端的使用场景是站在客户家门口、手里拎着工具、可能正戴着手套、楼道里信号还不好。一个在电脑上看起来信息完整的工单详情页，搬到这个场景下就会变成没人愿意用的东西。这类系统失败最常见的原因不是功能缺失，是师傅嫌麻烦、继续用电话和微信，系统里的数据全靠内勤事后补录。

管理端同样要考虑移动场景。小漆匠这个项目除了客户端还支持师傅入驻接单，管理员可以直接在手机端派单和管理订单 —— 这一点在小团队里很实用，因为老板本人往往就是调度，他不会一直坐在电脑前。具体到师傅端，下面几点最影响使用意愿：

• 接单和到达打卡要能在一屏之内点完，不要藏在二级页面里
• 客户电话和地址导航直接可点，不要让师傅复制粘贴到别的应用
• 完工照片支持弱网排队上传。别因为传图失败卡住整个完工提交
• 常用的加项和配件做成可选清单，避免手输名称和金额
• 当天工单按时间顺序排在首屏，师傅最关心的是"下一家去哪"
• 收款方式和金额显示清楚，减少现场算账

结算口径要和会员权益一起定，否则一定打架

师傅结算和客户端的营销活动是两套逻辑，但它们算的是同一笔钱，所以必须一起设计。常见的冲突是这样产生的：客户端为了促销上了优惠券、会员卡、免人工费；师傅端按订单金额的比例抽成。客户用了券，订单金额降了，师傅拿到的钱跟着少 —— 而师傅干的活一点没少。这件事上线一个月就会变成矛盾。

解决办法不复杂，但必须事先明确：师傅的结算基数用的是服务原价还是实收金额，优惠部分由平台补贴还是双方分摊，会员免人工费的单里师傅的人工费谁出。这三个问题谈定了，结算模块才有得做。谈不定就先不要上会员卡。

小漆匠的会员体系是月卡、季卡、年卡三档，权益包含维修折扣与免人工费；安欣瞬护那套则是积分商城、优惠券、会员等级加一级分销并行。权益设计得越丰富，与师傅结算的交叉点就越多，越需要在开发前把口径写成文档，而不是留给上线后再"灵活处理"。

四个可核验的参考项目

上面这些要点不是纸上推演，都来自已交付的项目。派单类系统很难靠效果图判断好坏 —— 界面都长得差不多，差别在工单状态、改价流程、结算口径这些看不见的地方。有可以追问细节的真实项目，比原型图更能说明问题。

• 房帮帮（嘉兴）房屋修缮有限公司，统一社会信用代码 91330481MAEDFUJ68T：房屋维修上门服务小程序，涵盖外墙修补、漏水维修、高空作业等，项目明码标价、一键预约，设应急服务专区，内置派单抢单系统与师傅端、管理员端独立入口，从在线预约、抢单派工到服务评价、售后退款打通全流程
• 西安小漆匠家具维修有限公司，统一社会信用代码 91611105MA6TWRGA6A：家居修缮上门平台，涵盖家具修复、空鼓修复、墙面水电维修、防水测漏、门窗调试等，支持实时订单追踪与全流程可视化，含月卡季卡年卡会员体系、师傅入驻接单与管理员手机端派单
• 山东济南安欣养老服务有限公司，统一社会信用代码 91370113MAKCHP8H5L：上门家政养老 O2O 平台，覆盖保洁、陪护、维修多品类，实现下单、接单、上门履约闭环，集成需求发布、积分商城、优惠券与会员等级体系
• 新疆博湖县承接广告安装部，统一社会信用代码 92652829MAE4KAG8XW：广告安装服务展示与预约小程序，实现区域化服务匹配与定金预约下单，把传统安装业务迁到线上

查看房帮帮房屋维修派单平台案例：含派单抢单与师傅端、管理员端说明

查看小漆匠家居修缮平台案例：含会员卡体系与手机端派单说明

查看安欣瞬护上门家政养老平台案例：含多品类履约闭环与营销体系说明

选型时建议逐项核对这 8 件事

第一期不要做成全套现场服务管理平台

派单这条线往深了做，可以一路延伸到师傅轨迹与到岗核验、配件库存与领用、智能排线与路径优化、师傅评级与晋升、客户回访与 NPS、发票与对公结算、多城市加盟管理。这些都是真实需求，但不适合放在第一期一起做。

更稳的顺序是：先把"一张报修单被完整、准确地走完"这件事跑通 —— 客户能问清楚地提交，单子派得出去也接得住，现场加项有确认，完工有凭证，月底和师傅算得清。跑满一两个月，你会拿到真实数据：哪类故障最多、白跑主要出在哪一步、哪些师傅在抢单里长期吃不到单。那时候再决定第二期做什么，比开工前凭想象排功能清单靠谱得多。