眼镜店管理系统需求方案：从业务流程到数据建模的完整拆解

做过不少零售业态的系统说实话眼镜店是我见过业务规则最拧巴的一类。表面看就是个进销存加会员管理可真往里做SKU怎么建、订单怎么流转、加工单怎么关联、验光数据怎么存每一层都是坑。这也是为什么很多通用收银软件在眼镜店用不起来——不是功能少是压根没按眼镜行业的业务逻辑设计。这篇就把我这些年总结的眼镜店管理系统需求方案完整拆开从业务流程、数据建模到报表和实施按一个真正能落地的系统该有的样子来讲给准备上系统的门店老板和产品研发都做个参考。1. 为什么普通进销存撑不起眼镜店先认清门店业务的三层特殊性聊需求之前得先把眼镜店到底特殊在哪说清楚。不下定义、不上理论就说业务现场的真实感受。很多人以为眼镜店跟服装店、便利店差不多进货、上架、扫码、收银、看库存。真进去做系统就知道完全不是这么回事。1.1 三种典型门店形态决定了需求起点完全不同眼镜店看着都是卖眼镜实际上业态差别很大系统需求不能一概而论。我一般把客户分成三类一是传统零售店以卖镜架、太阳镜、成品老花镜为主镜片也有但占比不高。这类店的核心痛点是库存和促销系统逻辑跟普通零售差不多但多了个镜片加工服务的穿插。二是专业验光配镜店有验光室、有持证验光师营收大头是定制镜片加镜架。这类店的核心痛点是订单履约链路——验光数据怎么传到加工环节加工进度怎么反馈给前台客人来取镜怎么快速找到订单。这才是眼镜店管理系统真正要下功夫的地方。三是连锁品牌店有总部、多门店、中央仓。这类店在以上所有需求之上还要考虑跨店调拨、会员档案共享、统一采购、各门店经营数据对比分析。很多连锁店早期用Excel管理都行一旦超过三五个门店数据一分散管理必然失控。需求方案第一步不是写功能清单而是先确认自己属于哪类。三类店的侧重点差异很大一份需求文档要是三类通吃结果往往是哪类都没做好。1.2 “眼镜不是标品”一单交易要拆成商品、处方、加工三个对象普通零售系统里一笔交易就是一个商品加一个价格。眼镜店不行。你去配一副眼镜系统里同时发生了三件事卖了一副镜架这个是库存实物、卖了一对镜片这个可能是按度数定制的没有现货库存、产生了一份加工任务把镜片按验光参数磨好装到镜架上。这三件事各自有独立的信息流但又必须挂在一张订单下。我用个直白的方式描述帮你理解这背后的数据结构商品层面镜架有SKU、有库存、有条码镜片不行镜片的基础属性是“折射率膜层光度范围”真正卖出去那一刻才确定球镜、柱镜、轴位。处方层面这单配镜是近视还是散光瞳距多少镜眼距多少这些参数不是商品属性是人的属性要跟着会员档案走。加工层面镜片是否需要定制、发货需要几天、磨边用什么机台、是否需要开槽打孔这是生产任务普通进销存完全没有这个概念。这就解释了为什么拿普通收银软件硬套眼镜店会非常难受订单打不出来完整加工单镜片库存永远对不上验光数据只能靠手写小纸条夹在病例里。做需求方案的时候第一条就要立住这个原则——系统里订单一拆为三但三块数据必须强关联。谁把这个关系理清楚了整个系统的骨架就立住了一半。2. 从建档到取镜订单履约主链路的流程设计与状态流转说完了业务特殊性接下来进入系统需求方案的核心订单履约链路。这是眼镜店管理系统的主动脉从客人进店到最后取走眼镜每一步该产生什么数据、该触发什么动作系统里必须有严格的流程控制。2.1 一张配镜订单的生命周期七个状态的完整流转门店每天都在处理配镜订单。我梳理过一份通用状态流转经过多个项目验证推荐直接参考使用状态含义触发条件系统动作待检查客户已建档但验光未完成新建配镜订单记录客户基础信息及本次诉求新配/换镜/维修已验光验光数据已录入验光师保存验光单锁定验光参数快照生成处方版本待收款商品已选但未付款前台选品完成校验库存、锁定镜架现货、生成应收明细已收款订单已支付收银完成联动创建加工任务单若有定制镜片发起采购订料单加工中镜片已出库或到货进入加工仓库确认备料完成/工厂发货记录加工人员、机台、起止时间待取镜加工完成质检通过质检员确认合格生成取镜通知短信/微信记录寄存位置已完成客户取走眼镜前台验货取镜关闭订单回写会员消费记录与售后起算日期这套状态机最大的价值是责任到人、进度可查。哪个环节堵住了打开订单列表看一眼状态颜色就知道。我在需求文档里通常会加一条硬约束任何状态流转都必须记录操作人和操作时间不允许直接跳状态比如“已收款”不能直接变“已完成”必须经过加工和质检。2.2 每个环节的关键字段验光单与加工单的数据要求订单流程拆开后要把每个环节的字段需求写明白。我挑两个最容易出问题的环节重点讲。验光单数据。很多门店现在还靠手写验光单验光师在纸质单上登记球镜、柱镜、轴位然后和订单订在一起。系统化的第一步就是把这些字段结构化。一份完整验光必录字段包括球镜左右眼、柱镜左右眼、轴位、瞳距选录字段包括瞳高、下加光、棱镜、角膜曲率、主导眼、矫正视力。特别注意散光等参数过矫还是欠矫、是否用试戴架调整过这些主观判断也必须能记录在备注里。验光数据要作为历史档案长期保存同一会员每次验光产生一个版本下次再来时能对比光度变化——这是营销和复购的底层数据后面专门说。加工单数据。加工单是眼镜店独有的单据字段需求一定要写细。除了关联验光单和商品信息还要包含镜架尺寸参数框高、框宽、鼻梁距、镜片加工属性是否渐进、通道长度、移心量、是否染色/变色、加工工艺磨边、开槽、打孔、抛光以及最重要的——定制镜片是“无现货需向工厂下单”还是“现货现磨”。有定制加工能力的门店系统里还要有备料状态镜片是否已通知工厂发货、预计到货时间、物流单号。这块信息不同步是门店客诉的高发源——前台不知道镜片到没到客户问起来只能含糊回答系统把这个链路管起来之后前台一查订单状态就能给出准确答复。2.3 退换、修改与售后的状态回退设计订单流程里不能只设计正向流转还要预留异常处理分支。最典型的两类情况客户验光后改主意换镜架或改镜片折射率。此时订单若还在“待收款”或“已收款未加工”阶段允许修改商品明细重新计价一旦进入“加工中”镜片可能已经订料修改就必须走审批流程涉及定制件还要确认工厂是否已排产已发生成本要生成退换差价单。这个逻辑必须在需求方案里写清楚否则门店遇到退换只能线下手工处理数据链条断掉之后库存和财务都会对不上。取镜后发现光度不适应或镜架变形需要返修。系统要有售后服务单关联原订单号、问题描述、处理方式重新验光/返厂/调校、处理结果。售后单打开的同时要能一键还原原订单信息——配的什么镜片、什么参数、哪天取的镜处理售后时这些都是必要信息。这一步经常被需求文档漏掉觉得一个维修而已没必要录系统真正做进系统以后才发现客诉处理有数据支撑和没有数据支撑完全是两个管理水平。3. 商品档案与库存建模镜片、镜架、隐形眼镜是三种完全不同的数据对象做需求方案的时候商品档案和库存建模是最容易被低估的部分。不少人觉得这不就是商品名称、进价、售价、库存数量吗随便一个Excel也能管。但在眼镜店场景下商品管理有三个完全不同的数据对象建模逻辑差异极大我用真实业务来拆。3.1 镜架档案最接近标准零售SKU但也有自身特点镜架是眼镜店唯一可以按标准SKU管理的实物商品。它的档案字段相对清晰品牌、型号、颜色、材质金属/板材/TR90/β钛等、尺寸框宽、鼻梁距、腿长有些品牌还分A/B/C尺寸、上市年份、采购价和多个售价策略。但镜架有个库存上的坑同一款型号不同颜色看起来是一样东西实际库存必须分开。很多门店在这一步偷懒把“某品牌某型号”建成一个SKU所有颜色共用库存盘点时怎么都对不上。我的建议是镜架SKU至少细分到“型号颜色”有条件的连尺寸都分开建档——虽然前期录入工作量大但后续库存和盘点会省非常多事。另外镜架的条码管理也值得提一句。不少镜架出厂自带条码或款号但同品牌同型号同颜色不同批次可能条码重复仓库到货时必须重新贴制店内唯一码。这个步骤要在系统上线前做完否则销售端扫码容易串货盘点时更乱。3.2 镜片档案SKU是“参数组合”备料靠“光度段”而非具体度数镜片是整个系统中建模难度最大的对象。它不像镜架那样有一个个实物SKU可以扫码镜片的库存管理要分两个层面来看。第一层是“方案库”。系统里维护的不是某个具体度数镜片而是一组规格组合品牌、系列、折射率1.56/1.60/1.67/1.74等、膜层防蓝光/变色/偏光/渐进等、功能类型单光/渐进/抗疲劳等。这一层负责定价和选品前台开单时选的是方案而不是选某一片实物。第二层是“备料库存”。镜片实际是按光度范围备货的比如某系列从-0.00D到-8.00D每0.25D一级散光另算。门店不可能备齐所有度数通常只备最常见的光度段我见过门店备-2.00D到-6.00D的居多超出常备范围的要么从同行调货要么向工厂定制。所以库存管理要区分“现货库存”和“工厂在途”两个口径现货可以马上加工在途要回货才能加工。这里有个关键需求必须写清楚镜片销售是按“副”计价的但库存按“片”管理。左右眼光度可能不同系统在下单时要自动判断左右眼各片是否有现货、是否需要分别订料而不是简单扣两片库存。3.3 隐形眼镜、护理液与太阳镜注意有效期和批次隐形眼镜的管理比框架镜片还多一个维度——有效期和批次。隐形眼镜有明确的效期库存管理必须引入批号与效期跟踪效期预警提前三个月提醒避免近效期产品还在前台销售。同时隐形眼镜按“盒”为最小销售单位度数、基弧、含水量、更换周期日抛/月抛/季抛/年抛都是必录字段开单时靠这些维度筛可选商品。护理液相对简单属于标准日化商品但要注意它和隐形眼镜的连带销售——很多门店会把“买隐形眼镜加购护理液”做成套餐。太阳镜则更接近镜架逻辑按单品SKU管理但旺季夏季、旅行季的进销存节奏明显报表要能按货类出汇总数据。3.4 库存调整与盘点损耗、赠品、样镜的口径库存上最容易乱的三个场景需求方案里要专门写规矩。一是损耗。加工过程中的报废镜片、试戴损耗、运输破损必须有报损单流程不能直接“库存减少”。报损原因要留选型分类月底可以统计损耗率按损耗率反推加工质量和管理漏洞。二是赠品。很多眼镜店送镜盒、镜布、清洗剂这些也有库存但不能进销售成本。系统要支持赠品行入账价为0但库存数量要扣减否则盘点永远多出来一堆盒子和布。三是样镜。门店展架上摆的样镜到底是库存还是固定资产很多门店样镜走费用报销没进系统卖的时候又找不着数据。建议样镜单独建库管理有独立状态“展示中/可售/报废”系统要随时能查到展示中的样镜是哪批、放了多久定期轮换后转入可售或报废。这块细节做得好不好直接体现在月末盘点报表准不准上。4. 验光档案、会员生命周期与复购营销眼镜店真正的资产不在商品在数据传统进销存只能告诉你“今天卖了多少”而眼镜店真正能产生复购价值的是会员的历史验光档案和消费记录。我见过很多门店营业额长期靠新客支撑老客流失了自己都不知道——因为根本没有数据能告诉你哪个老客户该换眼镜了。这一节讲清楚系统该怎么管这块资产。4.1 验光档案是“人的数据”每个会员要有连续的处方历史前面在订单流程里提过验光单要按版本存档这里把它放大到会员维度说。每个会员建档时要关联起所有历史验光记录不只是最近一次。这个需求的价值在二次配镜时异常显著客人说“我上一次配的好像是两百多度”系统里一查半年前验光单清清楚楚写着右眼-2.25/-0.50×180左眼-2.00/-0.75×175连瞳距都有。不用重新验光就能对比光度变化幅度验光师判断也更准。产品设计上会员详情页要有“验光时间线”视图按时间倒序列出每次验光的完整参数、当时的验光师、当时的购镜订单号。需求文档里建议把这个作为核心页面之一来设计它是极少数能让店员在产品里直接感受到“这个系统帮我省了事”的页面——用了就回不去了。另外一个容易被忽略的需求是“家族关联”。眼镜店经常是爸妈带着孩子配或者一家人都是老客户。系统支持把家人关系如监护人关联儿童档案维护起来好处有两个一是儿童近视防控的复查提醒可以直接提醒到家长二是家庭客户的消费画像和针对性营销更容易做。4.2 会员生命周期提醒与复购节奏框架镜、隐形眼镜各有各的周期眼镜不是一次性消费品复购周期是可预期的系统能不能把节奏用起来是会员营销的核心。框架眼镜的正常更换周期大约是一年半到两年儿童视力变化快的周期更短。系统应该能设定复查提醒比如配镜满12个月自动生成回访任务话术都可以配好“您前次配镜已满一年欢迎回店免费复查视力”。这里不做骚扰式营销做的是健康关怀客户接受度高很多。隐形眼镜的复购节奏比框架镜更刚性。日抛用户一个月就要补货一次月抛用户一个月换一次半年抛用户半年一换。系统要支持按产品的更换周期自动推算下次补货时间到期后推送购买提醒。我见过做得好的门店隐形眼镜复购率能做到百分之六七十靠的就是这套节奏管理。会员储值与积分也要纳入全套体系。储值余额、积分变动、优惠券到期提醒都要在订单流程里顺手处理掉不要让收银员结账时才发现客户有券没用。理想的状态是收银台一录会员号系统自动弹出可用券和积分能抵多少引导收银员与客户确认——需求文档里把这条列为强制功能因为这类功能的实际使用率直接取决于收银员的操作成本越自动越好。4.3 隐私合规与数据安全验光医疗数据是敏感数据这一点容易忽视但相当重要。验光数据严格意义上属于医疗健康数据系统的权限管理要做分级不是所有店员都能看完整验光单。建议至少分老板/店长/验光师/收银员四级收银员只能看必要基础信息验光师能读写验光单店长能看全部会员数据和经营报表老板额外看财务数据。操作日志要留痕谁查看了某条会员档案要有记录。另外连锁门店之间数据共享也有讲究。总部能看到全部门店的会员和销售数据但同品牌异店如果要查看客户完整验光档案建议做“请求授权”机制客户同意后才开放——既保护了客户隐私也避免了门店之间恶性抢客的纠纷。这个细节很多需求方案不写等真出问题就很麻烦。5. 管理报表与关键指标门店经营健康度从哪几个数看起系统收集了这么多数据最终要落到管理动作上。眼镜店不像大卖场店长每天看什么报表、老板每个月底看什么数需求方案里要把报表体系设计出来不然系统就是个“数据黑洞”。我把常用报表按使用场景分成三类每类讲清楚核心指标和计算口径。5.1 日常经营报表日营收、客单价与连带率日常要看的第一张表是销售日报但不要只看“今天卖了多少钱”。真正的经营诊断要看三个衍生指标客单价实收金额/交易订单数。眼镜店客单价波动大接一个大单就拉高一次只看总数看不出趋势要按时间段看分布。连带率含有镜架镜片护理液等两种以上品类的订单数/总订单数。眼镜店利润最高的动作是“一次配镜带出护理液、镜片防雾布、备用镜盒”连带率上去了单店盈利能力明显不一样。报表要支持按门店、按班次、按收银员下钻团伙和个人业绩差距一眼可见。我特别建议加一个“镜架毛利贡献”的分析页镜架品类里高毛利主推款卖得怎么样、滞销款库存积压了多久这些数据定期看能直接指导店内选品和下架而不是凭感觉堆货。5.2 库存与采购报表库龄、缺货与加工履约率眼镜店库存资金占用大老板必须盯三张表库龄表。每一件商品从入库至今放了多久按月份分段0-3个月、3-6个月、6-12个月、超一年。镜架滞销超过一年的基本就是死库存要尽快促销回血。定制镜片没有现货库存但系统要能看到“工厂在途订单列表”上面写明哪天订货、哪家工厂、预计到货日、目前超期多少天。缺货率与畅销品断货表。哪些畅销款在近期有销售但当前库存为零系统自动生成补货建议。眼镜行业很多SKU是单件库存销售一件就缺货补货建议的自动化能把采购工作量大幅减掉这也是系统落地后最直观能感受到的效率提升之一。加工履约率。从收款到加工完成平均用了多少天定制镜片订单平均等待多少天超期订单占比多少。这个指标直接影响客户满意度要周维度跟踪。我把报表命名为“加工时效周报”固定每周一早晨推送到店长端。5.3 会员分析报表忠诚度与流失预警会员报表设计的核心不是“有多少会员”而是“会员在怎么流动”。系统要有会员分层根据最近一次到店时间与消费频次分成活跃会员三个月内有消费、沉睡会员半年未消费、流失会员一年未消费且无任何互动。每类群体数量变化趋势要做趋势图告诉你拉新促销的效果到底好不好。流失预警更是直接给到一线某会员过去平均每半年配一次镜现在快一年没到店了系统自动弹出“高流失风险”提醒店员可以看到该会员的历史消费偏好主动做个微信关怀专享折扣卷都预设好了点击即发。这个功能做到位单店老客回转率能提不少。6. 上线实施最容易踩的五个坑数据准备与落地顺序最后一个部分说说需求方案之外、但决定系统能不能落地的实施问题。我在交付阶段见过太多项目产品设计和开发都挺好上线三个月就蔫了基本都是下面五个坑里中的某一个。6.1 SKU与条码清洗不做库存从第一天就是错的这是最大的坑。系统上线前门店实物库存必须全部盘点一遍每一项货品要对应到系统里的SKU贴好或不匹配条码再导入。尤其是镜架过去用Excel记的账、只记了型号没记颜色尺码的都要重新分清楚。悲观一点的现实建议宁可花两周做数据清洗也不要为了“先上线再说”把脏数据导进去。脏数据一旦进入系统库存报表就会永远不可信后面所有基于库存的管理动作都会失效再想清账基本等于重来。这条必须写进实施计划并且给足时间。6.2 历史会员和验光档案迁移被轻视门店手里往往有厚厚几摞旧病历本和手写会员记录。这些历史数据要不要录入系统、录到什么程度要在实施前定清楚决策如果历史档案数量不大几百条建议全量录入电子化一次录入换永久便利。如果数量巨大几千上万条建议先录最近一年活跃会员的头像信息、最近两次消费记录和验光参数更早的数据留作纸质封存归档业务上等切实需要历史比对再补录某一条。不要让实施团队在录入历史数据上拖太久时间成本和出错率都不低但活跃会员的电子化绝不能不做——否则系统上线那一刻老客户的资产就从线下切换断了。6.3 价格权限过度集中或过度分散眼镜店商品价格灵活日常折扣基本靠人肉谈。系统要支持多级价格体系统一零售价之外可以有会员价、折扣上限、店长特批价、老板底价。但权限设计必须明确——普通店员只能享受到某折扣上限超出要店长审批底价只有老板或授权店长才能操作。这在很多门店是敏感点需求方案里要单独跟老板敲定同时所有改价记录后台留痕月底对账时有据可查。6.4 加工单与销售单脱节前面反复强调订单和加工单要强关联在实施细节里要落实为一条硬校验规则一笔订单只要含有需加工镜片系统必须能够生成加工任务单否则订单不允许收款后直接完成。很多店员为了省事收款后马上打小票让客户走加工环节在系统外纸面流转结果就是谁也不知道这副眼镜做完了没、放哪了。上线初期店长必须强制按系统流程走等团队习惯之后反而是离了系统不知道怎么做店务了。6.5 员工培训与习惯切换的阻力旧习惯的惯性远比想象的大。很多门店店员习惯手写验光单和口头交接系统上线后被要求每一步都录系统第一周效率下降太正常了全员会非常抗拒。我的经验是三件事能明显降低阻力一是操作路径尽量短常用功能两步内完成不要为了功能齐全让收银员多点七八下二是阶段性看板做到位——加工单到没到、今天维护的客户比昨天多几条员工能看见系统的即时价值抵触会小很多三是老板自己要带头用报表数据驱动决策的示范比任何制度都管用。眼镜店管理系统说到底不是一个收银工具而是一条把商品、客户、加工、库存全部串起来的数据管道。管道通了门店的每一副眼镜、每一个客户、每一次加工进度都清清楚楚老板的管理半径才能真正从“亲力亲为”扩大到“看数决策”。需求方案能写到这个颗粒度系统上线才有保障门店运营也才能真正上一个台阶。