大部分电子价签项目的第一轮沟通，都会停在两个数字上：标签多少钱一片，通信距离多少米。这两个数字重要，但它们决定不了项目成败。真正让系统在半年后还能正常运转的，是终端、基站与数据中台三层之间的关系有没有被一起设计。
这篇文章不提供 ROI 数字，也不比较品牌参数。它讲的是一个更实际的问题：当你要评估一套 ESL 系统时，应该按什么顺序问问题，以及每一层各自解决什么、无法解决什么。
一、三层结构：各自的职责边界
一套可运营的电子价签网络，最少由三层组成。它们不是可选模块，而是缺一层就跑不起来的结构。
价签终端负责把接到的画面刷出来，并在两次刷新之间尽可能不耗电。它不判断价格对不对，也不决定什么时候该刷新。
基站以有线或无线网络接入门店，通过私有低功耗协议与终端通信。它决定"指令能不能到"，但不决定"指令内容是什么"。
模板设计、商品与价格数据、批量改价任务、设备管理、多门店权限与执行审计都在这一层。它是唯一知道"这次改价是谁发起、结果如何"的地方。
把三层分清楚有一个直接好处：出问题时不用猜。价格显示错了，是数据源问题；有几片没刷新，是网络或终端问题；改价改不动，先看任务有没有下发成功。如果一套系统没有把这三层的状态分别暴露出来，那么每次异常都会变成一次现场排查，而现场排查的成本远高于系统本身。
二、任务链路：一次改价究竟经过了什么
"改一次价"在业务侧是一个动作，在系统里是五段路程。理解这五段，才能判断一套系统在哪里可能卡住。
价格变化的源头在业务系统里。这里要确认的是接口形式（推送还是拉取）、字段口径（含税还是不含税、会员价怎么表达）与生效时间规则。
平台把价格变化匹配到具体货位与模板，生成刷新任务。这一步决定了改价是"整店一次性刷"还是"按品类分批刷"，直接影响完成时间与网络压力。
任务经门店网络到达基站，再通过私有协议广播给终端。门店网络不稳定、基站数量不足或位置不佳，问题都会在这一段暴露。
终端收到指令后刷新。电子纸整屏刷新需要时间，大批量同时刷新时完成时间会拉长——这不是故障，而是需要在业务侧预留窗口。
终端把刷新结果、电量与异常回传，平台形成"这次任务完成了多少、哪些没完成、为什么"的记录。这一段最容易被省略，也是最不该省略的。
很多系统只做到第 4 段。终端刷完就结束，平台不知道结果。这种系统在演示时看不出问题——演示只有十几片标签，人眼就能验收。但在一家有五千片标签的门店里，"有没有全部刷成功"这件事只能靠系统回答，靠人是数不完的。
三、为什么"只看终端"会做出错的选择
终端是唯一看得见摸得着的部分，所以评估容易集中在这里。但终端层的选择空间其实比想象中小，而且大部分决定是被现场条件反推出来的，不是被参数表推出来的。
以尺寸为例：2.13″ 和 2.90″ 的差别不在参数，而在层板高度、卡槽形式与顾客视距。层高 40mm 的常规货架，2.13″ 装上去合适；生鲜区需要写产地、等级和促销信息，4.20″ 才够放。仓储货位需要远距离可读，直接上 7.50″。这些判断都来自现场测量，不来自型号对比。
换句话说，终端层的问题在勘测阶段就基本收敛了。真正需要在选型阶段花时间讨论的，是平台层能不能承接你的业务规则，以及网络层能不能覆盖你的门店结构。
四、基站是系统组件，不是产品系列
基站经常被当成一个附属配件写在报价单末尾，但它的部署密度直接决定改价能不能按时完成。密度不是按面积平均分配的，需要看三件事：
金属货架密集排列会削弱信号，通道走向决定基站朝哪边装。
同一基站下挂载的终端越多，整批刷新耗时越长，需要拆分覆盖区。
有线接入更稳定；只能走无线时，要确认与收银、监控是否争抢带宽。
正确的做法是先勘测再报价。跳过勘测直接按面积估算基站数量，最常见的结果是首店验收时发现某个死角刷不到，然后追加基站、重新布线，工期和成本都超出预期。
勘测时有几个位置几乎每次都会出问题，值得提前带着清单去看。第一是冷柜和冷库：金属柜体加玻璃门会明显衰减信号，柜内标签往往需要就近增设基站。第二是背靠背的货架中缝，两排金属层板之间的终端接收条件最差。第三是仓储区与后场——它们常常在首轮勘测中被跳过，因为讨论集中在卖场，但后场货位同样要贴标签。第四是电梯井、配电间与消防通道附近的金属结构密集区。把这四类位置在平面图上先标出来，基站数量的估算精度会高很多。
另外要提前问清楚的是供电与布线条件。基站需要取电，门店天花板上有没有可用插座、走线需不需要打孔、装修方是否允许在吊顶开孔——这些施工层面的约束经常比技术参数更能决定基站最终装在哪里。如果门店属于商场统一管理，还要确认装修申报流程和可施工时间窗口，这部分时间要计入项目工期。
五、平台层：真正决定长期成本的地方
硬件是一次性支出，平台是长期支出。判断平台层是否合格，可以从下面几个问题入手——这些问题不需要技术背景也能问出来：
改价失败时，系统告诉我的是"失败"还是"哪一片、什么原因"？前者只能靠人排查，后者才能形成运维流程。
总部改价和门店改价能不能分权限？多门店场景下，谁能改哪些品类的价格，是一个合规问题，不只是功能问题。
模板改版需要找厂商还是自己能做？促销版式一年要换很多次，每次都提需求排期，运营节奏会被拖住。
有没有 RESTful API，能不能不靠导表对接 ERP / POS？靠人工导表的系统，最终一定会出现"两套价格"。
执行记录能保留多久、能不能导出？价格争议、审计与复盘都需要这份记录，它的价值在事后才显现。
终端决定看起来对不对，基站决定送不送得到，平台决定这件事能不能长期做下去。三层里任何一层没被认真评估，问题都会在第二家门店开始暴露。
六、一份可以直接用的评估顺序
如果要把上面的内容压缩成一个可执行的流程，建议按这个顺序推进：先确认业务规则，再看现场条件，最后才谈型号和数量。
第 5 步经常被跳过，但它和前四步一样重要。一套技术上完全合格的系统，如果没有人负责看告警、没有人负责补漏刷，半年后会退化成"墙上挂着的一批不准的标签"。责任落到具体岗位，系统才算真正交付完成。
七、试点阶段该记录哪些数字
试点的目的不是"证明系统能用"，而是拿到几个可以用于后续门店预算和排期的真实数字。演示环境里这些数字都很漂亮，只有在真实门店、真实终端数量下测出来的才有参考价值。建议至少记录下面五项：
这五项数字拿到手，第二家门店的方案就不再是估算，而是有依据的推算。反过来，如果试点结束时手里只有一句"跑通了"，那么后面每一家门店都要重新踩一遍同样的坑。试点的价值在于把不确定性换成数字，不在于证明可行。
最后回到开头那两个数字。标签单价和通信距离仍然要问，但它们应该出现在第 3 步之后，而不是第一次会议的第一句话。把顺序调过来，项目的返工率会明显下降。