汽车服务小程序开发

门店真正需要的，是把一次服务从预约做到交车

车主在手机上选择保养、洗车或维修项目，只是服务的开始。车辆到店以后，服务顾问要核对车况和里程，技师检查后可能发现新增项目，车主决定做不做，门店再派工、领料、施工、质检、结算和交车。任何一步只靠口头、纸单或聊天记录，后面都可能说不清。

不同门店需要的小程序深度差别很大。洗车美容更关心预约时段、套餐次数和核销；快修快保看重车辆档案、到期提醒和标准项目；综合维修厂需要接车检查、报价确认和完整工单；连锁品牌还要处理总部与门店的价格、员工、客户归属和报表权限。

因此，项目第一步不是决定首页放几张轮播图，而是把门店现在怎样接车、谁给报价、怎样确认增项、何时算完工讲清楚。可以分为三种常见范围：

车型展示、试驾、二手车交易、车险销售或报价、道路救援和汽车金融属于不同业务，不会因为都和汽车有关就默认放进普通汽修项目。

电话能约时间，却很难把车辆和后续服务记完整

不少门店的预约来自电话、微信和临时口头登记。到了早高峰，两个顾问同时把车约到同一工位；车主说上次换过配件，员工翻聊天记录也找不到；技师检查出增项，顾问在电话里报过价格，结账时双方对项目理解不一致。

车辆服务周期长，人员又可能变化。保养记录留在老员工手机里，车主换了联系方式或换了车，系统没有清楚关联；总部想看门店经营，只能让各店月底重新填表。问题不是员工不努力，而是信息没有随着车辆和工单留下来。

小程序与管理端可以把预约、车辆、检测、确认和施工记录放在同一条业务线上。车主知道当前进度，顾问知道哪些事项待确认，技师只看分配给自己的任务，店长能追到关键操作。但系统不会替技师做诊断，也不能把提醒写成车辆一定存在某种故障。

预约要看门店产能，不能只开放一个日历

车主预约时通常需要选择门店、服务项目、车辆、日期和时段。门店后台则要考虑营业时间、工位或技师数量、项目预计时长、临时停约和节假日安排。洗车半小时和复杂维修一天，不能用同一种号源算法。

常见预约规则包括：

• 每个时段可以接多少辆车，是否按项目分别限量。
• 是否允许指定技师或工位，指定后怎样防止冲突。
• 最早提前多久预约，最晚何时改期或取消。
• 迟到后保留多久，爽约是否影响后续预约。
• 预约是直接成功，还是由门店确认后生效。
• 到店以后怎样转成接车单或维修工单。

门店无法准确承诺完工时间的项目，可以只预约到店检查，而不是在前台显示一个不可靠的交车时间。事故维修、疑难故障等项目通常要先检测，再确定工期和费用。

连锁项目还要根据位置、服务能力和营业状态展示门店。附近并不代表能做所有项目，轮胎、钣喷、新能源或特定设备服务需要按门店实际能力配置。地图和距离由第三方接口提供，无法替代门店对服务范围的维护。

车辆档案要方便使用，也要控制查看范围

车辆档案常见内容包括车牌、品牌车型、车架号或VIN、注册时间、当前里程、车主关系和历史服务记录。并非每个项目都需要收集完整VIN；完成预约只需要车型和车牌时，就不应为了“以后可能用到”要求车主提交更多资料。

车主可能有多辆车，一辆家庭用车也可能由不同成员预约。系统需要确认谁能查看、修改和解绑车辆，门店员工又能看到哪些字段。车牌、VIN、手机号、行驶里程和维修记录与个人使用情况有关，不应被所有岗位随意导出。

服务记录要区分门店施工事实和车主自行填写。门店完成的项目、里程、配件及质保说明应跟工单对应；车主手工补充的信息可以标明来源，避免混成门店承诺。若要从第三方车型库识别车型或查询保养数据，需要确认数据服务商、授权范围、费用和准确性，不能自行编造车型信息。

车辆转让、换牌、账号注销和资料更正也要有处理办法。档案不是永远不动的静态表格，关键变更需要按权限操作并留下必要记录。

接车检查，是工单能不能说清楚的起点

车辆到店后，服务顾问可以建立接车记录，核对车牌、里程、油量或电量、随车物品和外观情况。根据门店实际流程，可以拍摄车身划痕、仪表状态或需要关注的部位。图片和视频的拍摄范围、用途及保存时间应向车主说明，不拍与服务无关的个人物品和环境。

接车检查不是维修诊断。它先记录车辆进店时的可见状态和车主描述，再由技师执行检查。检测项目可以设置正常、建议处理、需要确认等状态，并附图片、视频或说明。门店负责检测结论和专业判断，小程序只负责呈现和留存已确认内容。

初步报价要写清服务项目、工时、配件、数量和价格。拆检后发现新问题时，应生成增项，说明原因和费用，由车主确认后再进入施工。若车主拒绝，系统保留拒绝状态，不应该默认为同意。

线上确认可以降低口头争议，但不等于把所有风险转给车主。门店仍需提供真实、清楚的检测与报价，不能用默认勾选替代明确选择。

维修工单要跟着车辆走，而不是跟着某个员工走

报价确认后，门店可以创建或更新维修工单。工单一般包含车辆、项目、技师、工位、预计时间、配件或材料、施工记录、质检结果和结算状态。员工换班时，下一位同事可以从工单看到当前进度，不需要重新问一遍。

常见状态可以根据门店流程取舍：

1. 已接车，等待检测。
2. 检测完成，等待车主确认。
3. 已确认，等待派工或配件。
4. 施工中，记录项目和异常。
5. 待质检，检查施工结果。
6. 已完工，等待结算或交车。
7. 已交车，进入售后和提醒记录。

状态越多不一定越好。每个状态都要有明确触发人和下一步动作，否则员工只会跳过。洗车美容可能只需要接车、施工、完成和核销；复杂维修则需要检测、报价、派工、领料和质检。

技师端应只看到分配任务和施工所需信息。服务顾问负责车主沟通与增项确认，收银处理结算退款，店长查看异常和权限。谁都用管理员账号虽然省事，却会让误操作和责任记录失去意义。

配件记录可以先做到工单引用、数量、价格和安装状态。若需要采购、调拨、批次、供应商、盘点和成本核算，就是完整配件进销存或ERP范围，应单独设计，不把一张配件表包装成完整库存系统。

完工、质检、结算和交车，缺一项都容易留下争议

施工完成后，技师提交结果，质检人员按门店规则检查。质检不通过时应退回对应项目，并记录原因；通过后再进入结算和交车准备。服务顾问可以向车主展示完成项目、实际使用的配件、费用变化和必要注意事项。

结算金额应来自已确认项目和实际变更，不在收银环节临时添加无法追溯的费用。线上支付、线下收款、套餐次数或优惠券如何使用，需要在工单上留下对应状态。退款时同时核对业务订单与支付结果，不能只在支付后台完成而门店工单仍显示原金额。

电子发票需要确定开票主体、申请字段和发票服务接口。没有自动接口时，可以先收集开票申请并显示人工处理进度；不能因为页面有“申请开票”就宣称已经完成税务系统对接。

交车时可以由车主确认车辆和服务项目，记录交车时间、质保或复查说明。具体质保范围、期限和责任由门店提供并承担，小程序用于展示和查询，不替门店作出统一承诺。

会员套餐和提醒要按服务事实运行

洗车次卡、保养套餐、会员价、优惠券和积分是常见功能，但每种都要有使用条件。套餐是否限定门店和车辆，能否转赠，项目升级怎样补差价，退款时已用次数怎么算，需要在售卖前说明。

会员余额或充值会带来跨店使用、赠送金额、退款和持续服务责任，不适合在规则不清时默认加入。红数科技负责确认后的技术实现，不对会员方案的经营结果作保证。

保养提醒可以根据上次服务时间、里程或门店设置生成。系统不知道车辆每天真实行驶多少，未接入可靠车况数据时，只能基于已有记录作时间或估算提醒，不能把它写成准确故障诊断。年检、保险等提醒同样需要明确日期来源、用户授权和业务边界。

订阅消息需要用户授权，具体可用模板和发送条件以实施时平台能力为准。短信会产生费用，也不能保证每条都被看到。重要的维修或交车事项，门店仍要准备人工沟通。

单店好用以后，连锁管理才有基础

连锁项目需要在总部与门店之间划分管理权。总部可以创建标准服务项目和指导价，各门店是否允许调整价格和时长；会员档案是否跨店可见；套餐在哪些门店可用；维修记录归门店还是归品牌，都要先确定。

常见角色包括总部管理员、区域负责人、店长、服务顾问、技师、收银和财务。区域负责人可能查看管辖门店报表，但不能改其他区域设置；门店技师不能查看无关客户资料；总部财务看汇总金额，不等于能修改工单。

报表口径也要统一。预约数量、到店率、工单产值、已收金额、退款、套餐核销、技师工时和客户复购分别如何计算，不能让每家门店自己理解。系统会按确认口径统计，不把所有数字简单放进一个大屏。

外部系统和设备，必须先拿到接口条件

汽车服务项目常见对接包括VIN车型库、车牌识别、地图、支付、短信、打印机、电子发票、ERP、CRM、POS、配件库存和门店硬件。每一项都要确认服务商、接口文档、正式授权、测试环境、费用和配合人员。

车牌识别需要相机或识别服务，准确率受角度、光线、污损和网络影响；车型数据由数据服务商提供，覆盖范围和更新频率要核实；已有ERP如果没有开放接口，也不能只靠一个账号完成自动同步。

对接时还要确定主数据。客户、车辆、项目价格和工单在哪个系统维护，双向修改发生冲突时以谁为准。接口正常返回只是最基本情况，超时、重复、断网、错误数据和服务停机都要纳入测试。

第三方认证、云资源、短信、地图、车辆数据、识别服务、支付、发票、硬件、接口调用和厂商配合费用通常按实际发生单列。外部接口升级后的适配，根据改动影响判断是日常维护还是新增开发。

项目按一张真实工单推进

平台审核时间和结果不完全由开发团队控制。因主体、类目、内容或业务材料产生的补充要求，双方按实际反馈处理；若反馈引出合同外功能，再确认范围和排期。

周期和费用，取决于做到预约还是做到完整工单

以下范围用于立项和早期选型，不是需求未确认前的固定报价。

影响费用的主要因素包括门店数量、预约排期、车辆字段、接车检测、报价增项、工单状态、技师工位、套餐支付、权限层级、接口数量、数据迁移和高峰使用量。页面不多并不代表简单，检测、授权和工单每个状态都要测试。

小程序认证、云服务器、域名与证书、短信、地图、车辆数据、识别服务、支付、电子发票、设备、接口调用、厂商配合、测评和专项咨询等第三方费用按实际发生另计。保险、救援、二手车、试驾、汽车金融、完整配件ERP、多平台发布和旧系统迁移，除非写入确认清单，否则不属于基础版本默认内容。

交付要让门店人员真正接得住

一套定制汽车服务小程序通常交付以下内容，最终以合同和功能清单为准：

• 车主使用的小程序及约定的预约、车辆、报价和进度功能。
• 门店工作端、管理后台和服务端程序。
• 需求清单、原型、UI设计稿和角色权限表。
• 预约、检测、报价、增项、工单和交车规则说明。
• 合同约定范围内的支付及第三方接口程序。
• 测试记录、已知限制、部署和版本发布信息。
• 合同约定范围内的源代码及必要技术资料。
• 管理账号交接、后台操作说明和培训。

源码交付不代表车型库、识别服务、支付平台、商业组件、硬件和既有系统的权利一并转移。服务器、小程序账号、支付账号和正式车辆数据由谁持有，需要在项目开始时确定。

验收要让一辆测试车完整走完流程

验收不能只提交预约、看后台多一条记录。建议准备至少两辆测试车和多个账号，让车主、服务顾问、技师、收银和店长分别操作，覆盖正常工单和增项、取消、退款等异常情况。

已经确认的功能没有按约定运行，属于缺陷修复；验收时增加保险报价、车牌设备、完整配件库存、新系统接口或改变工单流程，属于需求变化。两类问题分开记录，才能判断完成标准和后续排期。

上线先选一条业务线跑顺

正式推广前，可以先选择一个门店、一组标准项目或非高峰时段试运行，让员工用真实车辆走完预约、接车、报价、增项、施工和交车。现场使用几天后，哪些状态容易误解、哪些字段重复填写会更清楚，再做小范围调整。

红数科技可在合同范围内提供上线支持、程序问题修复、后台培训和后续迭代评估。售后需要写清维护期限、响应方式、服务器与第三方服务续费、数据备份责任，以及平台或接口规则变化后的适配方式。

汽车服务小程序是否可靠，不只看车主端页面是否好看。预约不冲突、车况有记录、增项经确认、工单有人接、质检有结果、交车后查得到，这些环节在门店忙起来时仍能运行，才是项目真正达到交付标准。