一、项目背景

我们服务的客户是一家自助洗衣连锁，几十家门店，设备是我行我素的。哪台空闲、哪台在洗、哪台坏了，全靠店员偶尔去现场看一眼，或者靠顾客在群里抱怨才知道。周末下午高峰，好几个人围着几台机子等，体验非常差。会员储值在自家小程序，优惠券又是另一套，核销的时候两边对不上，财务月底做账要对到头秃。

我们进场时他们的诉求很直接：让顾客能提前看到哪台机器空着、能不能先锁个位，到了扫码就洗，洗完推个消息，顺便把储值和券打通。底层我们还是用 XpShop 那套门店加会员加订单的能力，再把设备接入这一层自己补上。

二、落地场景

实际落地我们做了四件事。设备在线状态这一块，每台洗衣机、烘干机装了物联网模块，心跳上报到平台，前台就能显示空闲、运行中、故障三种状态，顾客打开小程序按门店筛，空位一目了然。预约锁位，顾客看到空闲机器可以直接锁十分钟，到店扫码启动，超时没来自动释放给后面的人。扫码启动到完成通知，机器洗完主动推消息，不用蹲在机器旁边等。储值会员与优惠券核销，储值余额、券、订单全部走同一套账户，核销即扣，账目天然平。

试点选了六家门店，设备约两百台。真正麻烦的其实是老机器的改造，一部分设备通信协议是私有的，厂商不给文档，我们只能抓包反推报文，调通第一台花了三天，后面同型号就快了。

三、关键技术挑战与解决思路

第一个坑是设备状态延迟。最早心跳是三十秒一次，顾客看到空闲跑过去发现别人刚占了，体验崩了。我们把状态改成事件驱动，机器状态一变就主动上报，前端近乎实时刷新，锁位机制再兜一层，基本解决了跑了白跑的问题。

第二个是锁位冲突。两个顾客同时锁同一台，或者锁了不来，都会浪费资源。我们给锁位加了分布式锁和超时自动释放，锁的时候预占库存，释放时回滚，超时不来直接放给排队的下一位，高峰排队明显少了。

第三个是设备连接稳定性。物联网模块在地下室信号差，心跳会丢。我们没有要求百分百在线，而是做了状态推测：最后一次上报是运行中就继续显示运行中，连续丢失超过阈值才标未知，避免误报空闲骗顾客白跑。

案例片段（已脱敏）： 设备状态上报报文（JSON 示意）：{  "device_id": "WM-0601-07",  "store_id": "S0601",  "status": "running",  "remain_sec": 540,  "ts": 1774000000 }锁位日志一例：2026-03-15 14:22 顾客 U 锁定 WM-0601-07 成功，14:31 扫码启动，超时释放任务在 14:32 巡检时发现已启动便跳过；同日该门店高峰排队平均等待从改造前约 11 分钟降至约 4 分钟。

四、效果数据

跑了一个月我们看了关键指标。设备在线率稳定在约 97%，剩下的三成波动主要是地下室个别点位信号，不影响整体使用。锁位成功率约 99%，偶尔失败是弱网下的状态竞争，重试就过。核销成功率基本百分之百，因为储值和订单同一账户，不再出现两边对不上的情况。高峰等待时长，六家试点门店周末下午均值从约 11 分钟降到约 4 分钟，顾客投诉量明显下降。

有一件事超出预期，设备状态可视化之后，店员巡检工作量反而降了，原来每天来回走几趟看机器，现在打开后台就知道哪台该去处理，人力省下来做清洁和引导。

五、可复用经验总结

设备接入这类项目，状态千万别只靠轮询，事件驱动加锁位兜底才是真体验，我们三十秒轮询那版上线当天就被顾客骂了。老设备没文档别怕，抓包反推比等厂商靠谱，同型号调通一台后面就是复制。状态不可靠时宁可标未知也别乱报空闲，骗顾客跑一趟比显示未知更伤信任。账户体系一开始就要统一，储值券订单分两套后面对账能让人崩溃，这是我们踩过最贵的坑。

现在他们在把洗鞋、烘干这种增值服务也往这套预约体系里塞，逻辑是通的，只是设备类型又要多接几种。

附：从设备数据到运营决策

试点跑顺以后，运营方想看单台设备产出，用来考核门店。我们在后台加了设备维度的订单和时长统计，哪台机器总躺着不赚钱，一眼能看出来，门店排班也跟着调。储值这一块也踩过坑，原来优惠券和储值混在一个账户，财务分不清哪些是预收款、哪些是赠送，月底核算一团乱。我们后来把两者拆开，赠送部分单独挂营销账，预收款走会员账，账目终于清楚。自助设备这个项目，真正难的不是把机器连上，而是把设备数据变成运营真能用得上的东西，我们前两周几乎全耗在理解他们的考核口径上。

顺带说一句设备侧的运维，物联网模块批量部署时，我们做了个远程配置下发，固件参数改了不用派人去店里刷，后台推一下就好，这点在大批量扩店时省了不少人力。还有故障自检，机器报错码我们接进了工单，门店报修时系统已经知道是哪台、什么毛病，派单更准。自助设备这行，门店多、分布散，远程能力不是加分项，是能不能规模化的前提。我们把设备健康也接进大屏，哪台久未上报一眼可见。