●ENS 最高级别认证 · 有效
● system online// 问题
在群里说一声的故障，等于没发生。
多数酒店里，故障靠口头、电话或群聊上报。这套做法一直管用，直到有人要问：还有什么没处理完？是谁修的？三楼漏水平均要修多久？
01
会丢。 走廊上说的一句话，或者一天四十条消息的群里的一条，都不会留下任何痕迹。
02
没人知道进度。 报修的人不知道，客房主管不知道，管理层也不知道。只能去问。
03
没有历史。 客房没有，每两个月坏一次的设备没有，各部门实际耗时也没有。
// 它做什么
上报、派单、处理——并且拿得出证据。
按位置的二维码
每间客房、公共区域或机房贴一个码。一扫，工单就知道自己在哪儿。
部门收件箱
每个分类——水暖、空调、电视——都落到对应部门。维修看自己的，前台看自己的。
带证据的流转
从新建到已派单、处理中、已关闭，按配置要求开单与关单时必须附照片。
周期任务
每周或每月该做的巡检自动生成，和普通工单一样出现在列表里。
不可篡改的记录
每一次变更都记下是谁、何时。事后无法修改：历史记录的价值正在于此。
报表
什么在反复发生、哪个部门积压最多、关单到底需要多久。
// 谁在用
各看各的，互不打扰。
权限按部门授予，而不是按人：同一个人可以在前台报修、在维修部处理。而且客房主管对自己员工上报的事仍有话语权，哪怕动手修的是别的部门。
// 工单生命周期
新建已派单处理中已关闭挂起
1上报
客房部与前台。在现场用手机带照片开单，并跟进自己报的。
2处理
维修部。看本部门收件箱和派给自己的工单，主动领取，带证据关单。
3监督
部门主管与管理层。派单、定优先级、重开工单、看报表。业主与审计为只读。
// 管理后台
管理层一眼看清整家酒店。
哪些未处理、哪些在处理、今天关了多少、平均要多久。不用找任何人要报告：看板的数据完全来自团队在手机上的操作。
backoffice.ordenly.es
未处理
12
处理中
5
今日关闭
18
平均用时
2:14
| 工单 | 位置 | 部门 | 优先级 | 状态 |
|---|---|---|---|---|
| #2041洗手池下漏水 | 304 房 · 3 层 | 维修部 | 高 | 处理中 |
| #2040灭火器巡检 | 地下室 · 设备间 | 维修部 | 中 | 新建 |
| #2038空调不制冷 | 212 房 · 2 层 | 维修部 | 中 | 已派单 |
| #2036窗帘脱轨 | 118 房 · 1 层 | 客房部 | 低 | 挂起 |
| #2029房卡刷不开 | 401 房 · 4 层 | 前台 | 低 | 已关闭 |
// 技术内部
从设计上就让任何一家酒店看不到另一家的数据。
这是一套多租户平台：所有酒店共用基础设施，但谁也看不到别人的一行数据。这件事不能靠写代码时小心，而要在数据库这一层解决。
- 01在数据库层隔离。 每一行都带着它的租户，引擎拒绝从其他租户读取它——哪怕查询写错了。
- 02原生 iOS 与 Android 应用，一线员工个人手机保持登录态，共享设备用 PIN 进入。
- 03照片与附件存放在欧洲，下载链接带签名且会过期。
- 04第一天起就有监控。 错误、指标，以及从外部检查 API 是否响应，异常直接通知值班。