如何建立預約 App：時段、可預約時間、提醒與訂金

要建立預約 App，你需要四個環節協同運作：可預約項目的清單（服務、房間、人員）、每個項目何時可用的規則、只提供真正空閒時段的預約流程，以及讓店家管理預約的私人檢視。AI App 建置工具能根據一段簡短描述，在幾分鐘內產出可用的第一版；真正的工作在於決定規則——時段長度、緩衝時間、取消政策、時區——並測試重複預約是否確實不可能發生。

先決定「預約」對你來說是什麼

預約 App 表面上看起來很像，但底層差異很大。先回答這些問題：

• 預約的是什麼？ 服務（例如剪髮）、人員（例如家教）、資源（例如會議室、球場、廂型車），或是課程中的某個名額（例如一堂有 12 個名額的瑜伽課）。
• 需要多長時間？ 每項服務固定時長，還是由客戶自行選擇？
• 誰來提供服務？ 一位人員、多位各自有工作時間的人員，還是沒有人員（例如一間房間）？
• 預約後會發生什麼？ 立即確認，還是由店家審核的申請？
• 有涉及金錢嗎？ 免費、現場付款、先付訂金，還是全額預付？

「請求一個時間，店家會透過電子郵件確認」比「同時對照三位人員的行事曆、支援訂金的即時預約」簡單得多。兩者都是合理的選擇——第一版請挑你真正需要的那一種。

App 需要什麼

資料

在每筆預約中都儲存結束時間，而不只是開始時間，會讓檢查時段是否重疊變得容易得多。

頁面

• 公開頁面：服務列表、時段選擇器、預約表單、確認頁面，以及取消或改期的連結。
• 私人頁面（店家或人員）：今日行程、即將到來的預約、封鎖休假時間的方式，以及服務與營業時間的設定。

權限

客戶只應看到空閒或已佔用的時段，絕不能看到其他客戶的姓名。人員可能只能看自己的行程，店家則能看到全部。請把這點寫下來，因為它決定你是否需要登入與角色。我們關於為你的 App 加入登入的指南涵蓋了各種選項。

困難的部分，以及如何處理

重複預約

經典的錯誤：兩個人同時載入頁面，兩人都看到 10:00 是空的，然後都預約了它。解法是在伺服器儲存預約的當下再次檢查，若此時有任何時段重疊就拒絕。請明確提出這項要求：

儲存預約時，請在伺服器上重新確認同一位人員沒有任何已確認或待確認的預約與申請時間重疊（包含緩衝時間）。若有，就拒絕並顯示「該時段剛被預約，請選擇其他時間」。

然後用兩個瀏覽器視窗實際測試。

時區

所有時間都以 UTC 儲存，顯示時再轉換。請決定預約頁面要顯示誰的時區——實體服務通常是店家的時區，線上通話通常是客戶的時區——並在頁面上標示清楚。也要測試跨越夏令時間切換日的預約。

緩衝、提前通知與上限

常見而值得事先決定的規則包括：預約之間的緩衝時間、最短提前通知（「預約需至少提前 2 小時」）、可提前預約多遠，以及每日上限。每條規則在提示詞中只需一句話；若省略，AI 就會替你選擇預設值。

取消與未到場

每封確認信都應附上帶有唯一權杖的取消連結，讓客戶不需要帳號。請決定取消的時間範圍，以及訂金是否可退，並在付款前就把這項政策顯示出來。

提醒

提醒電子郵件或簡訊需要有能按排程執行的機制（「每 15 分鐘執行一次，寄送 24 小時內開始的預約提醒」）。請確認你的建置工具與主機如何處理排程工作。如果不支援，就使用外部排程器呼叫 App 中的端點，或在確認信中附上行事曆邀請，讓客戶自己的行事曆來提醒。寄信的服務商端設定，請參閱如何從你的 App 寄送電子郵件。

訂金與付款

使用 Stripe 的常見模式如下：

1. 客戶選擇時段；App 建立一筆待確認的預約，暫時保留該時段（例如 15 分鐘）。
2. App 把客戶導向 Stripe Checkout 支付訂金。
3. 付款成功時，Stripe 透過 webhook 通知你的 App；預約變為已確認。
4. 若未在時限內付款，待確認的預約就會過期，時段隨即釋出。

截至 2026 年 9 月，Stripe 的標準收費是每筆成功刷卡付款的百分比加固定手續費，沒有月費；各國費率不同，請查看 Stripe 針對你所在國家的定價頁面。在所有功能都正常運作之前，請使用測試模式與測試卡。我們的加入付款功能指南有逐步說明。

一個有效的首次提示詞

為 Northside Barbers 建立一個預約 App。服務項目：剪髮（30 分鐘，$25）、修鬍子（15 分鐘，$12）、剪髮加修鬍子（45 分鐘，$32）。兩位理髮師 Sam 與 Ali，各自週二至週六 9:00–18:00 工作。客戶先選服務，再選理髮師或「任一位理髮師」，然後只看到未來 14 天內空閒的 15 分鐘開始時間，並輸入姓名、電話與電子郵件。預約存入資料庫，每筆預約後保留 10 分鐘緩衝，並在儲存時重新檢查可用性以防止重複預約。顯示附有取消連結的確認頁面。店家有一個私人頁面，列出今日與即將到來的預約，可以取消預約，也能封鎖時段。時間以店家所在的當地時區為準。乾淨、以手機為優先的設計。

這段提示詞列出了服務、人員、時段、規則與店家的檢視方式——也就是 AI 否則只能猜測的所有內容。

建置步驟

1. 先做核心預約流程。 服務 → 時段 → 表單 → 儲存預約 → 確認。在手機上能順利運作之前，不要做其他任何事。
2. 店家檢視。 今日列表、即將到來的列表、取消、封鎖時間。
3. 保護店家頁面。 在真正的資料進入之前加入登入。
4. 規則。 緩衝時間、提前通知期限、可預約的最遠日期、假日。
5. 電子郵件。 附有行事曆邀請與取消連結的確認信。
6. 需要時加入訂金，先在 Stripe 測試模式中完成。
7. 測試邊緣情況。 兩個視窗預約同一時段、跨午夜的預約、夏令時間變換日、已取消的預約是否釋出時段。
8. 發佈，然後在分享連結前自己完成一筆真實預約。

常見錯誤

• 只在瀏覽器中檢查可預約狀態。 畫面看起來正確，但仍會重複預約。
• 儲存本地時間卻沒有時區。 在時鐘變更之前都沒問題，之後就出錯。
• 在公開行事曆中顯示客戶姓名。 只應顯示空閒或已佔用。
• 第一天就做人員排班、積分與簡訊。 先上線核心流程，再加入客戶真正會要求的功能。
• 店家無法封鎖時間。 第一次有人員請病假，就會產生無人到場的預約。

什麼時候 Calendly（或類似工具）是更好的選擇

如果你只是一個人，想分享自己的可預約時間來進行通話，排程工具很難被超越。截至 2026 年 9 月，Calendly 的免費方案包含一種活動類型、一個行事曆連線，以及可自訂預約頁面的一對一排程；付費方案則增加更多活動類型與團隊功能。這類工具開箱即可連接你現有的行事曆，而自建的 App 必須特別開發才能做到。

當你需要這些工具不支援的規則、多個可預約的資源、全程自有品牌，或預約要與其他資料（客戶、訂單、會員資格）相連，或你要打造一個銷售給他人的預約產品時，就應該自己建置。

用 Mythex 建置

在 Mythex 中，你在對話中描述預約 App，它會在即時預覽中建置出來；當需要儲存預約時，會加入 Postgres 資料庫。預約頁面使用案例文件建議先從預約表單與管理列表開始，再逐步加入其他功能。也要清楚區分哪些是內建的、哪些需要你自己接上：Mythex 沒有內建的行事曆同步、簡訊提醒或訂金產品。電子郵件透過你自己的服務商發送，訂金則透過你儲存為專案祕密資訊的 Stripe 金鑰處理（Stripe 作法）；而重複預約與時區的規則，則是你需要像上文所述那樣指定並測試的內容。

/test 指令可以讓代理在預覽中點擊完整的預約流程，並回報哪裡會出錯。若要起始提示詞，可以試試理髮店預約網站或會議預約器範本，或瀏覽所有App 範本。

常見問題