ybuild / 場景

為你的美髮沙龍打造線上預約應用

一家沙龍的生死，繫於那本座位（美髮椅）日曆。近一半的顧客預約發生在營業時間之外，透過線上預約的初次到店顧客，回頭頻率大約是散客的兩倍；然而大多數沙龍至今仍靠一本紙本預約簿、Instagram 私訊，以及一支在染髮做到一半時響起的電話，來撐起一整天的運轉。用大白話把你的沙龍講給 ybuild 聽，它就把這段描述變成一套真正在運行的預約系統，託管在你自己的網域上，在你專心剪髮的同時把美髮椅一張張填滿。

痛點

顧客想在晚上 11 點從 Instagram 上預約，但沙龍的電話只在朝九晚五時段有人接，於是這筆預約要嘛石沉大海，要嘛落進一則直到隔天早上才有人看見的私訊裡。
兩位設計師被安排到同一張椅子上，或者一場需要 3 小時的 Balayage 挑染只被排了 45 分鐘的檔期——因為可約狀況只存在某一個人的腦子裡和一本紙本記事簿上。
爽約和臨時取消每週都在悄無聲息地像放血一樣蠶食營收，既沒有預先綁定的信用卡，也沒有一套軟體真正能執行的規則。
通用的預約工具按設計師人頭收費，把你的品牌藏在它們的平台後面，還占著你的顧客名單——等於你在租用本該屬於自己的櫃檯。

你能打造什麼

屬於你自己的預約頁面

一個掛在 yoursalon.com（你自己網域）上的品牌化頁面，顧客在這裡選好服務項目和設計師後，看到的只有真正能容納該項目所需時長的時段，而不是隨便一個 30 分鐘的空檔。顧客一進入結帳流程，這個時段就立即被鎖定，絕不會出現兩個人同時搶下午 2 點、而其中一個還在輸入手機號碼的情況。配色、Logo 和服務菜單都是你的，隨之而來的那份顧客名單也歸你所有。

美髮椅日曆

一個按天呈現的檢視畫面，每位設計師占一欄，把每一個預約、染髮等待的空檔、午休和休假日都一覽無遺。櫃檯用拖曳來改約，把散客和電話預約直接放到對應的那一欄上，而且絕不會因為疏忽把同一張椅子重複預約——因為所有管道都即時寫入同一本日曆。

訂金與提醒

預約時收取並留存一張信用卡，一則自動確認立即發出，一則提醒會在預約前 24 小時透過簡訊和 Email 送達；對於爽約，則按你設定的規則扣款，讓原本白白流失的營收不再漏掉。而當顧客真正到店的那一刻，訂金就會自動折抵到最終帳單裡。

數據模型

clients

client_id, name, phone, email, formula_notes, allergy_flag, tags, no_show_count, created_at

services

service_id, name, category, base_duration_min, buffer_min, price, deposit_amount, requires_patch_test

stylists

stylist_id, name, level, working_hours, days_off, service_ids, commission_rate

appointments

appt_id, client_id, stylist_id, service_id, start_at, finish_at, process_gap_min, status, source, deposit_paid

payments

payment_id, appt_id, type, amount, method, card_on_file_id, status, refunded_at

系統裡的一天

晚上 10 點，一位顧客來到 yoursalon.com，選了由 Maya 服務的「Balayage 挑染 + 剪髮」，頁面只顯示那些 Maya 有完整 3 小時空檔的時段，而不是隨便一個 30 分鐘的空隙。
由於這是一位初次染髮的顧客，流程會標記出需要先做皮膚過敏測試（patch test），並在正式染髮預約之前，提供一個提前 48 小時的快速皮膚測試時段。
顧客支付了訂金，信用卡被留存下來以備執行爽約規則，下午 2 點的時段隨即立即鎖定，這樣下一位訪客就無法在其填寫表單的過程中搶走它。
一則簡訊和一封 Email 確認當場發出，同時安排好一則在預約前 24 小時送達的提醒。
隔天早上，櫃檯打開當天檢視畫面：每位設計師各占一欄，染髮等待的空檔顯示為可再利用的時間，一筆電話預約被直接放進 Maya 那一欄。
顧客到店，預約被標記為進行中；在染膏顯色的這段時間裡，那個空檔是空出來的，Maya 可以在另一張椅子上先為別的顧客做個快速吹整。
結帳時，服務被標記為完成，訂金被折抵，零售產品和小費一併加上，尾款則從同一張卡裡扣取。
另一位顧客始終沒有出現，其狀態被翻轉為爽約，費用按規則扣取，其 no_show_count 計數隨之加一，好讓櫃檯下次一眼就能看出這個慣犯的苗頭。

AI 容易出錯的地方

顯色等待的時間不是閒置時間。在染膏顯色期間，設計師會刻意再接一位顧客，所以一套硬性禁止任何時間重疊的系統，會徹底破壞沙龍真實的運作方式。要把一次預約建模成「前段準備 → 中間等待（process_gap）→ 後段收尾」三段，這樣椅子在服務中途就能空出來，而不是被整整鎖死 3 個小時。
時長不是一個固定的數字。同樣一套剪髮加染髮，在又長又厚的頭髮上、或由資歷較淺的設計師來做，都會比資深設計師耗時長得多。要按服務項目、也按設計師級別分別存放時長，否則整天的排程會悄悄偏移，後面每一位顧客都得乾等。
皮膚過敏測試是一道真實存在的法律與安全關卡。許多地區都要求在新顧客染髮前 48 小時先做一次過敏預警測試。預約流程必須能辨識出初次染髮的顧客，並拒絕當天染髮，而不是歡天喜地地照單預約。
一位設計師的可約時間不等於沙龍的營業時間。休假日、午休、兼職班次、以及被占用的教育訓練時段，每個人都各不相同。可約時段引擎必須讀取每位設計師自己的行程，而絕不能只看營業時間，否則你賣出去的會是根本不存在的時段。
爽約和訂金規則處處是鋒利的邊界：提前 26 小時改約應當保留訂金，同樣是改約但只提前 2 小時就應當沒收訂金；退款有時是部分退，而扣卡也會失敗。一定要把規則的時間點（通常是 24 或 48 小時的窗口）以及「改約」與「取消」的區別拿捏準，否則你會因為一次合情合理的更動而扣了一位忠實老顧客的錢，然後悄無聲息地失去他。

✓ 先做這些

一個按設計師區分的品牌化預約頁面，具備即時的、能感知服務時長的可約時段，並在結帳時即時鎖定時段。
在預約時收取訂金並留存信用卡，讓爽約和臨時取消真正變得可以執行。
透過簡訊和 Email 發送自動確認，外加一則提前 24 小時的提醒，以降低爽約率。

— 先別做

完整的零售 POS 收銀和產品庫存管理：v1 階段先繼續用現有的收銀機，結帳時只做產品記錄即可。
點數、會員制和預付套餐的追蹤：等預約和訂金這一塊穩固之後再加。
薪資發放、抽成結算和多門市彙總：現在先把 commission_rate 欄位建好，薪資單的自動化留到以後。

常見問題

顧客可以自己預約、而不用打電話到店裡嗎？

可以。你的預約頁面全天候運行在你自己的網域上，這一點很關鍵，因為將近一半的沙龍預約都發生在營業時間之外。顧客自己選好服務、設計師和時間，支付訂金，隨即拿到一則即時確認，全程無需碰一下電話。

它是怎麼防止同一張椅子被重複預約的？

每一個時段都會對照即時可約狀況進行核對，並在結帳一開始的那一刻就被鎖定，因此兩個人不可能搶到同一個時間。同時它依然支援染髮顯色期間那種刻意為之的時間重疊，因為那個空檔被建模成可再利用，而不是被封死。

我可以收訂金、並對爽約收費嗎？

可以。預約時收取並留存一張信用卡。當顧客爽約、或在你的規則窗口內取消時，費用會被自動扣取；而當顧客如約到店時，訂金則會折抵進最終帳單。

每位設計師可以有自己的服務項目、工作時間和價格嗎？

可以。服務項目、時長、價格、工作時間和休假日都按設計師逐一設定，資歷淺的和資深的可以用不同的時長和價位提供同一項服務。可約時段引擎會讀取每個人自己的行程。

散客、電話預約和我自己的品牌又怎麼處理？

櫃檯只需點幾下，就能把散客和電話預約直接加到同一本美髮椅日曆上，於是所有管道都匯集在一處、彼此絕不重複預約；而在顧客還在電話那頭時，顧客檔案、配方備註和爽約歷史就都擺在眼前。又因為這個應用託管在 ybuild 上、透過你自己的網域對外提供服務，預約頁面掛的是你的名字，而不是某個平台的名字，那份顧客名單也是你自己的資料。

參考來源

沙龍產業統計、趨勢與基準數據 — 約 46% 的預約發生在營業時間之外，且透過線上預約的初次顧客回頭頻率約為散客的 2 倍——這正是打造一個全天候自助預約頁面的理由。
如何公平地執行取消與爽約收費（Zenoti） — 關於固定金額收費與百分比收費之別、預先綁定信用卡、以及公示你的規則的實用指引，對設計訂金與爽約邏輯很有幫助。
如何避免預約重複撞期（Acuity Scheduling） — 一份關於緩衝時間與即時可約狀況的最佳實踐指南，為可約時段引擎和分設計師日曆提供參考。

為你的生意打造這套系統

描述它，一次上線到你自己的網域——託管、全端、免伺服器。免費開始。

免費開始打造 →