汽修智慧门店小程序开发

汽修门店真正难管的，不只是预约和收款，而是车辆进店以后的一连串细节：谁接的车、检查出什么问题、客户同意做哪些项目、用了什么配件、哪位技师施工、什么时候质检、最终为什么收这笔钱。红数科技围绕这套实际工作方式定制车主端小程序和门店管理后台，让预约、接车、报价、维修工单、配件、会员、结算与车辆档案前后对应，也为单店和连锁门店留下后续扩展空间

预约不撞单: 门店、项目、工位、技师和时间段按实际接待能力安排到位
接车有记录: 里程、油量、车况照片、客户需求和随车物品均可当面确认
报价可确认: 检测项目、工时、配件、优惠和施工增项分别取得客户确认
进度看得见: 待检测、待确认、施工中、质检和待交车状态随时可以查
配件对得上: 采购、入库、领料、退料和维修工单用料能够互相核对
车辆档案全: 保养维修、历史里程、配件、套餐和提醒跟随车辆持续保存

详情介绍

先分清门店真正要管的是什么

很多汽修系统看上去功能很多，真正用起来却经常卡在接车以后。预约信息只写了“做保养”，服务顾问还要重新问车型和里程；检测结果发在聊天里，客户是否同意施工没人说得清；技师换了配件，仓库没有领料记录；交车时金额又与最初报价不一致。问题并不在少一个页面，而在每个岗位记录的事情没有接起来。

汽修智慧门店小程序开发，一般包含车主使用的小程序、服务顾问与技师使用的工作端，以及店长、仓管、财务使用的管理后台。系统围绕车辆从预约到交车的过程设计，门店原来已有的接待方式、项目名称、工时规则、配件管理和会员规则，也需要在开发前逐项理清。

使用人	日常要处理的事情
车主	绑定车辆、选择门店、预约服务、确认报价、查看进度、支付和查维修记录
服务顾问	接车检查、建立工单、登记客户需求、发起报价确认、通知交车
技师	接单、检测、填写施工记录、申请配件、反馈增项、提交完工
仓管	采购入库、领料、退料、调拨、盘点并核对工单用料
店长	安排工位和人员、查看在厂车辆、处理异常、核对经营数据
财务	核对订单、支付、退款、优惠、储值消费和开票记录

预约、接车和维修工单不是一回事

预约解决的是“什么时候来、来哪家店、准备做什么”。它可以提前占用某个时间段，也可以根据门店接待能力限制人数，但预约成功不等于门店已经确认车辆故障，更不代表客户同意了维修费用。

车辆实际到店后，服务顾问应核对车主、车牌、车型、里程、油量、外观车况、随车物品和本次诉求，必要时拍照留存，再由预约转成维修工单。爽约、取消、改期、提前到店和直接到店都要有各自的处理方式，不能为了界面简单而把几种状态混在一起。

接车单重点证明“车辆交到门店时是什么状态”，维修工单则记录“门店后来检查了什么、客户同意做什么、实际做了什么”。两者有关联，但不能互相代替。

一张维修工单应该记录什么

工单不是一张简单的消费订单。它至少要把客户要求、检测判断、施工内容、人员、工时、配件和金额连在一起。门店采用纸单、电子单还是两者并用，也会影响签字、打印和归档方式。

记录内容	开发时需要确认的细节
车辆信息	车牌、VIN、品牌车型、发动机或动力类型、当前里程
接车情况	进店时间、油量、外观照片、随车物品、客户描述
检测结果	故障现象、检测说明、建议项目、检测图片或视频
施工项目	项目名称、标准工时、实际工时、负责技师、工位
使用配件	配件编码、品牌规格、数量、批次、领料与退料记录
费用明细	工时费、材料费、其他费用、优惠、套餐抵扣和应收金额
确认记录	确认人、确认内容、确认时间，以及取消或变更情况
完工交付	质检结果、完工时间、交车时间、结算和售后说明

不同门店的工单习惯差异很大。有的快修店按项目快速开单，有的综合维修厂要经过检测、报价、派工、领料、施工和质检，有的连锁门店还要执行总部统一项目与价格。开发前把这些差异写进原型和字段表，后面才不会靠不停加备注来补救。

检测报价与施工增项怎样确认

车辆进厂时，车主往往只知道异响、故障灯或保养到期，准确项目要等检测后才能确定。因此，系统中的初步需求、检测报价和最终结算必须分开。

检测完成后，报价单应列出建议项目、工时、配件、数量、单价和预计金额。客户可以整单确认，也可以只选择其中部分项目。对于暂不施工的项目，门店可保留检测结论和建议，但不能自动算进本次应收。

施工中发现新问题，需要另行发起增项确认。增项内容、费用、原因、凭证和客户确认时间应留在原工单内。配件品牌或规格发生替换、施工项目被取消，也要记录变更前后内容。这样到了结算环节，报价、增项、取消项目和实际施工才解释得清。

工位、技师和施工进度怎样安排

门店排班不能只做一个日历。一次服务可能先在检测工位检查，再转到机修、轮胎或美容工位；一张工单也可能由多位技师协作。是否允许一个技师同时处理多辆车、项目怎样计工时、返工怎样记录，都要按门店实际规则确定。

车主端适合显示容易理解的状态，例如已接车、检测中、待确认、施工中、质检中和待交车。门店内部则需要更细的节点，包括待派工、缺料等待、暂停施工、外协处理中和返工。内部备注、技师绩效或敏感故障判断不应原样展示给车主，两端信息要有明确边界。

进度更新应由真实操作触发，而不是为了看起来热闹自动跳转。技师接单、配件领料、提交完工和质检通过后，工单状态随之变化，店长才能看清车辆在哪里等待、哪里积压。

配件库存为什么必须对应工单

配件管理如果只有“库存数量”，很快就会出现账面有货、货架没货，或者仓库少了配件却找不到用在哪辆车上的情况。汽修门店至少要处理采购入库、其他入库、工单领料、退料、调拨、盘点和报损。

工单使用配件时，应记录领料人、数量、仓库、时间和对应施工项目。未使用的配件退回后，库存与工单成本同时调整。对于序列号、批次或质保要求较高的部件，还要根据业务需要保留批次和供应商信息。

如果客户自带配件，系统应能明确标记，避免误算材料收入，也便于门店写明安装责任边界。负库存是否允许、临时采购怎样入账、跨店调拨由谁审批，都应在开发前确认。

车辆档案与车主账号怎样建立关系

车辆档案的主体是车辆，不只是某一次下单的人。一个家庭可能多人使用同一辆车，企业车队也可能由管理员统一预约。换手机号、车辆过户、车牌变更和多人绑定时，需要有清楚的验证与处理规则。

档案可持续保存车型、VIN、历史里程、接车照片、维修保养记录、使用配件、套餐权益、质保信息和提醒计划。保养提醒应根据时间、里程或门店规则生成，不能把所有车辆简单设成同一个周期。车主看到的是与自己车辆有关的记录，门店员工只能按岗位权限查询和修改。

会员卡、次卡、套餐和储值怎样记账

会员功能最容易在规则没有说清时产生争议。洗车次卡、保养套餐、折扣卡和储值余额看起来都属于会员权益，但核销和退款方式完全不同。

权益类型	必须提前确定的规则
次卡	适用项目、可用次数、有效期、适用门店、是否可转赠
套餐	包含哪些工时和配件、是否可拆分、升级项目怎样补差价
折扣卡	折扣范围、排除项目、是否与其他优惠同时使用
储值	充值与赠送金额分开记录、消费扣减顺序、退款处理方式
优惠券	使用门槛、适用项目、有效期、门店范围和叠加规则

核销必须落到具体工单和具体项目上。连锁门店还要确定权益是总部通用、部分门店通用还是单店使用，以及跨店消费后的结算办法。系统可以执行已经确认的规则，但不能替门店省略经营和财务判断。

单店与连锁门店的权限区别

单店系统重点是把接待、施工、库存和结算管顺。连锁门店还要处理总部统一项目、门店差异价格、跨店会员、跨店调拨、区域管理和数据查看范围。

总部管理员、区域负责人、店长、服务顾问、技师、仓管和财务不应共用一个管理账号。每个角色能够查看哪些门店、能否改价、能否退款、能否调整库存、能否导出客户资料，都要单独授权。关键操作保留时间和操作人，离职员工账号及时停用。

支付、退款、开票和对账

车主可在小程序内支付，也可以到店使用门店已有的收款方式。无论采用哪种方式，订单状态、实收金额、支付渠道、退款和开票记录都应与维修工单对应。不能仅凭页面显示“支付成功”就认定财务已经到账，支付通知、重复通知、超时关闭和退款结果都要经过系统校验。

部分退款要说明退的是哪个项目、配件或会员权益；整单作废则要同步处理库存、次卡核销和储值扣款。开票通常要记录开票抬头、税号、金额和状态，具体与门店现有财务或开票系统对接到什么程度，以双方确认的接口条件为准。

旧系统、打印设备和第三方接口

已有门店通常不会从空白开始。旧系统中的客户、车辆、项目、配件、库存和会员余额是否迁移，需要先检查数据完整性、字段格式和重复情况。迁移前应确定截止时间，保留原始备份，并通过抽样核对确认数量和余额。历史数据质量差时，不能承诺一次导入后自动变得准确。

维修工单打印、小票打印、扫码设备、企业微信、地图、短信、支付和财务系统都可能涉及第三方能力。开发前需要确认设备型号、接口文档、账号权限、调用费用和平台审核条件。没有开放接口的旧系统，不能把“看得到数据”理解成一定可以直接打通。

车辆资料、照片与隐私保护

车牌、VIN、手机号、里程、行驶与维修记录、车况照片都属于需要妥善处理的客户和车辆资料。小程序应说明收集用途，只获取完成预约、维修和售后所需的信息，不把无关权限设为使用前提。

后台按岗位控制查看、编辑、导出和删除权限，重要操作保留记录。照片和附件设置访问边界，测试环境不长期使用真实客户资料。数据保存期限、备份、离职交接和异常账号处理，也应纳入门店日常管理。

新能源汽车维修如果涉及高压系统，仍应由具备相应条件的人员、工位和设备执行。小程序可以记录资质、检查项和作业过程，但不能代替线下安全操作制度。

项目怎样推进

阶段	主要工作	当阶段确认结果
业务梳理	走查预约、接车、检测、报价、施工、领料、质检和结算	业务范围、角色权限、异常处理和接口清单
原型设计	画出车主端、员工端和管理后台的页面与操作路径	页面原型、字段表、状态变化和确认规则
视觉设计	根据门店品牌完成小程序界面和后台关键页面设计	视觉稿、组件样式和主要页面效果
程序开发	完成前后端、后台、权限、消息、支付及约定接口	可供分阶段测试的功能版本
数据准备	清洗基础项目、配件、车辆、会员和门店资料	导入模板、迁移规则和核对结果
联调测试	按真实车辆进店过程跑通正常与异常情况	问题清单、修复记录和验收版本
发布交付	提交平台审核、配置正式环境、培训并上线	账号资料、源码或约定成果、使用说明和验收记录

项目开始时，红数科技会先把门店现有单据、岗位和处理方式了解清楚，再确定哪些做进首期，哪些留作后续扩展。开发过程中按原型、视觉和功能版本逐步确认，避免到上线前才发现双方对“工单”或“会员”的理解不同。

周期通常由哪些事情决定

只包含预约、车辆档案、基础维修工单和简单后台的项目，通常需要约6至10周。增加检测报价、施工进度、配件库存、会员权益和多岗位权限后，常见周期约为10至16周。连锁门店、较多历史数据迁移、复杂财务规则或多个第三方接口，通常需要14至24周或更长。

这些时间从需求和资料基本确认后估算。门店数量、原型确认速度、第三方接口条件、平台审核、历史数据质量以及需求变更都会影响实际排期，最终以项目范围和计划表为准。

费用为什么不能只按页面数量计算

汽修小程序的工作量主要藏在业务规则里。两套系统都叫“维修工单”，一套可能只是登记项目和收款，另一套还包括检测报价、客户授权、派工计时、配件领退、增项、质检、返工和多门店结算，开发量并不相同。

正式费用会根据门店数量、用户角色、工单流程、库存深度、会员规则、支付退款、历史数据迁移、第三方接口、部署方式和交付范围书面核算。报价单应列出首期功能、可选功能、第三方费用、维护范围与变更方式，让客户能按同一范围比较不同方案。

哪些门店更适合做定制开发

现有通用软件与实际接车、派工或结算方式不匹配的汽修厂。
同时经营保养、维修、轮胎、洗车或美容，需要统一车辆档案的综合门店。
已有稳定会员和车辆资料，希望把预约、进度、权益与售后放到车主端的门店。
多门店经营，需要总部规则、门店权限、跨店会员和统一数据的连锁品牌。
需要对接现有配件、财务、企业微信或设备系统，并且已有明确接口条件的企业。

如果门店业务还在频繁变化、基础项目和价格没有统一，先梳理经营规则通常比直接开发更稳妥。小程序会把规则执行得更快，但也会把原来含糊的地方放大。

交付时能拿到什么

具体交付内容以合同和项目清单为准，常见成果包括：

已确认的需求说明、页面原型、字段和权限清单。
车主端小程序、约定的员工工作端和门店管理后台。
视觉设计稿、前后端程序及约定范围内的源代码。
数据库结构、部署配置、接口说明和第三方配置清单。
基础资料导入模板，以及约定范围内的数据迁移结果。
测试记录、上线版本、管理员账号和操作说明。
面向店长、服务顾问、仓管等岗位的操作培训。
合同约定期限内的故障修复和技术维护。

验收不只看页面能不能打开

验收应按真实业务逐条走，不用“功能大致都有”代替结果。至少准备预约客户、直接到店、取消预约、报价部分确认、施工增项、配件退料、会员核销、部分退款和权限越权等测试情况。

验收重点	可以怎样检查
预约	门店容量、时间冲突、取消改期和到店转单是否正确
接车	车辆、里程、照片、客户要求和接车确认是否完整
报价	部分同意、拒绝项目、增项和价格变更是否保留记录
施工	派工、工位、进度、暂停、完工和质检状态是否准确
配件	入库、领料、退料、盘点和工单成本是否能核对
会员	次数、余额、有效期、适用门店和退款结果是否正确
结算	报价、实际项目、优惠、支付、退款和开票是否对应
权限	不同岗位能否只查看和操作被授权的数据
数据	迁移总量、关键字段、余额与抽样记录是否核对通过
终端	常用手机、门店电脑、打印和扫码设备是否正常使用