山谷里12间房的民宿,把系统这件事当天办完了
山谷民宿,12间房,5个人。这篇讲一家小民宿从纸质登记到系统当天上线的事。
没有需求文档,没有软件公司,需求是一句大白话,说的是预订、登记、保洁三件事。当天,四种角色、三张表单、四条工作流全部生成,第二天正式接客。
这篇把全程摊开:难账在哪,那句话怎么变成系统,一个季度跑出什么。
一、样本:山谷民宿的三本难账
1、业务底子
样本是宁老板的山谷民宿:一条山路进出的山谷村,12间客房,5个人——前台姑娘、保洁阿姨、管家、做饭的师傅,加他本人。
民宿的账,难在「散」。
预订的账难:订单来自五个口子:OTA两成多,微信直订、电话、老客介绍凑其余。订单记在本子上,房态记在白板上,节假日一改单,漏改一头就是超售。
入住的账难:登记靠手写两联单。想查「上个月谁住过201」,翻本子翻到眼花。
保洁的账难:谁打扫、哪间扫了,全在保洁阿姨脑子里。旺季连着退房,漏扫一间,下拨客人进了没打扫的房,体验砸手里。
2、旧路的账
宁老板算过上系统的账。
定制开发,前年问过:报价九万,工期四个月,还要先交需求文档。九万抹掉小半个旺季利润,报价单他压在抽屉里两年。
酒店版SaaS,去年试过:一年好几千,装上发现两个别扭。
其一,民宿要分「整栋包院」和「单间」两种卖法,系统里整栋就是一个大房间,跟单间拼着卖打架。
其二,保洁按「次日集中派单」设计,山谷民宿的规矩是退房后立刻打扫、新客中午直接进房。用了一个月,退了。
3、一句话生成
今年开春,开民宿的同行推荐了搭贝。宁老板晚上安顿完客人注册,第一句话:
先出来的是方案说明:预订怎么记、入住怎么登、保洁怎么派,逐条摆开。
宁老板核出两处口径。
其一,预订默认不分卖法,实际要分「整栋/单间」——整栋一口价,单间按间夜,库存联动:整栋一卖,单间全锁;改。
其二,保洁默认「次日集中派单」,实际要「退房后即派」——退房立刻扫,改。
两处一句话改完,方案当场刷新。
二、九步实录
1、第一步:填写需求
就是开头那句大白话,没有需求文档。一句话锚定方向:预订、入住、保洁,三摊生意的骨架,后续每一步都在这个骨架上长肉。
2、第二步:引导问题
系统追问四件事:

四问答完,最容易扯皮的口子全部有了预案。预案不是系统送的,是宁老板自己的规矩——问答把它们挖了出来。
3、第三步:生成总览
四问答完确认,系统当天生成。总览一屏摊开:角色、表单、看板、流程、规则、智能体全部在列。
宁老板的原话:「我以为是效果图,点进去发现都能用。」
4、第四步:角色
三种角色:

老板管全局审批,前台管预订入住,保洁只见任务,管家管客需盘点。
5、第五步:表单
十一张表单:

预订单带渠道标记,OTA单直询单两个口径,改期留痕。
登记单带姓名、证件、日期、房号,退房自动生成保洁任务。任务单带房号、状态、完成时间,加急要老板批准——规矩长在单子上。
6、第六步:看板
老板视角的看板三块:

宁老板最常用的是房态总览:12间房住没住、谁住、哪天走,一屏全见。
渠道占比是另一块——OTA佣金22%以前是笔糊涂账,现在每月一眼看清。前台有预订队列,保洁有任务清单,各盯各的活。
7、第七步:流程
三条工作流把全店串起来:

预订流管订单房态,入住流管登记交接,保洁流管打扫验收,对账流管日结对账。
规矩长在流程里:整栋一卖单间全锁,卡在预订流;退房后即派,卡在入住流和保洁流衔接上。
8、第八步:业务规则
四条核心规则,上线前单独验证过。

规则是问答环节定下的口径,生成时落成了硬约束。这是「规矩」和「愿望」的区别。
9、第九步:AI智能体
生成物里带预订改期智能体:客人改期,系统先核房态,先于老板开口。
按官方口径,智能体在关键环节主动辅助:改期它先核房态,退房它先派保洁,对账它先出差异。
配合AI工作流智能对话,跟系统说话就能改流程。「OTA取消单当日清差价」说出去,当天进对账流。

一处小瑕疵:客户信息默认带「血型」字段。住个宿登记血型,隐私和生意无关。说了一句「去掉血型」,当天删除。

三、上线一个季度:正式业务的答卷
1、三本难账的变化
预订:五个口子的订单一张表,节假日超售清零——本子和白板两头的改,变成房态一处改、处处生效。OTA佣金占比22%头一回看得清,直订比例从一成半提到四成。
入住:两联单退休。想查「上个月谁住过201」,点两下屏幕。
保洁:漏扫清零。旺季那周12间房连退连进,任务单一条不乱。
2、两个数字
直订涨到四成——省下的佣金一年是笔可观数字。账变准数,客人自然往直订走。超售清零——不是房多了,是联动的责任从本子转到系统,敢卖了。
3、员工的状态
5个人,上手三天。保洁阿姨五十多岁,第二天就自己点任务单干活。
前台姑娘的评价最直接:「以前节假日改单,一手本子一手白板两头改,现在只盯屏幕。客人电话里改期,当面就改完。」管家也发现:任务单写着房号和状态,谁的活谁认领,月底盘物资不用对嘴。
四、「当天上线」的三个前提
1、规矩说得清
整栋单间联动、退房后即派——这些规矩宁老板张口就来,因为想了两年。
AI生成的是规矩的载体,不是规矩本身。规矩说不清的生意,先理业务再谈系统。
2、验证做得实
上线前三步验证:总览逐项点验、历史订单录系统比对、新旧并行十天四次对账零差异。生成完直接切正式的冲动,被这十天按住了。
生成的系统不是不能信,是不该盲信。验证这一步,谁也替不了你。
3、边界认得清
这套系统管的是预订、入住、保洁、对账的骨干。门锁、发票直连不在这次生成范围内——边界清楚,各行其是。
「能用于正式业务」不等于「能用于一切业务」。边界认清楚,甜区才用得足。
宁老板的判断可以抄作业:骨干进系统,门锁和发票留给以后的开放能力。
常见问题
Q1:AI生成的系统,稳不稳?
稳不稳看验证。生成总览逐项点验、历史订单比对零差错、并行十天四次对账零差异后切换,正式跑一个季度零事故。过的是工程验收的关,不是感觉的关。
Q2:12间房、五个订单口子,撑得住吗?
撑得住。五种渠道一张预订表、房态一处改处处生效、改期留痕,这个量级远没到系统的边界。
Q3:酒店版SaaS也管预订,为什么换生成的?
SaaS装不下「整栋/单间」的库存联动,保洁按次日集中派单设计,跟「退房后即派」的规矩打架。生成的系统把这两件做成硬约束——核心诉求在哪家,就选哪家。
Q4:保洁阿姨年纪大,会用吗?
最年长的五十多岁,第二天自己点任务单干活。保洁只见任务清单,界面打开就是自己的活。
Q5:客人数据放系统里安全吗?
权限分级,操作留痕。登记单修改留痕到改前改后的值。比两联单压抽屉谁都能翻的年代,只安全不危险。
Q6:业务变了跟得上吗?
跟得上。说一句话当天进流程。上线一个季度改了几处,全部对话式修改,当天生效,不另收费。