门店概况（假想）
业态
居酒屋 · 可承接宴会
门店数
5 家门店（横滨近郊）
座位数 / 店
40〜70 席
员工
每店 8〜12 名（含兼职）
客单价
¥3,500〜4,800
营业时间
17:00〜次日 0:30
SIMULATION CASE · 假想情景案例 #01
“Aburiya” 5 家门店，
迁移 3 个月，预订漏接从每月 40 件降到 0 件
这是一个假想的居酒屋连锁“Aburiya”在横滨近郊经营 5 家门店，从 Air Regi 与 3 个网站的预订管理整合到 RestaurantOS 的 3 个月迁移情景。
预订漏接 每月 40 件 → 0 件
Before — 迁移前的状况
Gurunavi、Tabelog、Hot Pepper Gourmet — 3 个预订网站分别用不同的终端应对，周五的晚上真的搞不清楚到底发生了什么。
感觉每月漏接的预订有 30〜40 件。接不到电话，回拨过去又已经被订走了。顾客的信任也在一点点被削减。
5 家门店的排班调整，是店长通过 LINE 发过来、再由总部的人转抄到 Excel 里。当天的变更传不到现场，现场也因此起过争执。
— 假想老板 / 50 多岁男性 / 经营 5 家门店
Why RestaurantOS — 比较选型的决定性因素
- Air Regi、Toreta 也曾列入候选，但判断“只做 POS”“只做预订”解决不了 3 个网站的整合问题。
- 决定性的一点是，用 external-reservation-parser 插件可以把 3 个网站的预订邮件自动整合到 1 个台账里。
- 从总部对 5 家门店的统一管理（排班、销售分析）也能在同一个画面上完成，因此不增加现场负担就能管理。
导入流程（3 个月）
第 1〜14 天
并行运行阶段
Air Regi 与 RestaurantOS 并行运行。先在 1 家门店（横滨总店）启动试点，把预订数据导入 RestaurantOS 一侧，用双重录入验证准确性。
第 15〜30 天
POS 切换
横滨总店的 POS 完全切换到 RestaurantOS。Air Regi 仅作为查阅预订之用保留 30 天，之后完全停用。
第 31〜60 天
剩余 4 家门店的依次推广
以每周 1 家门店的节奏推进。在各门店重复 3 天并行运行 → 切换的流程。
第 61〜90 天
排班、分析的总部整合
5 家门店的排班用 RestaurantOS 的 shift-adjustment 整合。总部的 Excel 汇总工作归零。
实际导入的 6 个插件（假想）
预订管理
5 家门店预订台账整合
外部预订对接
3 个网站自动导入
POS
从 Air Regi 切换
排班调整
5 家门店统一管理
销售分析
各门店 KPI
AI 聊天
总部与店长间协同
After — 3 个月后的数字
预订漏接
0 件/月
每月 40 件 → 0 件
总部汇总工时
−12 h/周
每周 16h → 4h
排班调整失误
−85 %
凭感觉的数值
外部预订同步
<5 分钟
此前 30 分钟 → 5 分钟
总部与现场的沟通
+3 倍
信息的流通量
老板到店频率
−2 日/周
在家也能做经营判断
老板的声音（假想）
周五 20 点，即使 3 个预订网站的电话同时响起，全部都会进到 1 个台账里。光是这一点，就感觉店长脑子里的负担少了一半。
以前每周花在总部 Excel 汇总上的 16 个小时，变成了我自己去现场看看情况的时间。这一点很难体现在数字上，但对经营来说是最大的变化。
系统本身一开始是让人害怕的。但我们只用 1 家门店做试点，放心之后才推广到其余门店。因为可以并行运行，所以不用停业。
— 假想老板