Hi everyone,
I’m exploring opportunities to use n8n to automate processes in the hotel industry. I have a background in hospitality and I’m deeply impressed by what n8n can do.
I’m trying to find existing workflows or build new ones specifically for hotel operations, but I’m having trouble finding a direct “hotel” template. I believe hotel operations can be broken down into categories like Support, Marketing, and Sales.
I’d be incredibly grateful if the community could share some ideas, examples, or even existing workflows for the following use cases:
Guest Experience & Support:
- Pre-Arrival: Sending a welcome email 1-2 days before check-in with details about their stay.
- Post-Stay: Automatically sending a “Thank You” email after check-out with a link to leave a review on Google/TripAdvisor.
- Guest Requests: Creating a simple system to handle guest requests coming from WhatsApp or email and notifying the front desk.
Sales & Marketing:
- Syncing new booking details from a booking engine/channel manager (via webhook or API) to a Google Sheet for daily reporting.
- Adding guest emails to a marketing list (e.g., Mailchimp) for newsletters.
Operations:
- Generating a daily “Arrivals & Departures” list and sending it to the housekeeping and front desk teams via email or Telegram.
Has anyone here built something similar or have any pointers on which nodes or workflows would be best to start with for these tasks?
Any help or guidance would be highly appreciated!
Thank you!
Thanks for all the suggestions! I’ve actually started building some of these workflows and wanted to share my progress.
I’ve got the pre-arrival welcome email automation working great - it runs every 6 hours and checks for guests arriving in 1-2 days. The email template includes all the key info like WiFi details, breakfast hours, and contact information.
Also built out the post-stay review request system that triggers 24-48 hours after checkout. It automatically sends thank you emails with Google Reviews and TripAdvisor links, plus a return guest discount code.
The daily operations report is probably my favorite - it generates a clean summary of arrivals/departures and sends it to housekeeping and front desk staff each morning. Really helps with coordination.
Similarly instead sending to Email, we can simply send to the whatsapp or telegram of staff
I have shared the workflow with community , I hope this helps.
You can find Workflow here,
Hi @Gaurav,
Thank you so much for your incredibly detailed suggestions and workflow ideas! This is exactly what I needed and it gives me a very clear path forward.
My apologies for the delayed response.
Your advice on the pre-arrival email, the post-stay email with a TripAdvisor link, and the daily operational report for the staff is brilliant. I will start working on implementing these automations based on your recommendations.
Thanks again for your great help!
嘿 NAJA，酒店業 + n8n 真的很搭配，老實說你列出的大部分東西只是核心節點串在一起。沒什麼特別的。
如果我要開始，我會在處理任何客人郵件之前先做一件事：建立一個流程來抓取每一筆新的訂單，然後丟進 Google Sheet。如果你的訂票引擎或頻道管理器可以在新訂單時 POST，就用 Webhook 節點；如果不能，就用 Schedule Trigger + HTTP Request 來輪詢 API。用 Set 節點整理一下欄位，然後連到 Sheets。聽起來很無聊，但這是骨幹。一旦你的訂單都在那個 Sheet 裡，其他的東西就只需要從它讀取，而不用整天打 PMS 的 API。
從這裡開始，客人相關的功能就很容易實現了。到達前是一個每日的 Schedule Trigger，讀取 Sheet、篩選明天入住的、然後發送含有你的範本的郵件。退房後感謝信也是同樣的邏輯，只需要篩選昨天退房的，然後加入你的 Google 評論連結。有一個坑要注意：把「welcome_sent」旗標寫回那一列，否則遲早有人會收到兩次同樣的郵件，看起來就很不專業。
WhatsApp/email 客人請求那個才是我真正會用 AI 節點的地方。WhatsApp Business Cloud 觸發器（或 IMAP 處理郵件）→ AI 節點總結他們要什麼 → 傳到 Telegram 或 Slack 給前台，然後記錄到 Sheet。其他地方用 AI 節點都太過度了，但對於雜亂的自由文字請求，它是值得的。
你的 Mailchimp 想法也可以，只要在後面加個選擇加入的檢查。自動把每位客人都加進電子報是快速觸發 GDPR 麻煩的方法。
客人到達和離開時的清潔團隊通知也是同樣的每日 Sheet 模式：篩選今天的入住和退房、用 Code 節點格式化、傳到 Telegram 群組。還有一個小建議，早點加入一個 Error Trigger 工作流 — 否則一個無聲的失敗就會跳過一天的客人，你只有在前台發火時才會發現。
我很樂意詳細走一遍訂單同步流程，因為它會打開其他流程的大門。你的訂單系統是什麼 — 真正的 PMS/頻道管理器，還是只是訂票引擎？這決定了你用 webhook 還是輪詢。
嘿 NAJA，我對歡迎電子郵件自動化有一個想法。
與其每六小時檢查一次新預訂——這可能導致電子郵件在凌晨 4 點被發送——你可以將工作流程安排為每天運行一次，例如在上午 10 點。
你也可以根據預訂期間提供的信息估算客人的時區。例如，以 +34 開頭的電話號碼通常表示西班牙，目前是 GMT+2。基於此，工作流程可以在發送電子郵件前檢查交付時間是否在客人合理的白天時段內。
理想情況下，自動化應在可用時使用客人的國家或地址，因為電話號碼前綴只是一個近似值。然後它可以識別相關預訂，確認歡迎電子郵件尚未被發送，並在適當的當地時間立即發送或延遲發送。
在預訂同步骨幹上——在連接到 Sheets 之前，先檢查 PMS 實際發出的內容。Cloudbeds 和 Mews 有真正的 webhooks；許多較小的系統只給你每晚的 CSV 或 OTA 管道經理源，這會將整個設計從事件驅動翻轉為今天的匯出與昨天的比較。花十分鐘檢查可以省去之後重新建置的麻煩。
延伸上面的時區要點：不要從電話區號估算，要使用飯店的時區。客人是來你這裡旅遊，所以入住前電子郵件重要的是飯店當地時間，而不是客人碰巧從哪裡註冊的時間。我為小型服務型企業建置這些系統，所以如果有幫助的話很樂意提供具體建議。
@colemaffeo6 關於物業時區與客人位置的觀點非常中肯——預到達電子郵件需要根據客人實際抵達你的飯店當地時間來發送！
基於 @NAJA 的設定，飯店自動化中有兩個關鍵的現實邊界案例通常會被忽視，直到上線當天才發現：
### 1. 訂位取消與修改
如果客人透過你的 PMS/OTA 重新安排或取消訂位，簡單的「追加到 Google 工作表」方式會導致原始入住日期保留在你的系統中。結果：已取消的客人會收到「我們期待明天見到你！」的預到達電子郵件。
* **解決方案：** 使用基於 `booking_id` 的 **更新插入操作** 而非簡單追加。如果使用 Google 工作表，先按 `booking_id` 搜尋。如果 `status === ‘CANCELLED’`，標記該列，讓你的日常排程觸發器忽略它。
### 2. Google 工作表 API 速率限制與競爭條件
如果你同時收到多個訂位 webhook 或執行高頻率輪詢，Google 工作表 API 有嚴格的速率限制（每分鐘 60 次寫入），且缺乏原子鎖定。如果 `welcome_sent` 未立即更新，可能會導致重複寄送電子郵件。
* **解決方案：** 對於超過 20-30 間房間的生產環境，考慮使用 **n8n 資料表** 或 **Supabase / Postgres** 作為你的訂位快取狀態，而不是工作表。如果堅持使用工作表，在觸發發送節點前，在程式碼節點中執行快速 `booking_id` 去重複檢查。
### 3. 動態多語言範本
客人說不同的語言。與其硬編碼英文範本：
* 從 PMS 傳遞 `guest_language` 至 **切換節點** （或使用 AI 節點進行範本生成），動態提供正確的 HTML 電子郵件或 WhatsApp 範本，使用他們的母語。
### 
推薦的 4 階段 n8n 架構：
1. **擷取與標準化：** Webhook / 輪詢器 → 程式碼節點（將承載量標準化為統一欄位：`booking_id`、`guest_name`、`check_in`、`language`、`status`）。
2. **狀態管理（更新插入）：** 按 `booking_id` 保存/更新記錄，設定 `welcome_sent = false`。
3. **排程派遣器（例如當地時間上午 10 時）：** 排程觸發器 → 篩選器（`check_in == 明天` AND `status == 已確認` AND `welcome_sent == false`）→ 發送電子郵件 / WhatsApp。
4. **發送後回饋：** 更新 `welcome_sent = true` + 錯誤觸發工作流程，以便在 SMTP/WhatsApp API 失敗時立即通知 Slack/Telegram。
如果你知道你使用的是哪個 PMS / 訂位引擎（例如 Cloudbeds、Mews、Sirvoy 等），我可以分享一個針對其 webhook 模式量身定制的 n8n 工作流程範本！
Upsert 確實是正確的做法，但我會在它上面加一層：在發送時重新檢查狀態，而不只是在調度程序過濾器中檢查。你的上午10點過濾器讀取的是快取行，而在10:04到達的取消仍然會發出去。在發送節點前對PMS進行一次booking_id查詢，每封電郵都要花費一次API調用，這樣就消除了整個「很高興明天見到你」這類已經取消的客人的訊息。OTA頻道也有同樣的問題，它們從不觸發取消webhook，比你預期的要多。每晚重新取取得接下來48小時的入住資訊比起道歉要便宜得多。
在去重方面，順序和機制一樣重要。如果你先發送再設定welcome_sent = true，這兩個步驟之間的任何故障都會在下一次執行時產生重複。先聲稱該行（welcome_sent = 'sending'加上時間戳），然後發送，再標記為已發送。最壞的情況下你會漏掉一封電郵而不是複製一封，而超過一小時的陳舊聲稱很容易清除。對於到前通知，這是你想要的故障模式。
通常在第二週出現的問題：調度程序執行後建立的預訂。客人下午4點預訂明天，上午10點的工作已經執行過，他們什麼都收不到。你需要下午進行第二次執行，或者在建立時有一個分支，當check_in在24小時內時立即發送。
至於語言切換，應該預先翻譯範本，而不是在發送時生成副本。發送路徑中的AI節點是一個可能停滯或在沒有人閱讀之前就悄悄在交易性電郵上搞錯到達時間的節點。
好的想法 @colemaffeo6，特別是關於競態條件和最後一刻預訂的部分。我在執行類似的設置時有一些想法：
關於發送前的 PMS 檢查：在發送迴圈內為每封電郵進行 API 查詢如果要處理 30+ 次入住會很快變得危險。大多數 PMS API 有嚴格的速率限制或較慢的回應時間，所以在迴圈內執行 N 個請求通常會觸發 429 錯誤或導致 n8n 停止。對我們來說更有效的做法是在進行派送前（例如上午 9:55）執行一次性的 delta 擷取，將過去 24 小時內的任何取消/更新以一個批次拉入本機快取。或者如果 PMS 支援的話，就依賴取消 webhook。
關於狀態鎖定（sending 對 sent）：新增三狀態宣告會使資料庫寫入增加一倍，如果你仍在使用 Sheets 或輕量級快取的話會造成影響。在 n8n 中我們通常以本機方式處理：在 Send 節點上設定「失敗時重試」，並連接一個 Error Trigger 子工作流程。如果發送失敗，n8n 會捕捉到錯誤，向 Slack/Telegram 發出警告，並在下次執行時將 welcome_sent 保留為 false。
關於最後一刻預訂：完全同意這個邊界情況，但在建立時立即觸發發送如果有人在凌晨 3 點預訂可能會適得其反。在 webhook 後新增一個快速代碼節點檢查本機時間效果很好——如果時間在上午 8 點到晚上 9 點之間則立即發送，否則將其排入上午 8 點的批次。
而且完全同意在派送期間避免使用 AI 節點。我們只在擷取時使用 AI 來解析原始客人備註或檢測語言，然後將簡單的 guest_language 欄位傳遞到具有預先翻譯範本的 Switch Node。零延遲，零幻覺到達時間的風險。
如果是我的話，我不會一次把所有的東西都建構出來。先讓退房後的評論請求上線。這是你清單上回報率最好的東西，而且說真的只需要半小時的工作：每天早上設置一個 Schedule Trigger，從你的訂單系統中提取那天的退房資訊，然後用 Gmail 或 SMTP node 發送「感謝入住，可以留個評論嗎」的郵件，並附上 Google/TripAdvisor 的連結。建構起來很無聊，但它確實能提升評論數，而評論才是真正推動未來訂單的東西。
抵達前歡迎訊息的工作流程相同，只是日期改成住房日期的前一兩天。所以一旦你建構好了其中一個，基本上就完成了兩個。唯一真正的差異是資料的來源。訂單在 Google Sheet 中？Schedule Trigger 加上日期篩選器，完成。在 PMS 或頻道管理器中？不要輪詢它，使用它的 webhook 讓 n8n 在訂單出現的那一刻立即反應。
客人請求這個我會告訴你不要過度思考。每個人都想在第一天就建構一個完整的工單系統，那太過頭了。一個電郵觸發器（或 WhatsApp/Twilio node）、一個檢查關鍵字的 IF、一條訊息發送到前臺真正在看的 Telegram 或 Slack 頻道。一個單純的共享頻道勝過沒有人維護的聰明資料庫。
抵達和出發訊息給客房部是最簡單的一個：排程執行、提取今天的抵達和出發、Telegram 格式化的清單給團隊。
但是，這些全部的成敗都取決於是否能把乾淨的訂單和房價資料導入 n8n，而那正是會偷偷失敗的一步。如果你最後為此抓取 Airbnb 或 Booking 頁面，每隔幾週當他們改變標記時就會壞掉，而且無聲地壞掉，所以你發現的時候是因為客人沒有收到他們的電郵。在那一步之後用真正的 API 而不是抓取器。
StayingAPI，我用過的那個，直接從 HTTP Request node 以 JSON 形式返回 Booking、Google Hotels、Airbnb 和 Vrbo 的資料，如果你之後想要 AI agent 驅動的話也有 MCP 工具。房價監控是一個不錯的補充，一旦郵件流程穩定下來，結構相同，按排程拉取競爭對手的房價，與你的房價比較，當有人低價競爭時 Slack 提醒。