我们会看看 贵方的场地和设备 并告诉您 哪些可以接入
已经装的是什么柜子和锁、它们对外输出什么、需要哪些开柜场景，以及从哪里开始比较合理。
寄存间与储物柜软件
面向行李寄存处、寄存点和带电子锁柜体的软件
一排带格口的柜子，无非是金属和锁。软件把它变成一项服务：人凭码或刷卡获得权限，格口自动打开，系统知道哪个格口被谁占用、占到什么时候，每一次开启都留在日志里。以下讲解它是怎么运作的——从屏幕上的一次点击，到锁的一声脆响，再到历史里的一条记录。
面向行李寄存和储物柜的程序
是什么
储物柜软件 — 一套系统，决定把哪个格口分配给谁、在恰当的时刻打开它的电子锁，并保存每一次开启的记录：谁、什么时候、依据什么。
它和普通柜子的区别，一个例子就能说清。用钥匙或挂锁时，为格口负责的是人：发了钥匙、记住号码、再收回来。钥匙丢了就得撬门，出了争议靠当班的记忆来判断，而现在还有几个格口空着，只有站在旁边的人知道。
自助格口没有钥匙。开门的权利是数据库里的一条记录：某个码对某个格口有效，直到某个时刻。码可以签发、作废、延期，也可以转给别人，全程不用走近柜子。而所有场地、所有格口的占用情况，在一个清单里就能看到。
举个例子。 购物中心的顾客把袋子放进格口：在屏幕上扫一下二维码，门打开，他关上门就走。两小时后他用同一个码打开同一个格口。系统里留下两条开启记录、寄存开始时间，以及一条「该格口已释放、可供下一次使用」的标记。
行李寄存自动化 的起点，是当三个问题的答案再也装不进值班人员的脑子时：此刻有多少格口被占用、今天 14:20 究竟是谁打开了某个格口、以及已经放了第二天的东西该怎么处理。
- 1用户
- 2身份识别
- 3权限校验
- 4柜体控制器
- 5电子锁
- 6门磁
- 7事件日志记录
- 8管理后台
链路是双向的：指令从左往右走，确认再回来。开启是否算数，不看指令是否发出，而看门磁是否应答。少了这一步，系统讲述的就是它相信的格口状态，而不是场地上真实发生的事。
系统对每个格口都知道什么
- 它在哪里 — 场地、区域、柜体、格口编号及其尺寸类型
- 是否被占用 — 空闲、已预约、已占用、待释放、已封锁
- 被谁占用 — 寄存会话，含开始时间、时长和开柜方式
- 用什么打开 — 此刻对它有效的是哪个码、哪张卡或哪个账号
- 它经历过什么 — 所有开启和关闭，含精确时间和依据
- 是否正常 — 锁是否应答、与控制器是否连通、门是否关得上
这与快递柜有何不同
设备看起来差不多——同样的柜子、同样的锁、同样的码。区别在用途。快递柜是把别人的包裹交给收件人：配送员放进去，收件人取走，格口随即释放。行李寄存则是按时间租给某个人：他自己放自己的东西、自己取走，格口按时长计费。
由此对软件的要求也不同：快递柜最要紧的是与网店和配送服务的连接，行李寄存最要紧的是会话、时限、续期和把格口收回流转。订单交付的详细解析见 自助服务系统.
运作方式：从一个码 到一扇打开的门
一次请求所走完的全程——从柜子前的人到日志里的记录。本页后面会对其中每一环做更详细的解析。
1. 柜体与格口
物理部分：柜体的各节、不同尺寸的格口、门。每个格口在系统里都是一个独立对象，有自己的编号、尺寸、区域和状态。柜体可以再加一节——在软件里那只是增加格口，而不是改造。
2. 电子锁
不是用钥匙打开，而是由控制器发出电脉冲打开的锁。旁边通常还有一个门磁——它汇报门是否真的开了、又是否关上了。没有门磁的锁也能用，但那样系统只知道指令，而不知道结果。
3. 柜体控制器
柜体内部的一个小设备，所有锁和传感器都接在它上面。它接收「打开 14 号格口」的指令，向对应的锁发出脉冲，并回传结果。一个控制器能带几十个格口，因此柜体接入系统只需一条链路，而不是四十根线。
4. 用户接入点
人用来与系统打交道的东西：柜体上的屏幕、大厅里的独立终端、读卡器，或者他自己的手机。接入点可以同时有好几种——流程完全一样，只是输入方式不同。
5. 服务端
做决定的地方。服务器保存格口、会话、码、权限和日志，校验请求并向控制器下达指令。它同时还计算寄存时长、生成通知和报表。部署在数据中心还是客户自己的设备上，由项目决定。
6. 管理后台
场地员工的工作台：柜体地图、格口占用、进行中的会话、事件、手动开柜、封锁格口、角色与报表。在浏览器里打开，无需安装任何东西。
- 输入人把二维码对准扫描口，或在柜体屏幕上输入 PIN
- 权限校验服务器按这个码查找有效会话：它存在吗、过期没有、属于哪个格口、尝试次数是否超限
- 指令向柜体控制器发出打开指定格口的指令；码本身不会传给控制器
- 向锁发脉冲控制器给对应格口的锁通电，并等待门磁应答
- 确认门磁报告门已打开。到这一刻开启才算数，而不是点击的那一刻
- 记录日志收到格口、时间、开柜方式、会话和结果。被拒绝时同样生成记录——「码已过期」也是一个事件
- 关闭门磁报告门已关上。如果在规定时间内没有发生，系统会另外产生一个事件
顺序正是这样才有意义。权限校验在服务器上完成，而不是在柜子里：控制器既不保存码，也不决定放谁进来——它只执行指令。因此在后台一秒钟就能吊销权限，不必走到设备跟前。
解决方案的 软件生态
系统由模块拼装而成。并不是每个场地都需要全部模块：办公室的储物柜不需要支付模块，车站的行李寄存也不需要企业角色。具体组合由需求决定，但模块之间是事先就能对接好的，而不是事后从旁边硬加。
用户界面
人所看到的：柜体屏幕、通过链接打开的浏览器页面，或者手机应用。三四步——选尺寸、拿格口、开门、关门。出错时用人话解释：「寄存时间已到」，而不是「错误 403」。
管理后台
员工的工作台：柜体占用情况、进行中的会话、事件、填写原因后手动开柜、封锁格口、资费和规则台账、报表。全部在浏览器里，并按角色区分。
格口管理
格口台账：场地、柜体、编号、尺寸类型、区域、当前状态和历史。格口可以停用检修、为特定用途预留，也可以编成一组共用同一套开柜规则。
电子锁
与锁打交道的那一层：开锁指令、等待应答、处理失败、重试。锁的类型也在这里体现——带不带门磁、是否回传锁舌位置，还是只发一个脉冲。
设备控制器
与柜体控制器的交互：指令队列、链路监控、端口状态、固件版本。不同型号通过各自的交互模块接入，但在界面里长得一模一样。
身份识别
校验站在柜子前的是谁：二维码、PIN 码、刷卡、应用内账号。这些方式可以组合，也可以按场地启用——这个柜子用码，那个柜子用员工卡。
预约
提前占下一个格口：按时段、按日期、按周期性区间。预约会把格口留到人来为止，如果没来则自动释放——否则半个柜子都白白锁着。
支付模块
用在寄存收费的场景：资费、金额计算、支付、超时补款、退款。具体支持哪些支付方式，取决于接入的服务商和设备——这是一项对接，而不是内置功能。
通知
发给用户和员工的消息：开柜码、时限将至的提醒、门未关好、格口已释放、柜体故障。下发渠道在落地时确定。
操作与事件日志
不可篡改的历史：开启与关闭、拒绝开柜、维护开柜、资费和权限变更、员工操作。记录不做编辑——更正以新增一条记录的方式写入。
设备监控
柜体和锁的状态：与控制器是否连通、锁是否应答、门是否卡住、有没有电。有故障的格口会自动退出分配，而不是被访客发现。
员工角色与权限
值班人员、场地管理员、维修服务、负责人。手动开柜、延长会话、修改资费和查看个人数据，都是各自独立的权限，而不是打包成一个「管理员」。
API 与系统对接
系统对外的接口：分配格口、取得开柜码、查询状态、结束会话、拉取日志。财务系统、CRM、场地的门禁系统和客户自有服务，都通过它接入。
数据分析与报表
按小时和按天的使用率、格口周转、各尺寸类型的分布、超时占比、设备故障，以及收费寄存场景下的营收。报表可导出为文件，也可按计划自动生成。
服务端
把上述一切串起来的内核：会话核算、指令队列、时限与通知的调度、日志存储、带恢复验证的备份。
用户如何
取得格口的开启权
开柜的场景有两种，而且互不替代。第一种是人走到空柜子前，当场领一个格口。第二种是格口事先就归属于他：已预约、按月租用，或者作为工位储物柜发给他。
当场领用。 访客在屏幕上选尺寸，系统挑一个该尺寸的空闲格口并打开它。与此同时创建一个寄存会话，并签发一个码——显示在屏幕上、打在小票上，或者用短信发过去。这个码就是钥匙：它只对这个格口有效，也只在时限之内有效。
归属格口。 这时钥匙就是人本身：员工卡、应用内账号、固定 PIN。识别通过即开柜，每次来都不会重新创建会话，时限由合同或排班决定，而不是按寄存小时数算。
两次开启之间会发生什么：
- 格口保持归属状态 — 在会话关闭之前，它不会分配给别人
- 码可以重复使用 — 只要场地规则允许：放进去、离开、回来、再放一点
- 计时在走 — 系统统计寄存时长，并提前提醒时限将至
- 开柜权可以转交 — 在流程允许的情况下，为同一个格口再签发一个码给别人
- 开柜权可以吊销 — 码立刻失效，不必走到柜子跟前
- 14:05 — 选择访客在屏幕上选了中号；该尺寸的空闲格口有 12 个
- 14:05 — 分配系统把 № 27 号格口分配给他，创建会话并打开门。码显示在屏幕上，并用短信再发一份
- 14:06 — 关门门磁确认门已关上。从这一分钟起开始计算已付费时长
- 16:40 — 再次开启同一个码，同一个格口。事件已记录，会话继续，格口仍归属于他
- 18:20 — 提醒距已付费时限还有 40 分钟。发出提醒，给两个选项：取走物品或续期
- 18:52 — 结束访客取走物品并在屏幕上确认结束。会话关闭，补款已计算并支付
- 18:53 — 回到流转格口标记为空闲，码已作废，下一次分配可以立即进行
系统界面截图，时间为演示用。请注意最后一步：格口回到流转，是在会话关闭的那一刻，而不是「等员工注意到的时候」。否则到了傍晚，半个柜子在账上是占用的，实际却是空的。
异常情况
这类情况不多，而且全都是事先就考虑好的——否则每一种都会变成给管理员打的一个电话。
- 码丢了 — 就同一个会话重新签发：通过发到分配时留下的手机号，或者由持有该权限的员工来办
- 门没打开 — 指令发出去了，门磁没动静。系统不会把这个事件按成功结案：它会重试，第二次仍失败就把该格口移出流转并生成一条维修任务
- 门没关上 — 一个单独事件，注明格口和时间。只要门开着，这个格口既不算被正确占用，也不算空闲
- 时限已过，东西还在格口里 — 格口转入超时状态：按场地规则，用户的开柜权或保留或封锁，同时员工会收到一份超时格口清单
- 由员工开柜 — 任何时候都可以，但这是一项单独的权限，也是日志里一条单独的记录，且必须填写原因
- 与柜体失联 — 对它的请求会停止，而不是盲目堆积；控制器离线工作的方案在下面讨论
身份识别 的方式
身份识别回答的是一个问题：这个人此刻是否有权打开这个格口。方式要按场地和设备来选——在车站好用的，未必适合办公室的储物柜。某种方式能不能用，取决于柜体上装了什么，因此具体组合在调研时确定。
二维码
码显示在手机屏幕上或打印在小票上，柜体用扫描口读取。适合一次性访客：不用记也不用输。它需要柜体上有扫描口，也需要用户那边有一块能用的屏幕。
PIN 码
在键盘或屏幕上输入的几位数字。这是最不挑条件的方式：不需要手机、不需要用户那边有网络，也不需要额外设备。它需要限制尝试次数和有效期。
卡或钥匙扣
贴到读卡器上的非接触介质。在人们本来就有门禁卡的地方，这是主要方式：办公室、工厂、健身房。它常常可以直接沿用场地里已经发出去的卡——这要按卡的类型确认。
移动应用
格口由应用里的一个按钮打开，而不是在柜体上输码。适合常客和包月用户；同时也便于在这里展示历史、时限和支付。它要求用户在开柜那一刻有网络。
单据条码
钥匙就是一份已经存在的单据：订单号、车票、取件票、送货单。格口与它绑定，人不必另外拿一个码。能否这样做，取决于单据从哪里来、以及能否通过对接取到它。
生物识别
用指纹或人脸代替码和卡。技术上它就是再接一个读取设备，但个人数据的保存和保护需要单独定方案，因此它被当作某个具体项目下可选的方案，而不是默认方式。
| 场地与场景 | 主要方式 | 原因 |
|---|---|---|
| 一次性访客、人流量大、现场付费 | 二维码或 PIN | 不必事先发放，也不必事后回收 |
| 持门禁卡的员工 | 刷卡 | 介质本来就在手上，不需要另发一个码 |
| 包月与常客 | 应用 | 时限、支付和使用历史都在同一个地方 |
| 在人与人之间转交物品 | 两个不同的码 | 放东西的人和取东西的人，各有各的码 |
| 访客那边网络不稳定的场地 | 只用 PIN | 不依赖人这边的手机和网络 |
这些方式并不互斥：同一个柜子可以同时开着给员工的刷卡和给访客的码。要紧的是另一件事——哪一种是主要方式，因为有效期、尝试次数和补发规则都是围绕它来配置的。
电子锁
与设备控制器
这是系统里最「物理」的一部分，软件说的是不是实话，就取决于它。 电子锁 靠一个短电脉冲打开：电压一到，锁舌缩回，门就松开了。锁本身对人和码一无所知。
控制器 — 柜体内部的一个设备，锁和传感器都接在它上面。它从服务器收到「打开 27 号格口」的指令，向对应的输出口发出脉冲，并回传结果。一个控制器能带几十个格口，因此柜体接入系统只需一条通信链路。
门磁 — 它把推测和事实区分开。没有它，系统只知道指令发出去了。有了它，系统才知道门确实开了、以及过了多久被关上。柜体上有没有传感器，是针对具体型号的问题，要在开工之前弄清楚。
接设备时要考虑什么：
- 锁的类型 — 脉冲式还是保持式，是否回传锁舌位置
- 是否有门磁 — 它决定系统能否区分「已打开」和「尝试打开」
- 控制器接口 — 指令具体怎么下达给它，它又以什么形式回传状态
- 每个控制器带多少格口 — 已经用掉多少输出口，还剩多少可供柜体扩容
- 供电 — 断电时锁会怎样，是否配备了备用电源
- 机械开启 — 有没有在断电情况下打开格口的应急方式，以及由谁掌管
我们不预先宣称支持某些品牌的锁和控制器。可接入的设备范围在调研时按厂商文档以及设备对外开放的接口来确定；没有现成接口的，在开工前单独解决，而不是给一句「兼容」的承诺。
断网时会发生什么
柜体与服务器之间的链路会断——这是正常情况，而不是一年一次的事故。断的那一刻怎么办，是事先设计好的，方案有两种。
不做离线模式 柜体就直接停止服务：屏幕提示没有连接，不再分配新格口。里面的东西是安全的，但在链路恢复之前，没有员工就取不出来。
做离线模式 控制器保存一批有限的有效码，继续凭它们开柜，并把事件堆进队列。链路恢复后，整个队列一次性上传服务器。这种模式是一项单独的设计决策：它需要控制器上有存储空间，也会让吊销一个码不再是瞬时生效。
系统能区分的状态
| 设备回传了什么 | 如何解读 |
|---|---|
| 指令已接受，门磁确认已打开 | 已打开 |
| 指令已接受，门磁没有动静 | 需要核查 |
| 门打开的时间超过了允许值 | 事件 |
| 控制器没有应答指令 | 事件 |
| 柜体没有上线 | 事件 |
| 门在没有指令的情况下被打开 | 事件 |
「门磁没有动静」这一行最重要。系统既不把这样的开启算作发生了，也不算作没发生：它把该格口标记为需要核查，在弄清楚之前不会分配给下一个人。
占用情况 与格口状态
一个格口任何时候都恰好处于一种状态，状态之间的流转由规则决定，而不是由现场员工拍板。「此刻有多少格口空着」这个问题的答案，正是由这些状态汇总出来的——而且必须不用走到柜子跟前就是对的。
空闲
格口正常、是空的，可以分配给下一个人。只有这类格口才参与分配时的挑选和预约。
已预约
已提前占下，不会给别人，但里面还没有东西。预约有时限：人没来，格口就自行回到流转。
已占用
寄存会话正在进行：有开柜权的人、开始时间和时限。这是主要的工作状态，格口大部分时间都处于其中。
待取件
东西是一个人为另一个人放的。格口是占用的，但钥匙在取件人手里——这是转交和订单交付的场景。
已超时
寄存时限已过，东西还在里面。该格口不再分配，会进入一份单独的清单，并按场地规则处理——补款、封锁，或者取出物品。
需要核查
开启没有被门磁确认、门一直开着，或者记录到没有指令的开启。在弄清楚之前，该格口被移出分配。
故障
锁不应答，或者控制器报了错。格口自动移出，并为它生成一条给维修服务的任务。
人工封锁
员工把格口移出了流转：保洁、整节维修、内部需要。封锁有操作者、原因和时间——否则谁把十个格口关了、为什么关，都无从得知。
240个格口在本场地
171当前占用
9已超时 需要排查
4已移出流转
系统界面截图，数字为演示用。按尺寸类型的拆分比总数更重要：一个占用率 71% 的场地，可能一个空闲的小号格口都没有——而大多数访客要的正是小号。同一张表也能看出，扩容柜体时值得增加哪些尺寸。
预约、转交
与物品存放
预约 用在人来的时间可预期的场合：他知道自己周四会来，希望确定那时有格口。系统把格口按时间段留出来，不再提供给别人。
预约一定要有等候时限。没有它，场地很快就会陷入这样一种状态：没有空闲格口，柜子却空了一半，因为人们预约了却不来。到约定时间没来，预约即释放，格口回到流转，人则收到一条通知。
预约的类型：
- 一次性 — 指定某天某个时间段的格口
- 周期性 — 每周二和周四，用于包月和固定排班
- 长期 — 格口按月或按合同期限归属，如同租下的一间储物间
- 内部占用 — 由场地为特定用途预留、不对外分配的格口
转交与领取 — 第二种场景，格口在其中成为两个人之间的交接点。一个人放，另一个人取，双方不必见面。
技术上这仍是同一个会话，只是有两种不同的开柜权：投放码和领取码。前者在关门后作废，后者从那一刻起开始生效。这样系统知道的就不只是「格口已占用」，而是「东西已放好，取件人还没来过」。
- 分配由员工或系统挑选一个尺寸合适的空闲格口，并创建一个转交会话
- 投放码发给放东西的人。有效时间有限，且只能开一次
- 投放格口打开，东西放进去，门关上。投放码作废，会话转入「待取件」状态
- 领取码发给取件人，同时附上场地地址、格口编号，以及东西会等到什么时候
- 领取取件人用自己的码打开格口，取走东西并关上门
- 关闭会话格口释放。如果取件人没有按时来，会话转入超时，并进入待排查清单
把两个码分开不是走形式。只要还是一个共用码，就无法回答究竟是谁打开了格口：是放东西的人，还是取东西的人。有了两个码，日志里的每一次开启都有操作者和角色。
系统如何挑选格口
挑选不是「按编号取第一个空的」。规则按场地配置，通常会同时考虑几个条件：
- 尺寸类型 — 取能装下的最小尺寸，免得在大格口紧张时还拿它去装一个小包
- 区域与高度 — 下面几排更好取用，可以留给确实需要的人
- 磨损均衡 — 格口轮流分配，而不是同样那几个一天用十次
- 是否正常 — 有未结事件的格口不参与挑选
超时了怎么办
场地规则决定：时限到了、东西还在里面时会发生什么。方案有几种，而且要在上线前选定，而不是等第一例出现时再说。
- 补款 — 开柜权保留，但要先把超时的时间补交了才能打开格口
- 封锁 — 凭码开柜被关闭，只能由员工打开
- 取出 — 超过规定期限后，把物品移到指定地点，格口回到流转；取出这件事本身会作为一条带操作者的独立记录留存
无论哪种方案，人都会在时限结束之前收到提醒，而不是被罚款之后才知道。
寄存费用
在寄存收费的场景下
支付模块不是人人都需要：员工储物柜和俱乐部的更衣格口完全不涉及钱。但只要格口是租出去的，钱就成了会话的一部分，计费规则也必须像开柜规则一样定得严格。
费用怎么算。 资费与格口的尺寸类型和时间挂钩。最常见的几种方案是：按会话收固定价；按时间段（小时、天）计价并向上取整；阶梯资费，第一小时比后续更贵；以及长期的包月方案。
什么时候收款。 这同样是项目决策。按选定时段预付、续期时补款，对场地来说是最简单、最可预期的方案。会话结束后再按实际收费，则需要有人一定会付款的保障——例如先在卡上做一笔预授权冻结。
系统的支付部分包含什么：
- 资费 — 按尺寸类型、场地、时段和星期几设定
- 金额计算 — 按会话的实际时长，并带取整规则
- 续期 — 在不结束会话的情况下为延长的时段补款
- 超时 — 对超出已付费时间的部分单独计价
- 退款 — 分配格口失败时，款项退回，而不是留在场地方
- 支付与会话的关联 — 双向的：从会话能看到支付，从支付能看到格口和时间
- 对账 — 每天把操作与支付服务的流水做比对
边界我们直说。 具体的支付方式——刷卡、非接触支付、二维码、应用内支付、通过纸币器投现金——取决于接入的支付服务和柜体上的设备。这是一项范围在调研时确定的对接，而不是任何项目里都现成可用的内置功能。开具税务凭证的要求由所在国家的法规和设备型号决定。
一次会话的费用计算
- 第一小时，中号尺寸120
- 后续小时，4 × 60240
- 不足一小时按一小时向上取整已含
- 分配格口时已付，2 小时−180
- 结束会话时的补款180
取整规则要在付款之前就告诉本人，而不是让他在最终金额里自己发现。这是整份计算里唯一一行会在场地引发争议的内容。
当支付与开柜对不上时
危险的场景只有一个：钱扣了，格口没开。系统不会把这样的操作视为已完成——会话不开始，格口仍然空闲，而这笔支付连同原因进入退款队列。
反过来——格口开了，支付却没确认——处理同样严格：会话照常创建，但标记为未付款并进入待排查清单。系统不能对差异睁一只眼闭一只眼，否则到月底什么都对不上了。
通知 与事件日志
事件是指系统必须记住的任何一次变化：开启、拒绝、时限到期、员工操作。其中一部分事件会以消息形式发给人，而全部事件无一例外都会进入日志。下发渠道——应用、手机短信、邮件、即时通讯——通过对接接入，并在落地时选定。
发给用户：开柜
开柜码、格口编号、场地地址和寄存时限。在分配时发送；若码丢失，可按请求再发一次。
发给用户：时限
在已付费时间用完之前发出提醒，并提供续期入口；会话转入超时时另发一条消息。
发给用户：转交
通知取件人东西已放好、格口在等他；并向寄件人回传一条确认，说明东西已被取走。
发给员工：设备
格口没打开、门没关上、柜体离线、控制器报错。事件是有收件人的：它带着场地和责任人。
发给员工：超时
寄存时限已过的格口清单，含会话开始时间；如果留了联系方式，也附上联系方式。
发给员工：排查
没有指令的开启、连续多次输码失败、员工手动开柜、支付与分配对不上。
| 时间 | 事件 | 依据 | 结果 |
|---|---|---|---|
| 14:05 | 分配 № 27 号格口 | 会话 8842，中号尺寸 | 成功 |
| 14:06 | 门已关闭 | 门磁 | 成功 |
| 16:40 | 凭码开启 | 会话 8842，二维码 | 成功 |
| 16:47 | 门打开的时间超过允许值 | 门磁，6 分钟 | 事件 |
| 18:20 | 时限到期通知 | 「提前 40 分钟」规则 | 已送达 |
| 18:49 | 拒绝开柜 | 码输入错误，第 2 次 / 共 5 次 | 拒绝 |
| 18:52 | 会话结束 | 屏幕上确认，补款 180 | 成功 |
| 19:14 | 维护开柜 | 值班员 Asanov，原因「格口保洁」 | 手动 |
系统界面截图，数据为演示用。请注意 18:49 那一行：输码失败同样是一个事件。只记录成功的日志，没法用来复盘争议，因为争议讨论的恰恰是那些拒绝和手动开柜。
管理员
员工的角色与权限
管理后台是一个工作台，而不是一屏「设置」。大部分时间里，员工只看两件事：此刻格口那边在发生什么，以及有什么需要他插手。
第一屏上有什么： 带各尺寸占用情况的柜体地图、按紧急程度排列的未结事件清单、超时的格口、已移出流转的格口。而不是把格口一个接一个全列出来——否则在有两百个格口的场地，第一屏就毫无用处。
管理员可以做什么：
- 手动开柜 — 必须填写原因，该原因连同员工姓名一并进入日志
- 延长或结束会话 — 用在本人无法自己操作的时候
- 重新签发开柜码 — 针对已有会话，不新建会话
- 封锁格口 — 因保洁、维修或内部任务把它移出流转
- 处理事件 — 记录核查了什么、发现了什么、最后怎么了结
- 修改资费与规则 — 如果该角色有这项权限；变更连同操作者和时间一并记录
权限发给角色，而不是发给某个人。 在只有三名员工的场地看不出区别，但一旦变成二十名，个性化配置就无法核查了：没有人能说清此刻谁有权打开别人的格口。角色就是这个问题的一行答案。
- 查看本场地的占用情况和事件值班人员基础权限：没有它，员工无法上班
- 针对某个会话重新签发开柜码值班人员最常见的支持操作；会记入该会话的日志
- 手动开柜值班人员，需填原因原因必填且从列表中选择；没有原因，系统不予执行
- 提前结束他人的会话场地管理员值班人员无此权限：这是终止一项已付费的服务，而不是帮访客一把
- 从超时格口取出物品场地管理员一项单独的权限，且必须注明物品被移到了哪里
- 修改资费与寄存规则负责人变更自指定日期起生效，并连同原值一并保存
- 给其他员工发放权限负责人这是一项不能发给自己的权限：角色的指派永远来自上级
- 查看用户的个人数据单独的权限默认不包含在任何角色里，需按具体理由单独发放
最后两行不是过度谨慎。发放权限的权限和查看个人数据的权限会绕过其他一切限制，因此它们始终被单列出来，而不打包进「管理员」里。
在同一个后台里管理多个场地
当柜子都在一个场地时，一份清单就够了。当场地有十个时，单点从来不会遇到的问题就全都冒出来了。
- 分组 — 按场地、区域、柜体类型和责任人分组，每组有自己的汇总
- 各有各的接收人 — 事件发给它发生的那个场地的值班人员，而不是进一个公共清单
- 升级 — 在规定时间内没人接手的事件，转给链条上的下一个人
- 场地之间对比 — 哪里使用率更高、哪里超时更频繁、哪里设备故障更多
- 共用台账 — 资费和规则设定一次，作用于一组场地
员工能看到关于某个人的什么信息
恰好是工作所需的那些：会话号、格口、时间、开柜方式、支付状态。联系方式（如果当初采集了）需要单独的权限才能看到，并且会记入日志——查看这件事本身也是一个事件。
关于用户采集哪些数据，是一项项目决策，由场地要求和法规决定，而不是由系统能力决定。有一种方案是：除了格口编号和时间之外，关于本人什么都不保存——这是可行的，而且往往已经够用。
设备状态
监控
柜子是无人看管的，这正是它的根本特性。也就是说，故障必须由系统自己发现——否则来报告的会是那位打不开自己格口、东西还在里面的访客。
持续监控什么：
- 与柜体的连接 — 控制器是按时上线，还是沉默超过了允许的间隔
- 锁的应答 — 格口是否按指令打开，门磁是否确认了结果
- 门的位置 — 已关、已开、开着超过允许时长、无指令自行打开
- 供电 — 柜体是否有电，以及在哪一刻断的
- 外设 — 扫描口、屏幕、读卡器、支付部件是否工作正常
- 控制器报错 — 在型号支持的情况下，它自己上报的错误码
沉默同样是一个事件。 不上线的柜体并不意味着「一切平安」：它意味着关于两百个格口及其中物品的状态，我们一无所知。因此失联会产生和锁故障同等的事件，而不是在监控上留下一段空白。
故障格口会怎样。 它会自动从挑选中移除：不会再推给下一个人。系统为它生成一条给维修服务的任务，含柜体编号、格口编号和故障描述。只有填写了完工记录，格口才能回到流转——它自己不会「痊愈」。
设备管控的思路，与我们在 物联网监控系统中所采用的一致：指标、正常范围、保持时长、事件、责任人。区别只在于这里度量的不是温度，而是锁的应答和链路是否在线。
并非每一次偏离都是事故
级别有三档，级别决定系统去打扰谁、以及多快去打扰。
- 记录 — 写入历史，不打扰任何人：短暂的应答延迟、单次输码失败
- 事件 — 需要处理，但不紧急：门开着超过允许时长、某一个格口不应答、格口超时
- 事故 — 柜体离线、断电、一组锁失效：消息立即发出，并同时发给多名员工
保持时长——系统在报警之前所等待的时间——为每一类事件分别设定。没有它，大厅保洁和例行维护就会变成一串误报，之后再也没人会去看它们。
可用性报表
任意一段时间内，每个柜体都能看到：它在线了多久、有多少格口被移出流转以及移出了多长时间、每个格口摊到多少次故障。这些数字回答一个很实际的问题：哪些格口该换了，以及哪个柜体所在的位置根本保不住网络。
锁与控制器
凭码与刷卡开柜
管理后台
每一次开启的日志
开柜与数据
的安全
这类系统里的安全不是靠某一项措施，而是靠几条简单规则，每一条各自堵住一种进入别人格口的途径。
码的有效范围是受限的。 每个码都有期限、对应的格口和允许使用的次数。一个永不过期、任何格口都能开的码，那不是钥匙，是万能钥匙，因此系统连员工都不允许处于这种状态。
码无法被暴力猜出。 输入次数有上限，用完之后输入会被暂时封锁，而连续失败会成为一个待排查事件。没有这一条，四位 PIN 一个晚上就能试出来。
做决定的是服务器。 柜体控制器既不保存码，也不决定放谁进来——它只执行指令。因此接触到设备并不等于能打开格口，而吊销一个码是即时生效的。
所有开启都被记录。 日志不可篡改：记录既不能编辑也不能删除，更正以新增一条记录的方式写入。这对员工同样适用——维护开柜与普通开柜一样出现在格口历史里。
权限是分开的。 查看、手动开柜、修改规则和处理个人数据，是不同的权限。一个什么都能干的账号，就是整套防护唯一的失效点。
系统不负责什么。 它管的是开柜权限，但不替代物理防护：柜体的坚固程度、该区域的视频监控、人员的处置流程以及贵重物品的存放规定，仍然是场地方的责任。把这一点直说出来，比让人误以为软件能把柜子变成防火保险柜要诚实得多。
什么会进入排查队列
- 连续多次输错 — 短时间内在同一个柜体上连续输错好几个码
- 无指令的开启 — 门磁报告门被打开，而系统并未发起这次开启
- 付了款没分配、分配了没付款 — 同一个会话上两条流之间出现差异
- 频繁的手动开柜 — 某一名员工打开别人格口的次数明显多于其他人
- 重复签发开柜码 — 同一个会话的码被连续签发了好几次
这些事件单看没有一件意味着违规：老实人也会把码输错，而手动开柜有十来种正当理由。这个队列的意义在于：这类情况不会消融在总日志里，而是汇集成一份单独的清单，由人定期查看。
个人数据
关于用户保存哪些数据，由场地的使用场景决定。一次性寄存可以完全不保存——只有格口、时间和码。包月则需要一个账号。企业储物柜要与人事系统打通。采集的数据越少，需要保护的就越少，因此这个范围在开发之前就要谈定，而不是「以防万一」地不断扩大。
系统对接 与 API
寄存系统很少独立存在：它装在一个已经有自己一堆程序的场地里。数据交换通过 API 完成——一个对外接口，别的系统可以用它分配格口、取得开柜码、查询状态或拉取日志。以下是最常见的几个交换方向。
我们自己的 API
最基础的接入方式：分配格口、签发和吊销码、查询占用、结束会话、拉取事件。其余一切都通过它接入，包括客户自己的内部服务。
场地的门禁系统
用在人们本来就有卡的地方：开格口用的是与闸机同一张门禁卡。这需要就卡的类型，以及现有门禁系统对外提供什么接口，达成一致。
人事与财务系统
用于企业储物柜：员工入职即分配柜子，离职即收回权限并释放格口。否则一年之后，半数柜子还挂在早已不在场地的人名下。
支付服务
收款、退款、操作对账。具体的服务商和支付方式由项目决定，而开具税务凭证的要求由所在国家的法规和设备型号决定。
通知渠道
把消息送到用户和员工手里：应用、手机短信、即时通讯、邮件。渠道单独接入，并按场地选择。
网店与配送
通过格口交付订单的场景：订单从外部进来，系统分配格口，开柜码分别发给寄件人和取件人。这条链路的详细解析见 自助服务系统.
设备监控
把柜体和锁的状态传给外部监控系统（如果场地已经有一套的话），或者直接用我们自己的这条链路 物联网监控.
会计与报表
把收费会话和支付数据导出到财务系统。此时资费台账的归属方只能有一个——要么是财务系统，要么是寄存系统，不能同时是两个。
数据导出
定期把日志和指标推送到客户的数据仓库或报表系统——适用于场地分析建在公司统一体系里、而不是单独做的情况。
我们不预先声明一份具体的对接清单：能否交换，取决于客户侧系统对外提供什么接口。哪些可以立即接上、哪些需要对方也做改造、哪些只能靠文件导出来解决，这些在调研时就会清楚——在开工之前，而不是干到一半才发现。
这类系统 用在哪里
设备和逻辑到哪里都一样：格口、锁、码、会话、日志。不同的是使用场景、寄存时长，以及是否收费——配置上的差异，正是从这三点差别里来的。
购物中心
几个小时的一次性寄存：购物袋、婴儿车、大件物品。人流量大、访客随机，因此需要简单的凭码开柜、快速分配，以及一条硬性规则——到商场打烊时格口必须回到流转。
车站与交通枢纽
典型的行李寄存：存放几小时到几天，按时长收费，全天候运营。这里最要紧的是离线运行的可靠性和清晰的超时规则——人是会误车的。
健身房与游泳馆
训练期间用的储物柜，多数是免费的，用会员卡开。系统的价值不在收费，而在于管理员能看到哪些柜子在用，并且不用撬锁就能打开被遗忘的那一个。
办公室与共享办公
员工或入驻者的私人储物柜：归属格口、凭门禁卡开启、期限按合同。与人事系统打通，就消除了最主要的问题——柜子还挂在已离职的人名下。
商务中心
给租户和访客用的格口，以及公司之间不见面交接文件和钥匙。这里最常需要的是两个码的场景——一个投放码，一个领取码。
个人仓储
按月出租的储物间：长会话、包月付费、凭卡或凭码开启。软件部分负责期限、续期、欠费封锁和到访历史。
生产与仓库
存放工具、仪器和工装的格口。重点不在收费，而在责任：谁拿走了、什么时候还的、到下班还有什么没还回来。这里日志就是系统最主要的产出。
学校与图书馆
给学生和访客用的储物柜，以及通过格口借还书籍和设备。通常需要的是与现有的人员管理系统打通，而不是另建一套用户台账。
医疗与政府机构
候诊区给访客用的格口，以及工作人员的内部储物柜。这里对日志和权限划分的要求高于平常，而采集的数据范围则压到最低。
数据分析
与报表
系统积累的数据很多，但其中有用的很少。真正有实际意义的是四个问题：格口够不够、需要哪些尺寸、时间损耗在哪里，以及哪些设备该维护了。
使用率能说明什么。 不是一个月的平均数字，而是按小时和按天的分布：一个场地平均使用率可能是 45%，但每周六 14 点到 18 点却连一个空闲的小号格口都没有。解决办法是增加对应尺寸的格口，而不是整个再加一个柜子。
按场地统计的指标：
- 使用率 — 按小时、按星期几和按尺寸类型统计的格口占用比例
- 周转 — 一段时间内经过同一个格口的会话数
- 平均会话时长 — 分别按尺寸类型和按星期几统计
- 分配失败 — 有多少次因为没有对应尺寸的空闲格口而没能给到人
- 超时 — 超出时限的会话占比，以及它们把格口多占了多久
- 设备可用性 — 格口被移出流转的时长，以及原因
- 营收 — 在收费寄存场景下：按场地、尺寸类型和时间段统计
分配失败是最被低估的一项指标。 占用情况人人都看得到，可是那个走过来、没找到空闲格口、转身就走的人，在普通统计里根本不留痕迹。而恰恰是这个数字，回答了柜体要不要扩容的问题。
报表可导出为文件，也可以按计划生成——例如每月一号一次性覆盖所有场地。
按小时的使用率
图上连续两小时满占，并不意味着「用得挺好」，而是意味着排队和拒之门外。这项指标旁边永远放着没拿到格口就离开的人数——否则这个峰值会被读成一次成功。
这些数字在实践中有什么用
- 该加多少格口、加哪种 — 依据分配失败次数和按尺寸类型拆分的使用率，而不是靠总体感觉
- 资费要不要调整 — 如果格口被占八个小时，那资费不是在抑制周转，而是在鼓励占用
- 哪里需要第二个柜体 — 按分配失败次数和峰值使用率横向对比各场地
- 哪些格口该换了 — 依据某个具体格口在一段时间内的设备故障次数
落地实施的 顺序
这些阶段的顺序不能变。跳过调研，是系统最后被搭在一台根本不接受所需指令的设备上的最常见原因。
1. 调研
场地上现在已经有什么：柜体、锁、控制器、读取设备、网络、供电。需要哪些场景、寄存是否收费、谁对格口负责。产出是：哪些可以立即接入、哪些需要改造、场地还缺什么。
2. 单柜试点
完整跑通一个柜体：在真实设备上与控制器交互、验证开启和传感器、按人们的实际行为而不是按文档去调整时限、资费和规则。
3. 规则与角色
谁对哪些场地负责、哪些事件发给谁、什么算事故、超时如何处理。员工权限和手动开柜的流程也在这一步配置。
4. 推广部署
其余柜体和场地按已跑通的方案铺开，新类型的设备则作为单独的交互模块接入。此后历史逐渐积累，跨周期的报表和用于扩容的数据也就有了。
我们的 客户
聊聊贵方的寄存系统
立即联系我们
请写明这是什么样的场地、有多少格口、现在装的是哪种柜子、寄存是否收费，以及谁来使用这套系统。我们会回答：现有设备能接入什么、哪些开柜场景更合适，以及试点从哪里开始比较合理。
