这份表交给的是门店端的人——接车主管、店长，以及甲方内部那个被临时指派"盯系统"的运营。汽修的工单小程序开发做完交付，代码这一侧的活基本就结束了，真正决定这套东西能不能活下来的是接下来三十天：车一台台开进来，工单一张张开出去，任何一处没对齐的字段都会在结算台前排队，变成客户的脸色。开工前手上必须先有三样东西：一份带权限说明的账号清单（接车、技师、收银、店长、超级管理员五类各几个人写死），一张工单字段对照表（纸单上每一栏对应小程序里的哪个字段，允许为空的标出来），一张按天排的值班表（谁在打烊后做核对，谁的手机上装着后台）。三样缺一样就别急着上线，补齐再往下走。

上线首日：纸单和小程序双轨跑满一整天

这一步手上要有的是当天排班表和还没停印的三联纸单。动作只有一个：接车员每接一台车，纸单照开，小程序里同步再开一张，技师照常撕联，收银端两边都录。打烊后由值班的人逐单比对，只盯六栏——车牌、进厂里程、施工项目、工时费、配件费、实收金额。一家六工位的门店日均 28 到 45 单，比对下来大约花 40 分钟。产出是一张《首日差异表》，每条写清哪一栏对不上、差多少、什么原因。差异率落在 8% 到 15% 都算正常，超过 20% 说明字段对照表本身有问题，不是人的问题。

这一步最容易栽的地方是只让技师用。技师端只管施工项目和工时，真正的数据入口在接车那一环，接车员不参与，第二天所有工单的进厂里程和联系电话都是空的。另一个常踩的坑是车牌不做唯一性校验：同一台车上午接车员开一单、下午技师又补一单，满月统计时进厂台次直接虚高一成。

第二天到第三天：字段先冻结，再谈改

输入是前一天那张差异表。动作是逐条归因，分成三类：录入习惯问题（该填的没填、格式写乱），字段缺失问题（纸单上有、小程序里根本没这一栏），逻辑错误问题（配件退换后工单金额不回算这种）。三类里只有第三类当天提给小程序开发那边，前两类一律走培训和界面文案解决，不许当成需求提。产出是一份冻结版字段清单，外加一页纸的操作卡，塑封了贴在接车台和收银台各一张。

失败点几乎都出在同一处：上线第三天就召集各店店长开需求评审会，每人提五条，全都答应改。汽修门店之间的差异本来就大，钣喷店和快修店对一张工单的理解完全不同，这个阶段照单全收，版本会变成一天两发，到头来谁也说不清线上跑的是哪一版。首月的字段变更控制在三项以内是条务实的线，一项改动从提出到灰度上线按 2 到 3 天排。

第三日起：回访任务怎么生成、派给谁、超时怎么收回

输入是已结算并且出厂满 72 小时的工单。动作分三段。生成：每天早上九点批量跑一次，把符合条件的工单转成回访任务，保养类和维修类分开，钣喷类因为周期长，单独延到出厂第七天再生成。分派：按施工门店派给店长或专职客服，硬规则是不能派给当初的施工技师本人，自己回访自己修的车，问出来的满意度没有参考价值。回收：一条任务 24 小时未处理自动收回重派，同一账号连续两条被回收，系统直接给店长发提醒。

产出是一条完整的回访记录：接通、未接还是拒访，四道题的问卷结果，以及差评自动转成的售后工单。问卷务必压到四题以内，让客户九十秒内答完——保养后第三天打过去，愿意配合的时间窗就那么长。电话直接接通率通常在 40% 到 55%，两次未接后自动补发微信服务通知加一条短信，整体触达能抬到 70% 到 80%。回访是汽修类小程序开发里最容易被做浅的模块，浅在两个地方：一是任务没有超时回收机制，压在某个店长手里三天，等他想起来打过去，客户连换了什么机油都记不清了；二是把回访做成了推销，前两题还在问施工质量，第三题开始推年卡，接通率一周内就往下掉。

第一周结束前：每天二十分钟的三方对账

输入是三份数据：小程序端的结算流水、原有收银软件或 POS 的流水、仓库的配件出库单。动作是只对三个口径——笔数、金额、挂账单，别一上来就对全字段，对不完也没人愿意天天干。产出是一张留痕的日对账表，当天的差异当天挂账当天清，不许过夜。

这个行当的对账差异高度集中在四种单子上：未结算就放车出厂的（熟客挂账、老板打过招呼），配件退换只在仓库系统改了、工单金额没回算的，跨店核销的次卡和洗车券没回写到原开卡门店的，以及返工单挂在原工单下面导致工时费重复计的。首周未结算出厂的占比通常在 3% 到 8%，到第四周应该压进 1% 以内；配件金额差异的容忍线放在 1% 左右比较现实，超过就得回去查出库单。这一步做不做，直接决定满月那天拉出来的营收数字有没有人信。

第十一天到第二十天：异常工单捞取与热修节奏

输入是后台错误日志、客服会话记录和接口超时清单。动作是每两天捞一次四类异常单：结算状态卡住超过 24 小时的、实收金额为零的、同一车牌当天重复开单的、回访任务生成失败的。捞出来按影响面分级，卡住收银和卡住出厂的算 P0，当天热修；体验类和统计口径类算 P1，攒到双周版本一起发。产出是一份异常台账加一张版本计划表。

这一步最常见的翻车不在技术上，而在承诺上：客户上午反馈一个问题，运营下午就回"明天更新"，忘了小程序的审核周期，普通审核要排 1 到 3 个工作日，赶上节前还更久。做小程序开发的团队在这个阶段应该主动给门店一张发版日历，哪天提测、哪天送审、哪天灰度，写清楚贴出来，比口头承诺管用得多。另一个坑是一次发版塞十几个改动点，回归测试根本覆盖不完，五到八个改动点是比较安全的量，先在一家门店灰度跑满七天再推全量。

第二十一天到第三十天：提醒与卡券接上，再按五条线验收

输入是次卡与套餐的核销数据、上次保养的里程和日期。动作是把两类自动提醒开出来：里程提醒按上次保养里程加 4500 公里、或者满五个月触发，两者取先到的那个；次卡到期提醒提前 15 天发一次，只发一次。同时把跨店核销的回写打通，A 店办的卡在 B 店用，次数从 A 店扣、收入记 B 店，这条不通，年底分账能吵一个月。产出是一份满月验收单。

提醒这块的失败点单一但致命：不设频次上限。一个客户名下三台车，里程提醒、次卡到期、生日券三条撞在同一周发出去，人直接把订阅关了，往后再想触达就没通道了。同一用户七天内不超过两条，是个可以照抄的默认值。多数小程序开发合同里写的首月免费运维，指的也就是这三十天，过了这个窗口再补，人力得另算。

满月这天把下面五条拉出来逐条对，全达标才算首月交付结束。工单线上化率不低于 95%，也就是纸单可以停印；单据结算平均耗时从原先的 6 到 8 分钟降到 90 到 150 秒；回访完成率不低于 85%，其中差评转售后工单的闭环率必须是 100%，一条都不能留；日对账差异控制在 1% 以内，并且连续七天没有挂账过夜；P0 级缺陷零个未闭环，P1 待办不超过五条且都已排进下一个版本。五条里任何一条没达标，这个月就不算收尾，下一阶段的功能迭代往后压，先把这条补上再说。