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,也不儲存臨床記錄或處方。

可以加訂閱或續費提醒嗎?

可以,作為外掛商店裡的可安裝擴充套件——會員與訂閱讓顧客從你的主頁買下方案,續費提醒就挨著它。兩者對任何業務型別都適用。解除安裝會移除磁貼,但不會移除資料。

把服務清單放進去

建立一家服務或診所商家,加一個帶時長的專案,然後接一次預約。