很多门店找技术服务商时，手里只有一个大致想法：车主能预约，店里能开单，还要做会员和营销。这样的信息可以开始沟通，却还不能直接拿来出开发方案。同样叫“预约保养”，单店可能只需要选择时间和项目；连锁门店还要分配门店、工位、技师，判断配件库存，处理跨店会员权益。前面的资料差一点，后面就可能多出一套完全不同的流程。
所以，方案前期不是让门店先写一份厚厚的需求文档。更实际的做法，是把现有业务原样摊开：现在怎么接车、怎么报价、谁确认、哪里容易出错，希望小程序替哪一步省时间。资料真实，方案才不会停在一张看起来很全的功能表上。
先交一份门店经营底账
这部分不需要做得漂亮，但要准确。单店和连锁的方案差别很大，直营、加盟、联营在账号权限、价格管理、会员通用和数据归属上也不是一回事。
建议准备这些基础信息：
- 门店数量、所在城市、营业时间、门店地址、联系电话和导航定位；
- 每家门店的工位数、主要设备、日常接车量区间，以及高峰时段；
- 现有岗位和人数，包括接待、技师、库管、收银、店长、财务和总部运营；
- 主营业务范围，例如保养、快修、轮胎、钣喷、美容、洗车、年检代办或保险协作；
- 当前最想解决的两三个问题，比如预约到店后仍要排队、报价确认慢、库存账不准、老客户到期提醒靠人工；
- 项目准备先在哪些门店使用，计划什么时候上线，大致预算由谁确认。
“提高效率”“做好会员”还不算可落地的目标。换成门店每天确实会发生的事，就容易判断了：接待开一张工单要填几遍车牌和电话；客户确认增项现在靠口头、纸单还是聊天记录；保养到期后由谁筛选客户、谁发送提醒。方案里的优先级，应该从这些动作里定。
把车辆进店后的真实流程画出来
汽修小程序不是独立的一块屏幕。车主在小程序里提交的预约，最终要落到门店接待、工位、技师、配件、结算和售后。前期最好找一位熟悉门店日常的人，把一辆车从预约到离店的过程讲一遍。现有纸质单据、表格和系统截图都可以作为资料，不必重新制作。
至少要讲清下面几件事：
- 预约是否需要选择门店、车型、服务项目、到店时间和接送车；
- 到店后由谁接车，是否做外观检查、拍照、里程和油量记录；
- 检查后怎样报价，客户用什么方式确认新增项目，取消项目怎样留痕；
- 工单如何派给技师，计件、提成、工位和预计完工时间是否需要进入系统；
- 领料、退料、缺货调拨和临时采购现在怎么处理；
- 完工后由谁质检，怎样结算，是否支持套餐、优惠券、储值、积分或挂账；
- 离店后需要保留哪些维修记录，保养提醒、满意度回访和售后问题由谁负责。
流程里有分歧也不用先强行统一。比如有的门店先检测再开单，有的门店基础保养直接开工；这种差异要在方案里看到，才能判断是保留两种流程，还是上线前统一门店做法。最怕的是把理想流程写进需求，开发完成后才发现一线接待根本没法按它操作。
服务项目、配件和价格要能对得上
小程序要展示什么、客户能买什么，取决于门店现有的商品与服务资料。请准备服务项目表、工时费规则、配件目录、套餐、会员权益、优惠规则和适用门店。能提供 Excel 最好；如果目前只在旧系统里，也可以先导出样表，让项目方看清字段和数据量。
这里经常卡住的不是页面，而是价格到底由什么决定。相同的机油保养，是否随车型、排量、机油规格和用量变化；不同门店能否独立定价；线上价格是定金、预估价还是最终结算价；优惠券能不能和会员折扣叠加。规则没有确认，前端写一个“￥399”很容易，真正结算时却没有可靠依据。
配件资料也别只给一个名称。常用字段通常还包括品牌、规格、适配车型、单位、采购价、销售价、库存上下限、供应商和仓位。是否需要做到批次、序列号或轮胎 DOT 日期，要看门店的实际管理深度，不必一开始全部上齐。
主体、账号和平台资料不能等到上线再找
小程序注册、认证、备案和支付接入都需要明确的经营主体。方案启动时应确认由哪家公司或个体工商户持有小程序，谁保管管理员账号，收款进入哪个商户号和银行账户。常用资料包括营业执照、法定代表人或经营者信息、管理员信息、对公账户或结算账户，以及平台要求的行业资质。具体清单要以申请当时微信公众平台和微信支付页面的提示为准。
如果小程序已经注册，应提供 AppID、现有类目、认证和备案状态，并安排有权限的管理员配合授权。账号密码不建议直接写进普通需求文档，更不要在多人群聊里长期保存。由负责人在需要时完成扫码、授权或密钥交接，责任会清楚很多。
按照现行小程序备案要求，主办者信息、负责人信息和小程序信息都需要如实提交；涉及前置审批的服务，还要按实际经营内容准备相关材料。支付接入也不是开发方单方面就能办完，商户主体、结算账户、经营场景和管理员必须对应得上。
旧系统、设备和外部接口先摸清边界
门店已经在用收银软件、汽修管理系统、进销存、财务软件或企业微信，前期要把系统名称、版本、使用门店、现有数据量和对接方式列出来。最好同时确认原供应商是否提供接口或数据导出，接口是否收费，历史合同对数据迁出有没有限制。
需要对接的对象还可能包括微信支付、短信、电子发票、地图、打印机、扫码枪、车牌识别、工位看板、供应链平台和财务系统。不要只写“需要打通”，要说明哪一边产生数据、另一边接收什么、多久同步一次、失败后由谁处理。没有开放接口的旧系统，不能仅凭需求表就承诺自动同步。
历史数据准备一份脱敏样例，比口头说明有效得多。客户档案、车辆档案、维修记录、会员余额、积分、套餐余次、库存和未结工单分别有多少条，字段里有没有重复手机号、错误车牌、空车型和同名配件，都要先看到。数据迁移通常还要约定截止时间、清洗规则、核对方式和旧系统停用后的查询安排。
客户信息怎么收、谁能看，前期就要定
汽修业务会接触手机号、车牌号、车辆识别代号（VIN）、行驶里程、维修记录、定位、支付记录等信息。小程序准备采集哪一项，就要能解释为什么需要、在哪个环节使用、保存多久、哪些岗位可以查看。不能因为“以后可能有用”就默认全部收集。
门店应准备现行的隐私政策、会员协议、储值或套餐规则、售后条款；如果还没有，就需要结合实际功能补齐。涉及第三方短信、地图、客服、统计或支付服务，也要列出服务商和数据用途。微信小程序的用户隐私保护指引要求开发者说明处理的个人信息种类和用途，相关接口调用也受隐私授权机制约束。我国《个人信息保护法》同时要求处理个人信息具备明确、合理的目的，并与处理目的直接相关。
后台权限要按岗位谈，不要笼统地写“员工都能看”。接待是否能看客户全部消费记录，技师是否需要看到手机号，加盟店能不能查看其他门店的会员，离职员工账号怎样停用，这些决定了后台角色、数据权限和操作日志怎么设计。
页面素材不用一步到位，但品牌信息要有准数
设计前应提供品牌中文名、规范写法、Logo 源文件、标准色、门店环境照片、服务项目实拍图、门店介绍和页面中必须出现的提示语。Logo 尽量提供 SVG、AI 或透明底 PNG，不要只发一张从宣传图里截下来的小图。
暂时没有完整视觉规范并不妨碍方案启动，服务项目图片也可以分批补齐。只是涉及名称、价格、使用条件、服务承诺和法律责任的文字，必须由门店确认，不能让设计或开发人员凭经验代写后直接上线。
最后确认谁拍板、怎样验收
项目最容易耽误的地方，往往不是开发本身，而是同一个问题由几个人给出不同答案。门店侧需要确定一位项目负责人，能协调老板、店长、财务、库管和一线接待；价格、流程、页面和上线资料分别由谁确认，也要提前说好。
验收不要只看“有没有这个按钮”。预约提交后门店是否收到提醒，客户确认的报价能否回到工单，退料后库存是否恢复，跨店会员有没有越权，支付退款和财务记录能不能对应，这些才是能够执行的验收条件。准备三到五组常见业务单据，再加一两组退款、缺货、改价或重复客户这样的异常情况，测试会更接近正式营业。
资料准备到可以开工，不等于每个细节都已经定死。门店经营主体、业务范围、主要流程、数据来源、系统接口和责任人必须明确；页面文案、部分图片和低优先级功能可以在排期内继续确认。红数科技据此才能把需求分成首期必做、后续可加和暂不适合做的内容，并把原型、接口、数据迁移、测试与上线安排落到同一份项目范围里。
在正式方案会上，带齐下面这组资料通常就够用了：门店基础信息表、组织与权限表、现行业务流程和单据、服务与价格表、配件样表、会员及营销规则、旧系统及接口清单、脱敏数据样例、主体与平台账号状态、品牌素材，以及项目负责人和验收人名单。缺少的内容可以当场标明负责人和确认时间，别用一句“后面再说”带过去。
文中平台与合规部分核对了以下公开资料；实际申请时仍应以平台页面和经营所在地主管部门的最新要求为准。
