Korat
功能

客人先约、店家确认、再指派员工

一套店家自己就能配好的在线预约系统。一个服务有时长和价格。一次预约有一个人挂在上面。一份疗程是 N 次、有效 N 天,随核销递减。美发店、汽修厂、工作室或诊所需要系统记住的,大部分就是这些。免费,没有月费。

两种业务类型共用这套预约系统:serviceclinic。它们跑同一份代码——服务、预约、员工指派、套餐——而诊所类型把界面词汇改成预约、患者和疗程,因为牙科诊所和美甲店面对的是同一个排期问题,只是说法不同。选择类型改变的是词汇,没有任何结构性差别:一个单独的诊所产品会在两个版本之内和服务产品分道扬镳。

一个服务就是你定的时长加价格

目录是一份服务清单,每项带时长和价格。时长不是装饰——它才让一本预约册有意义,因为九十分钟的疗程和十五分钟的修剪占用的是同一天里不同的份额。顾客在店铺公开主页上浏览、选一项服务并预约;那一段页面区块由服务模块自己贡献,用的是和其他模块相同的共享 UI 套件,所以它看起来是原生的,不是焊上去的。

预约,以及店家自己按下的确认

一次预约请求携带姓名、电话、日期、时间和备注。它以待处理状态到达,由店家确认。待处理数量是控制台仪表盘上的实时角标之一,每隔几秒刷新,和进行中的订单、呼叫服务员的桌台、待批的请假并排——所以一家跑着好几个模块的店,只有一个地方在统计等着人处理的事。

确认这一步不是为了制造摩擦。一个日历有空就自动接受的预约系统,会接下技师那天不在的那一单,以及只有当十点提前结束才成立的那个十一点。让接受成为一个人的动作,把店家自己的知识留在环路里,也给顾客一个确定的答复,而不是一个会悄悄挪动的时段。

每次预约都可以指派给一名员工。这一个字段把一份预约清单变成一个能开工的工作日:它回答谁来做,让回头客能被交回同一个人手上,还会汇入客户历史,让店家知道熟客是冲着自己哪位师傅来的。

一位技师的今天 9 10 11 12 13 14 15 16 17 18 修剪 15 分钟 疗程 90 分钟 新请求,等店家确认 90 分钟 已确认并已指派 等店家确认
每一格的宽度就是这项服务真正占用的时长;店家还没确认的请求画成虚线(示例排期)。

套餐与预付疗程:N 次,有效 N 天

预付业务有自己的模型,而不是当成一次普通销售。一份套餐要么是 N 次、有效 N 天的疗程,要么是有效 N 天的会员。顾客买下它,一次核销一次;“我的套餐”页显示他们持有什么、还剩多少。那个剩余次数是记录本身,存在和消耗它的预约同一个后端上,而不是钱包里一张盖章卡。

购买套餐也是评价资格视图里的合格交易之一,所以疗程顾客在核销第一次之前就可以评价这家店。

没有短信提醒,因为根本没有短信。电话验证和短信发送都没有构建——端点返回 501 并明说这一点。通知在应用内送达顾客,邮件只发往已验证的地址。

诊所类型只是换词,不是病历系统。它把界面改称预约、患者和疗程。它不存储临床记录、处方,或任何应该待在 EMR 里的东西,也不是为此而建的。

店主在这周围拿到什么:报表、客户台账和人事

服务或诊所商家拿到三块模块磁贴——预约、服务和套餐——加上每种业务类型都有的一切。报表覆盖营业额、订单数、客单价、现金/PromptPay/其他的构成、销量前五、七日营业额图表,以及今天/七天/三十天/全部四个周期,附带收据补打和可分享的收据文本——但开不了税务发票,因为只有增值税登记人才能开具,而系统里还没有记录任何一家店的登记信息。对一家服务店来说,销量前五读起来就是“哪些项目真的在赚钱”,通常不是海报上那个。

客户台账由销售流水生成,带备注和标签、购买历史,以及按店家自设汇率累积的积分,对应可配置的最低消费额与奖励。HR 覆盖员工那一侧:带 GPS 和备注的上下班打卡、请假申请、排班与工资,含实际工时和一天超过八小时的加班,按时薪或月薪计算,另有公告与可指派的任务。工资的可见性是分级的——普通成员只看得到自己那份,店主和经理看得到所有人。

访问权限跑在权限矩阵上:十三项核心能力加上已安装模块声明的能力,店主、经理、服务员、厨房和员工五种角色预设,以及按人覆盖。成员缺少某项能力时磁贴直接消失;还没有任何权限的成员会看到一屏明说这件事的界面,而不是一个读起来像 bug 的空列表。在安卓应用里这些检查跑在客户端;同一套矩阵在数据库里以 has_capability(business_id, capability) 存在,为行级安全策略在服务端展开。

底层的模块系统,以及可安装的扩展

服务是四个核心模块之一,另外三个是点餐住宿和零售——业务类型就是模块。一个模块声明自己的 id、认领的业务类型、标签、目录标题、主要行动按钮、目录视图,以及可选的能力、控制台磁贴、控制台界面和面向顾客的页面区块。正因为有这份契约,权限编辑器才能由已安装模块所声明的能力自动生成。

在这之上还有四个对任何业务类型都适用的可安装扩展,从控制台里的插件商店安装:团队权限、收款渠道、会员与订阅,以及续费提醒。后两个和服务类商家显然是一对——顾客从店铺主页买下的一份方案,以及到期前的一次提醒。卸载在一个确认框后面,确认框明说数据不会被删除;被卸载的扩展不再贡献任何磁贴、任何权限和任何面向顾客的区块。第三方插件还没有开放,商店自己就是这么写的。今天存在的,是一套带自研扩展的模块化架构,而开放提交是下一步。

结束之后的评价

使用过服务是评价资格视图里的合格类型之一,所以真的被服务过的顾客可以写评价,其余的人看到一张说明按钮为什么不在的锁定卡片。星级由数据库触发器从评价记录重算,从来不是手填的。评价可以带照片,有五到一的分布汇总,可以编辑或删除自己最新的一条,回访时新增一条而旧的一条保留,店家可以公开回复。

当天到店、不预先定时间的客人,用排队叫号更合适——扫码取号,看得到自己排在第几位,不必先选一个时段。

被指派的那位员工今天上不上班、请没请假,来自我的职场里的同一张排班表;第一次开出这套后台,从面向商家那一页开始。

常见问题

可以把预约指派给具体员工吗?

可以。每次预约都能指派员工,这正是让当天的清单变成一份可执行排期而不是一个队列的原因——而且它让回头客能被交回同一个人。

预付疗程怎么运作?

一份套餐是 N 次、有效 N 天的疗程,或有效 N 天的会员。顾客买下后一次核销一次;“我的套餐”页显示他们还持有什么。剩余次数存在后端,不在柜台的一张卡上。

顾客会在预约前收到短信提醒吗?

不会。这里没有接入任何短信服务商——电话验证和短信今天都返回 501。通知在应用内送达顾客,邮件只发往已验证的地址。

诊所类型适合用来管病历吗?

不适合。选择 clinic 只是把界面改称预约、患者和疗程。它是一套带诊所词汇的预约与套餐系统,不是 EMR,也不存储临床记录或处方。

可以加订阅或续费提醒吗?

可以,作为插件商店里的可安装扩展——会员与订阅让顾客从你的主页买下方案,续费提醒就挨着它。两者对任何业务类型都适用。卸载会移除磁贴,但不会移除数据。

把服务清单放进去

创建一家服务或诊所商家,加一个带时长的项目,然后接一次预约。