WordPress 線上預約系統架設：Amelia 外掛指南

預約失控，本質上不是客人難搞，而是你還在用 LINE 訊息加行事曆手動拼湊接單流程。客人用 LINE 跟你約週三下午三點，半小時後又傳訊改到四點，當天沒出現你才發現行事曆根本沒同步，晚上打烊還要手動把今天的預約一筆一筆抄進 Google Calendar。把這件事做了一年你會發現，你不是在做生意，你是在當一個低薪的排程工讀生。

這篇要解的，就是把這整套「客人預約、你確認、系統自動排好、通知發出去、錢收進來、行事曆同步」的流程，交給一個不會累、不會漏、不會把九號跟十號搞錯的數位櫃檯。這裡以 Amelia 這套 WordPress 預約外掛當主引擎，帶你從「先搞清楚你要哪種預約」一路走到「上線之後每天怎麼管理預約」。如果你還在通盤規劃整站該裝哪些外掛，可以先看 WordPress 必裝外掛清單。

先講結論：Amelia 是一套服務導向的 WordPress 預約系統外掛，核心是「服務＋員工＋地點＋營業時間」四個物件。先把這四個物件想清楚，再裝外掛、嵌表單、接通知、收款、追蹤轉換，你的線上預約就能 24 小時自己跑。如果你要的是「從零把整個預約網站（主題、首頁、關於我們）架起來」，看預約網站架設全攻略；這篇聚焦在預約系統本身的設定與日常營運。

先問對問題：你要的是服務型、活動型、還是套餐型預約

預約型網站常見的第一個誤區，是十個有七個一開始就想錯方向。直覺上認為「預約就是預約」，裝了外掛就開始建服務，結果做到一半才發現：要的是一班二十人的瑜珈課，可是外掛預設是一對一的服務；要的是「任選三堂的套票」，可是外掛只能賣單堂。

預約系統不是一種東西，是三種東西共用一個名字。先對應你是哪一種，後面的設定才不會走冤枉路。

預約模式	適合場景	Amelia 對應功能
服務型（一對一時段）	美容、髮型、診所、諮詢、家教	Service（Appointment）
活動型（固定時段、名額有限）	瑜珈團課、工作坊、體驗課程	Event
套餐型（多堂組合、可分次使用）	課程套票、堂數卡	Package（依當期付費方案）

這裡的關鍵判斷是「時間是不是你賣的核心」。服務型賣的是「某個人在某個時段為你服務」，所以每一個時段只能給一組客人；活動型賣的是「一個名額」，同一個時段可以塞很多人；套餐型賣的是「一段可分次使用的權利」，跟單次時段脫鉤。三者的庫存邏輯完全不同，選錯了後面的行事曆、付款、退款規則全部要重來。

還有一種藏在灰色地帶的混合型態：同一間店同時賣服務與活動。例如一間皮拉提斯工作室，一對一的私人課是服務型，五人小班課是活動型，十堂套票是套餐型，三者在同一個網站上並存。Amelia 允許你把這三種模式同時架在同一套系統裡，但前提是你前面那張表要先分清楚哪一個項目屬於哪一種，別全部當成服務來建。實務上的經驗法則是：如果你不確定，先從服務型開始跑通，等流程順了再加活動或套餐，一次只多加一種業態，排查問題時才不會亂。

Amelia 適合處理哪些 WordPress 預約需求

Amelia 採步驟式預約流程，後台以「服務／員工／地點／營業時間」整理資料，也提供行事曆與 WooCommerce 等整合。這些功能是否可用、支援到哪個層級，會依外掛版本與當期方案而異，上線前要用官方功能表逐項核對。

免費版可用來驗證基本預約流程；活動、套餐、訂金、付款、行事曆與通知等進階能力的方案邊界可能調整，也不再只是「免費／Pro」兩級。先列出必要功能，再對照官方當期方案；若基本流程能用免費版驗證，可先跑通一個服務再購買授權。

如果要比較其他預約架構，也可參考WordPress 預約外掛比較；這篇聚焦 Amelia 的設定邏輯。

安裝前一定要先做好的三件事

太多人裝預約外掛的第一個動作是去後台搜尋、點安裝、啟用，然後隔天發現預約通知信全部進了垃圾郵件匣，客人根本沒收到確認。這不是外掛的鍋，是你跳過了前置作業。這三件事是「裝 Amelia 之前絕對不能省」的清單。

第一，幫網站裝好可靠的 SMTP 寄信通道

WordPress 的 wp_mail() 是否能可靠送達，取決於主機與寄信服務設定，不能只看畫面顯示「已寄出」。依WordPress SMTP 設定教學接上具備 SPF、DKIM 等驗證的寄信通道，測試不同信箱供應商，並監看退信與寄送紀錄，再把通知流程交給系統。

第二，裝外掛前先做一次完整備份

預約外掛會建立資料表並寫入營運資料，安裝或大幅改版前要確認最近的檔案與資料庫備份成功、能獨立取回，並知道還原會覆蓋哪些新預約。可參考 WordPress 備份流程，高風險變更則先在 staging 驗證。

第三，把固定網址與時區設正確

可讀的永久連結方便管理與分享，但 WordPress 預設參數網址本身不會讓 Amelia 預約必然失效。既有網站若要改網址結構，要先規劃 301。時區則到設定 → 一般，選擇營業所在地的城市時區（例如 Asia/Taipei），再測試日光節約時間、跨日服務與員工個別時區的顯示。

這三件事做完，再進到後台外掛 → 安裝外掛，搜尋 Amelia 安裝啟用。完整的安裝流程可以對照WordPress 外掛安裝教學。

若主機提供 staging，可先在測試站跑通完整預約流程並檢查外掛衝突。不要直接把測試站的整份資料庫推回已開始收單的正式站，否則可能覆蓋新預約；應記錄並部署已驗證的設定變更。沒有測試環境時，安排維護時段並準備已驗證的備份與回復步驟。

用四個核心物件建立你的預約資料模型

這一節是整篇文章最關鍵的部分，因為它決定你後面所有設定的順序與彈性。Amelia 的設計哲學是把一間店的預約邏輯拆成四個獨立但互相牽動的物件，你只要把這四個物件想清楚，設定介面點起來會非常有條理。

物件	它代表什麼	設定時要想清楚的事
服務（Service）	你賣的預約項目	時長、價格、可預約的人、是否允許多人同時段、緩衝時間
員工（Employee）	實際提供服務的人	對應哪些服務、各自的上班時段、休假日
地點（Location）	服務發生的實體或線上位置	多分館、到府服務、線上會議連結
營業時間（Working Hours）	每個員工可被預約的時段	配合服務時長自動產生的時段、午休、特殊營業日

一個常見的誤解是「營業時間等於店開門的時間」。在 Amelia 裡，營業時間是綁在員工身上的，不是綁在店面身上的。意思是：你的店週一到週日都開，但設計師小美只上班週二到週六，那麼客人在預約時，Amelia 會根據小美的上班時段自動算出可預約的時段，不會拿店開門的時間來充數。

設定順序建議如下：先把服務建好（先想清楚你賣什麼），再把員工建好並指派服務（誰來做），接著設定地點（在哪做），然後才處理每個員工的營業時間與休假日（什麼時候做）。這個順序的好處是，當你之後新增一個服務或一個員工時，只需要在對應的物件裡動，不會牽一髮動全身。

還有兩個容易被忘記的欄位務必一開始就想清楚：緩衝時間（buffer time）是服務前後的預留時間，例如染髮前後要留清潔時間；允許多人同時段（capacity）決定這是一對一還是一對多的時段。這兩個欄位直接影響客人能看到的時段數量，設定錯了要回頭改，會連帶影響已經成立的舊預約。

這裡再補充一個容易踩的坑：capacity 與員工數量的交互作用。當一個服務的 capacity 設成大於一，表示這個時段可以同時接待多名客人，這在活動型預約很正常；但如果你把一對一的服務誤設成 capacity 二，就會出現同一個時段被兩組客人同時預約、而員工只有一個人的窘境。判斷原則是：capacity 永遠不能超過同一時段實際提供服務的人數，除非你的服務本質上就是團體進行。設定完之後，自己用測試帳號預約一次、再約一次，看系統是否正確擋下第二筆，是最快的驗證方式。

把預約表單嵌進你的網站版面

資料模型建好之後，接下來是把「讓客人預約」的介面放進你的網站。Amelia 提供三條嵌入路線，差別在於你用什麼方式構築網站頁面。

路線一：短代碼（shortcode）

最直接、相容性最高。在 Amelia 後台為你要開放預約的服務產生一段短代碼（形如 [ameliabooking service=1]），貼到任何支援區塊編輯的頁面或文章裡即可。如果你用的是傳統編輯器或自訂文章類型，這是最保險的做法。

路線二：Gutenberg 區塊

WordPress 內建區塊編輯器的話，Amelia 提供了對應的預約區塊，直接在區塊選擇器裡插入，省去記短代碼參數的麻煩。對純內容頁來說這條路最順手。

路線三：頁面編輯器元件

若使用 Amelia 支援的頁面編輯器，可以透過對應元件插入預約表單；可用元件與篩選參數依版本而異。若流程需要收集客製欄位，先確認資料會存在哪裡、誰能存取、保留多久，並只要求完成預約所必要的資訊。

無論走哪條路，嵌入後都要用未登入的瀏覽器與手機實際走一次完整預約。你自己覺得順不代表客人覺得順，尤其要檢查步驟切換時的載入感，以及送出後「預約完成」的回饋是否清楚。模板再漂亮，客人卡在流程中離開仍無法完成預約。

讓預約流程自動跑：通知、提醒、日曆雙向同步

表單能收預約，只是起點。真正省下你時間的，是這套系統在預約成立之後自動做的事。

通知常見節點包括預約成立、提醒、取消、改期與付款狀態。可用管道、範本與排程彈性依 Amelia 當期方案而異；提醒時間也沒有所有業態通用的固定答案。設定後要確認 WordPress 排程能按時執行，並以測試預約驗證客人與員工收到的內容一致。

但通知信能不能準時寄達，回到前面那條 SMTP 通道。沒有可靠的寄件通道，通知系統形同虛設，這是上線前一定要先驗證的單點故障。

通知信的內容要寫什麼

很多人把通知信維持在系統預設的英文範本就上線，這是另一個常見的放棄點。一封會讓客人安心的確認信，至少要包含四個訊息：預約的服務名稱與時段、地點或線上會議連結、取消或改期的按鈕連結、以及遇到問題怎麼聯絡你。其中取消連結是最關鍵的，因為它讓想改時間的客人可以自己處理，不需要打電話或傳訊息找你，這一個連結能幫你吸收掉大量的人工客服。

若方案與所在地支援，也可加入簡訊提醒。簡訊通常要透過第三方服務計費，還涉及電話號碼、同意與退訂管理；先量測 email 提醒與實際未到率，再評估是否需要增加這個管道。

Amelia 可把網站預約建立到支援的外部行事曆，並可依設定將外部忙碌時段排除在可預約範圍外。這不代表任何一端的所有編輯都會即時、完整地回寫成另一端的預約；同步方向、延遲、重複事件與刪除行為都要依所用行事曆、方案與官方文件實測。

收款設定：線上刷卡、現場付款、WooCommerce 整合

要不要在預約當下收款，是商業與風險決策。全額預付、訂金或現場付款各有轉換、退款、爭議與未到風險，不能假設某一種一定較好。Amelia 的訂金與線上付款屬方案功能，採用前要核對目前方案、金流可用地區與退款流程。

Amelia 可支援多種線上付款閘道與現場付款，但可用項目依方案、地區、幣別與帳戶資格而異。若要把預約與購物車、稅務或其他商品共用結帳，可評估 WooCommerce 整合；它會增加訂單狀態對應與相容性測試，不一定是每個單純預約站的最短路徑。

WooCommerce 是 W3Techs 追蹤的主流電商系統之一（2026 年 6 月）。整合後可沿用 WooCommerce 的訂單與相容金流，但發票、退款與狀態同步仍取決於個別外掛。可先看WooCommerce 開店設定教學與WooCommerce 金流物流設定。

訂金可用來分擔未到風險，但比例與取消期限沒有通用數字。應依服務成本、消費者保護規範、金流費用與實際數據設計，並在付款前清楚揭露取消、改期與退款條件；必要時請在地法律或會計專業人士確認。

台灣的金流與發票是綁在一起的另一層課題。如果你走 WooCommerce 收款，可以透過綠界 ECPay 金流串接同時處理線上刷卡與電子發票開立，把預約收款、發票、對帳收進一條流程裡，省下三條線各自維護、互相對不上的麻煩。結帳頁本身的欄位也要回頭檢視，預約型交易的結帳不需要實體物流欄位，可以對照WooCommerce 結帳頁客製化把不需要的欄位拿掉，讓結帳更短更順。

手機預約為什麼才是真正的決戰點

根據 Statista 的統計（2026 年 4 月），全球網頁流量有相當比例來自行動裝置，但你的預約裝置占比仍要看自己的分析資料。無論目前比例如何，手機版都應走完實際的預約、付款、改期與取消測試。

這代表你嵌入的預約表單，必須在手機上做到三件事：步驟之間的切換不卡頓、可點選的時段按鈕夠大不會誤觸、輸入電話與姓名時自動帶出對應的鍵盤類型。Amelia 的步驟式預約介面在手機上的表現是它的主要賣點之一，但這不代表你可以裝完就不管。請務必用自己的手機走一次完整流程，特別注意橫向捲動、字級、以及小螢幕下時段格的可點擊範圍。

另一個手機場景的隱藏成本是表單欄位數量。每多一個必填欄位，在手機上的放棄率就會上升。實務上的原則是：能用預設值帶入的就別問、能在後台補的資料就別在預約時問。預約表單只留三件事：聯絡方式、要約的服務與時段、（如果要收錢）付款資訊。其他你想知道的（例如怎麼知道我們的、是否有特殊需求），放進選填欄位就好。這個原則也適用於你網站上所有引導詢問的表單，愈短愈好。

手機預約送出後的確認頁，是另一個容易被漏掉的關鍵畫面。這個畫面要在第一眼就讓客人確定「我約成功了」，清楚顯示時段、地點、以及接下來會收到一封確認信。很多預約流失不是發生在填表過程，而是發生在送出後畫面沒有明確回饋，客人不確定到底約成功沒有，於是再約一次造成重複預約，或直接離開以為沒約成。一個做得好的確認頁會把取消與改期的連結也放上去，讓客人在這個當下就能把約會加進自己的手機行事曆，等於把這筆預約釘進客人的記憶裡，No-show 機率也會跟著下降。

上線後的日常：改時間、取消、No-show、退款

到這裡你的系統已經會自己收預約了，但「會收預約」跟「會管預約」是兩回事。上線之後，你每天要做的是管理已經進來的預約，而這部分的外掛操作直接決定你的客訴量。

Amelia 的後台提供月、週、日三種行事曆檢視，可以在任何一個檢視裡直接把預約拖到別的時段來改時間，系統會自動寄改期通知給客人。取消預約時，你可以設定是否要返還已收的款項、是否要把那個時段釋放回可預約池。這些操作看似直覺，重點在於你事前有沒有把規則定清楚。

有三條規則建議在正式對外開放預約之前就寫進你的服務條款，並在 Amelia 的對應設定裡落實：

• 取消政策：例如「預約時段 24 小時前免費取消，之後沒到不退款」。Amelia 可以設定最晚取消時間，過了就鎖定。
• 改期政策：允許客人在幾小時前自己從信件連結改期，過了就只能聯絡店家。這能幫你省下大量的人工改期工。
• No-show 處理：客人沒出現時，員工可以在後台把這筆預約標記為 No-show，方便後續追蹤與累計，作為下次是否接受預約的判斷依據。

退款流程依付款閘道與 Amelia 整合方式而異：部分情況可從系統發起，另一些仍要到金流或 WooCommerce 訂單操作。無論從哪裡執行，都要核對金流交易、訂單與預約狀態，並保存退款結果，不能只改畫面上的預約狀態。

員工權限是這一節容易被疏忽的一環。多數店會希望第一線員工（例如設計師、老師）能看到自己的預約、但不能改店家的收款設定或服務價格。這件事要回到 WordPress 的角色權限系統來處理，可以對照WordPress 使用者角色與權限的設定方式，把員工帳號限制在只能管理自己預約的範圍，避免有人誤改了全局設定。

還有一個上線前要決定的開關：預約是自動確認還是人工審核。自動確認的好處是 24 小時都能成交、客人體驗最順，適合時段充足、不太需要把關的服務；人工審核則適合名額稀缺或需要先確認客戶條件的服務（例如付費諮詢、客製化課程）。Amelia 可以在每個服務上單獨設定這個開關，建議初期先用人工審核跑一兩週，觀察實際的預約樣態與常見問題，再決定哪些服務可以放寬成自動確認。這個開關一旦切換，客人收到的通知信內容也要跟著調整，否則會出現「系統已經自動確認、信裡卻還寫著我們將盡快與您聯繫」的矛盾訊息，反而讓客人困惑。

效能地雷：快取、AJAX 與主機資源

預約頁面可以快取靜態外框，但可用時段與提交結果必須從即時端點取得，不能讓頁面快取、CDN 或代理錯誤快取個人化或動態回應。是否要排除整頁，要依 Amelia 與所用快取工具的官方相容設定和實測決定。

Google 在 web.dev 的文件裡反覆強調，頁面載入速度直接影響使用者是否會留下、是否會完成轉換。但「快」跟「即時」在預約系統裡是兩件互相拉扯的事：你要回應快，但又不能把即時資料快取起來。解法不是不快取，而是「選擇性快取」。

實務上先依官方建議設定快取排除，並用無痕視窗同時提交兩筆競爭時段，確認伺服器仍會在送出時再次驗證庫存。接著用壓力測試或尖峰紀錄觀察動態請求，而不是預設某個主機規格就足夠；可參考WordPress 快取外掛比較、WordPress 主機選擇與網站效能優化。

資料庫與物件快取的連動

物件快取是否能改善 Amelia 查詢、以及哪些資料鍵可安全快取，取決於外掛實作與主機環境，不能只因為啟用了 Redis 或 Memcached 就假設會更快。依 Amelia 與快取工具文件設定，在 staging 比較啟用前後的動態請求時間，並測試庫存、改期與取消是否即時更新；若出現過期時段，就回退相關快取層。

把預約當轉換追蹤，用 GA4 看見漏斗

預約系統上線後，你會想知道：進入預約表單的人，有多少真的完成預約？這個數字就是預約轉換率，而要拿到它，需要把預約完成事件送進 GA4。

Amelia 可依版本與設定透過前端事件、callback 或資料層傳出預約狀態，再由 Google Tag Manager 送往 GA4。事件名稱與 payload 不能靠猜，應對照目前官方文件並在瀏覽器除錯工具驗證；完整設定可參考WordPress 的 GTM 與 GA4 設定教學。也要避免把姓名、電話、email 等個資送進分析工具。

一個提醒：轉換追蹤跟優化表單是兩個層次的事。追蹤是讓你看見問題，把欄位改少、把文案改清楚才是解決問題。不要裝完 GA4 就以為沒事了，數字給你方向，動手做的還是你。

具體要追蹤哪些事件，取決於你的預約流程有幾個步驟。最基本的組合是三個：進入預約表單頁（漏斗起點）、選定服務與時段（意圖訊號）、完成預約（轉換）。把這三個事件串起來看，你就能算出每一步的放棄率，知道客人是卡在選時段還是卡在填資料。如果你收線上款，再加一個付款完成的事件，把「預約成立」與「實際收款」兩個數字分開看，兩者之間的落差往往就是你漏掉的營收，也是最有價值的優化線索。

Amelia 中文化與多語系的現實

Amelia 的後台與前端介面預設是英文，要呈現給台灣客人看之前必須中文化。免費的做法是透過翻譯檔（.po/.mo）覆寫字串，Loco Translate 是 WordPress 上最穩定的翻譯外掛之一，可以直接在後台編輯 Amelia 的語言檔，不需要改程式碼。

但有兩個地方光靠翻譯檔搞不定。第一是日期與時間格式，Amelia 的時段顯示格式有自己的設定欄位，要再進到 Amelia 的通用設定裡調成 24 小時制與中文日期格式。第二是付款頁面上的金額顯示與幣別符號，這牽涉到 WooCommerce 或金流本身的設定，不是 Amelia 單獨能控制。

如果你同時要經營中文與英文客人（例如服務外籍客戶的診所或工作室），那麼你需要的是完整的多語系方案，單純翻譯並不夠用，這會牽涉到多語系外掛與 Amelia 的相容性測試，建議上線前先在一個測試環境跑通，不要直接在正式站上賭。

三個產業的配置範例：美容 SPA、瑜珈教室、家教老師

抽象的設定講完了，用三個常見產業把整個流程串一次，你會更具體地看到「服務／員工／地點／營業時間」這四個物件在不同業態裡長什麼樣子。

產業	預約模式	核心設定重點	建議收款方式
美容 SPA	服務型（一對一）	不同療程不同時長、設計師對應不同服務、緩衝時間留清潔	線上訂金＋現場尾款
瑜珈教室	活動型（一對多名額）	團課名額上限、月卡套票、教室容量限制	月卡或堂數套票
家教老師	服務型＋套餐型	一對一時段、學生可買十堂套票分次預約	套票預付

美容 SPA 的重點在「緩衝時間」與「員工對應服務」。每一位美容師會的療程不同、每一個療程需要的準備與收尾時間也不同，這兩個欄位設定正確，客人看到的時段才會是真實可執行的，不會發生「約了卻發現美容師根本沒空準備」的尷尬。

瑜珈教室的重點是「活動型預約」與「名額管理」。一堂二十人的團課可建立為 Event，每筆預約占用名額，額滿後停止接受。月卡或堂數卡則要核對當期方案是否包含 Package，以及到期、退款與剩餘堂數規則。整體版面可參考瑜珈網站設計範例，但預約流程仍以可用性與手機實測為準。

家教老師的重點是「服務型與套餐型的混合」。學生可以先買一組十堂的套票，之後每次自己在系統裡約時間，每約一次扣一堂。這個模式同時解決了「預約」與「庫存（剩幾堂）」兩件事，是在地教育與諮詢服務很常見的業態。如果你經營的是更完整的線上教學平台，線上教學平台架設指南會是更對口的資源。

順帶提一個邊界案例：餐廳訂位。Amelia 不是為餐廳設計的，因為餐廳訂位牽涉到桌位組合與翻桌率的邏輯，跟單純的服務預約不同。但小型餐廳的時段訂位可以用活動型預約來近似，搭配餐廳網站設計教學一起規劃會更完整。大型連鎖或複雜訂位需求，還是建議走專門的餐廳訂位系統。

這三個產業加上餐廳，共同點是它們賣的都不是商品，而是「某個人在某個時段的服務或名額」。這類服務型業態導入預約系統的效益最明顯，因為手動排程的成本最高、出錯的代價（客人白跑一趟、員工空等）也最大。如果你的業態接近這幾種，可以直接套用對應的設定骨架；如果是更特殊的業態（例如到府服務的多技師調度、場地分時租賃），核心思路一樣是回到那四個物件，先把「賣什麼、誰做、在哪、什麼時候」拆清楚，Amelia 的設定介面就能跟著展開，剩下的是細節微調，不必重新設計一套流程。

你的下一步行動方案

讀完不等於做完。接下來這六個步驟，是你把這篇文章變成實際能收預約的系統的最短路徑。

1. 決定你的預約模式：對照前面那張表，寫下你是服務型、活動型還是套餐型，這個答案會決定後面全部的設定走向。
2. 把四個物件畫在一張紙上：服務有哪些、誰來做、在哪做、什麼時段可做。這張紙就是你之後在 Amelia 後台設定的藍圖。
3. 完成前置檢查：驗證寄信通道、確認可還原備份與時區；永久連結若需變更，先規劃重新導向。
4. 安裝 Amelia 免費版跑通一個服務：先別買 Pro，先確認流程在你的網站上能完整走完一次。
5. 用自己的手機實測一次完整預約：從客人視角走完，記下任何卡頓或不清楚的步驟。
6. 決定收款策略與取消政策，再對外開放：把規則寫進服務條款，也寫進 Amelia 的對應設定，然後才正式上線。

把預約系統當成你店裡第二個不睡覺的櫃檯來經營，它回報你的會是更多能專注在專業本業上的時間。這套東西不會一夜完美，但每修一個卡頓點，你的預約轉換率就會往上一階。

如果你在挑主機、規劃多語系、或把預約跟 WooCommerce 購物車串起來這幾件事上需要更具體的協助，Whoops SEO 提供 WordPress 網站架設與轉換優化的顧問服務。你照著上面的步驟自己跑也完全沒問題。