案例研究 / 02
Power Platform 内部运营工具组
Power Apps / Power Automate / Microsoft Lists
2025 年 4 至 7 月搭建的三个面向一线员工的工具，把承包商管理、客房清洁员考勤和物资订购，从纸张、Excel 与口头交接转成结构化、可审计的流程。
← 全部项目复杂度超出后 → React · TypeScript · Node · SQL
挑战
酒店运营靠纸质签到表、Excel 和聊天消息运转。「谁在店里」「谁签到了」「那批货到了没」，不问一圈没人答得上来。
我的贡献
走进运营现场，梳理每一条人工流程，在 Microsoft Lists 里建数据模型，用 Power Apps 搭出员工真正在用的界面，再用 Power Automate 接上背后的逻辑——然后在实际运营中持续修改。
第一阶段 · 2025 年 4–7 月
在平台之前，
是现场的三个工具。
酒店运营数字化的第一步。每个工具都从一个真实的一线问题出发，在 Microsoft Lists 里建模，配上 Power Apps 界面与 Power Automate 流程，再在实际使用中修改。
- 012025 年 4 月承包商与访客管理
- 022025 年 4 月客房清洁员签到与考勤
- 032025 年 7 月库存与订单追踪
三条工作流
每一条都替掉了
一段人工流程。
每张卡同一套骨架：问题是什么、界面做什么、数据怎么建模、自动化承担什么、一条记录经过怎样的生命周期、酒店从中得到了什么。
承包商与访客管理
2025 年 4 月
- Power Apps
- Microsoft Lists / SharePoint
- Power Automate
- Microsoft 365
问题
维修人员、供应商和其他承包商来店时没有统一记录。前台看不到今天谁会来、谁已经在店里、谁已经离开——事后也没有历史可查。
应用做什么
- 登记：姓名、公司、电话、车牌、来访目的、计划到达与离开时间
- 「今天 / 即将到来」视图，让前台在承包商到达之前就看到当天和未来几天的安排
- 一键 Check in / Check out，记录实际到达与离开时间
- 管理层可查看完整记录；前台只处理当前与即将到来的名单
数据模型
- 姓名
- 公司
- 电话
- 车牌
- 来访目的
- 计划到达
- 计划离开
- 签入时间
- 签出时间
自动化
Power Automate 让工作名单与长期历史保持同步：日常视图始终很短，而每一次来访都被保留。
生命周期
- 01已安排
- 02已签入
- 03已签出
- 04历史记录
业务价值前台能回答谁要来、来做什么、现在是否在店里、什么时候走的——并为运营、安全与审计保留完整记录。
客房清洁员签到与考勤
2025 年 4 月
- Power Apps
- Microsoft Lists
- Power Automate
- 二维码流程
问题
客房清洁员的签到、签退和工时靠手写记录。大多数清洁员没有 Microsoft 365 账号，普通的办公应用根本不会有人用。
应用做什么
- 班次开始时通过二维码进入签到流程
- 记录清洁员姓名、签到时间、签退时间与签名
- 由两个时间点自动计算工时
- 围着现场而不是办公室设计：大控件、最少输入
数据模型
- 清洁员姓名
- 清洁员
- 签到时间
- 签退时间
- 出勤
- 工时
- 签名
自动化
Power Automate 处理签到 / 签退逻辑，并根据记录的时间计算实际工时。
生命周期
- 01签到
- 02工作中
- 03签退
- 04工时已计算
业务价值考勤从手写变成结构化记录。设计思路随后延伸到房间任务分派、清洁状态、查房员通知与查房流程——成为后来完整平台的早期雏形之一。
库存与订单追踪
2025 年 7 月投入使用
- Power Apps
- Microsoft Lists / SharePoint
- Power Automate
- Microsoft 365
问题
餐饮、前厅、工程和客房都在持续采购物资，却没人能很快说清：订了什么、谁订的、什么时候到、到了没、实际到了多少、谁收的、放哪了。
应用做什么
- 订单日志：品名、类别、下单日期、预计到货、下单人、备注与数量
- 画廊只显示未收货订单——Received Date 为空——先按预计到货、再按下单日期排序
- 收货：收货日期、收货人、实收数量、收货备注、签名与存放位置
- 前厅、客房与餐饮员工跨班次共用，交接靠看，不靠说
数据模型
- 品名
- 类别
- 下单日期
- 预计到货日期
- 下单人
- 订单备注
- 订购数量
- 收货日期
- 收货人
- 实收数量
- 收货备注
- 收货人签名
- 存放位置
自动化
Power Automate 与 Microsoft 365 承载收货更新，订单一经签收，状态立刻对下一班可见。
生命周期
- 01已下单
- 02等待送达
- 03预计到货
- 04已收货
- 05数量已确认
- 06已签收
- 07已入库
业务价值松散的「等货 / 找货 / 问谁收了」变成可追踪的流程。下一班看到的是当前订单状态，而不是依赖口头交接。
每个工具都是这样做出来的
同一套方法，
做了三遍。
- 01从真实的酒店运营问题出发
- 02先分析现有的人工流程
- 03把业务过程结构化为明确的步骤与状态
- 04在 Microsoft Lists 里设计数据模型
- 05用 Power Apps 搭面向员工的界面
- 06用 Power Automate 处理流程与自动化
- 07在真实的酒店运营环境中持续修改
低代码撞到的边界
工具是好用的。
架构却没有余地了。
系统越长越大，同样的压力反复出现。它们没有让工具失效，却让下一个系统必须是另一种系统。
数据规模与查询性能
Microsoft Lists 做登记表很舒服；一旦运营历史不断累积、查询越来越具体，它就开始吃力。
Delegation 与筛选
Power Apps 的 delegation 限制封住了能在服务端筛选与排序的范围，数据一多，「只给我看这个」就越来越难。
权限模型
超出「前台 vs 经理」的基于角色的访问控制，需要比 List 级共享更细、更可强制执行的规则。
跨酒店隔离
三家酒店共用一套运营，每家的数据必须靠规则限定范围，而不是靠谁碰巧打开了哪张 List。
工作流状态
真实运营里有异常、返工和交接，一张带状态列的表单装不下。
UI 与体验控制
一线界面需要为具体岗位调校的布局与交互，超出了画布所能给的。
系统集成
要和物业管理系统及其他工具对话，需要真正的 API 层，光靠连接器不够。
交付过程
这项工作
是如何成形的。
从对问题的第一个模型，到检验系统的实际行为。
观察人工流程
先和前台、客房与采购一起看承包商怎么登记、考勤怎么记、订单怎么追，再决定做什么。
在 Lists 里建数据模型
把每条流程转成字段明确的 Microsoft Lists，把员工每天要碰的数据和必须留存的历史记录分开。
搭员工用的界面
Power Apps 的画廊与表单围着班次来设计：今天和即将到来的放最前，签入签出一键完成，未收货订单排在最上。
在现场迭代
员工在实际运营中使用时，随时调整字段、筛选与流程；凡是规则能替代人工步骤的地方，就补上 Power Automate。
工程证据
那些
真正重要的细节。
- 三个月内上线三条工作流，跨班次使用
- 承包商登记：9 个字段，涵盖身份、来访目的与计划 / 实际到达与离开时间
- 客房清洁员考勤：两张核心 List（HouseKeepers、AttendanceRecords），二维码入口，没有 Microsoft 365 账号也能用
- 库存与订单日志：13 个字段，从下单到入库的 7 步生命周期，「未收货优先」并按预计到货排序的画廊
- 日常操作数据与长期历史记录分开保存，便于审计
- 复杂度超出低代码后，被 React / TypeScript / Node.js / SQL 平台取代
决策细节 / 展开阅读
01日常操作与长期历史分开
承包商工具的工作视图只保留今天和即将到来的来访，而每一次来访都会落到一份长期记录里。前台看到的是一张短名单，管理层和审计拿到的是完整历史。
02为没有 Microsoft 365 账号的员工设计
大多数客房清洁员没有租户登录，考勤不可能做成普通的办公应用。二维码入口加签名字段，让它能在班次开始时、在现场直接用。
03先显示最需要跟进的
订单画廊只显示 Received Date 为空的行，先按预计到货、再按下单日期排序。下一班打开时看到的是要追的货，不是档案库。
04知道何时离开低代码
工具越做越多，Lists 的数据量、Power Apps 的 delegation 限制、权限需求、跨酒店隔离和更复杂的工作流状态都在顶着平台的天花板。这股压力决定了全栈重建的方向。
结果
三条人工流程变成了跨班次可见的结构化记录；这段经历也定下了后来整个酒店运营平台沿用的方法——观察、建模、搭建、修改。
内部工具，运行在私有的 Microsoft 365 租户中。没有公开产物或截图；字段结构与流程描述来自实际搭建的系统。后被自研的酒店运营平台取代。
- Power Apps
- Power Automate
- Microsoft Lists
- SharePoint
- Microsoft 365
下一个案例
03Old Town Hotel→