評價請求電子郵件範本：2026 年 7 個範例

一位咖啡館老闆在繁忙的週六隔天早上傳送了 Google 連結，獲得了三條評論。一家飯店在退房時傳送了相同的電子郵件，卻一無所獲。兩種情況下的文案都沒問題。問題出在觸發條件、時機和目標受眾設定錯誤，而這正是大多數請求失敗的原因。

如果您在顧客完成真實體驗後使用 Email，它依然能為您帶來極佳的效益。在 BrightLocal 的 2025 年在地消費者評論調查 中，40% 的美國消費者表示，當被要求留下評論時，Email 是他們最有可能留下評論的方式，相較之下現場親自詢問僅占 27%。該調查涵蓋了 1,026 名美國成年人，其中 96% 的受訪者願意撰寫評論。然而，意願並不等於實際行動。顧客需要的是在依然能清晰回憶造訪過程的時刻，於行動裝置上進行單一且明確的操作。

以下七個範本均採用相同的標準來評估。每一個都指定了觸發條件、發送時間區間、管道、個人化標記和合規界限，以防止其變成篩選評論（review gating）。請先依據觸發條件進行選擇，然後再調整文案。

目錄

• 1. Google 評論邀請（直接連結）
  • 可能出錯之處
• 2. 顧客離場後餐飲評論邀請
• 3. 飯店退房後評論邀請
  • 飯店合規基準線
• 4. 零售結帳後評論邀請
• 5. 多平台評論中心郵件
• 6. 評論提醒後續跟進管道
• 7. 調查轉公開評論邀請（意見回饋迴圈）
• 每種評論邀請郵件範本的觸發機制與發送時機
• 撰寫文案前先決定觸發條件

1. Google 評論請求（直達連結）

這是適用於大多數場所的基本評論請求電子郵件範本。一聲感謝，一句提及造訪的話，一個直接連結至確切 Google 商家檔案的按鈕。沒有其他需要決定的事情，這就是它運作良好的原因。

觸發條件為記錄到的收銀機收據、預訂或 WiFi 配對的到訪。發送時間窗口為當天或次日清晨，趁著記憶猶新時發送。請使用 {first_name}、{venue_name} 與 {visit_date} 變數標籤，並使用該分店地標的連結，而非總部頁面。擁有多家分店的咖啡館集團可以向每位與收據配對的顧客發送相同結構的郵件，只需在主旨行中更改分店名稱。酒吧集團則可以運用「{first_name}，感謝您今晚光臨」作為開頭，並將按鈕直接放在下方。

將寄件者設定為真實的門店經理或具名的工作人員。在正式推出前，請先在手機上測試連結，因為失效的深度連結會毀掉一封原本優秀的電子郵件。關於此流程背後的營運檢查事項，請參閱 餐廳適用之 Google 評論請求檢查清單。

容易失效的地方

當經理僅在服務順暢的輪班後或只向他們喜歡的訪客傳送時，機制就會失效。請對每一次記錄在案的造訪傳送相同的請求，不提供任何折扣或獎勵，並且不要預先篩選情緒。一致的傳送標準才能確保評論的可信度。

2. 顧客到訪後餐飲旅宿評論請求

餐廳、酒吧和咖啡廳在此需要展現親切感，但篇幅無需過長。感謝顧客參加特定活動或時段、指出一件他們可以評論的事項，然後詢問一次即可。像是「感謝您參與我們的週日午餐」會比泛泛的「感謝您的光臨」更具效果，因為這證明了您明確知道自己詢問的是哪一次體驗。

當符合預期時，顧客確實會接受這種管道。在 GatherUp 的 Beyond the Stars 2025 報告 中，53% 的顧客表示電子郵件是可接受的評論邀請方式，相比之下，面對面邀請為 49%，簡訊則為 33%。但這並不意味著可以群發垃圾郵件。請透過連結至已同意顧客紀錄的收銀機收據來觸發，並在到訪後二至六小時內發送。即使自動化流程已準備就緒，也應避免向晚餐顧客在深夜發送。

使用一個主要按鈕，即使您也在下方低調列出第二個平台。條件式區塊有助於您為首次造訪與再次光臨的訪客修改內文，而無需製作兩封電子郵件。請在審核時及傳送時再次檢查同意狀態，以確保尊重退訂選擇。

在顧客對餐點記憶猶新時發送，但不要在顧客仍在桌邊時發送。這個時間差就是餐飲旅宿業時機決策的核心。

當此範本變成電子報時就會失效。請移除選單、優惠與活動宣傳。一次到訪，一項請求。

3. 退房後飯店評論請求

飯店過早要求評價。在退房當天早上的請求，往往會在住客忙著打包、交通移動或處理帳單疑問時收到。請等待退房後一至三天，當他們回到家且對住宿體驗形成沉澱後的周全看法時再發送。

觸發點是物業系統中完成的退房手續。代碼應該在此發揮實質作用：{first_name}、{property_name}、{check_out_date} 和 {room_type}。一個簡單的主旨如 "How was your stay at {property_name}?" 就足夠了。優先列出對您的市場最重要的單一平台（通常是 Google 或 TripAdvisor），並將第二個平台放置於下方。不要讓疲憊的訪客去比較各大標誌。

飯店集團可能會在退房後兩天發送，優先放上 Google，其次是 TripAdvisor，並在頁尾另外附上直接預訂連結。公寓式飯店品牌也可以採用相同方式使用其記錄的住宿資料，前提是每個記錄的住宿都符合條件。

飯店的合規基準線

請勿排除曾在櫃檯抱怨過的訪客。請勿僅將滿意的訪客引導至公開平台。請確認您連結的平台允許此類邀請，傳送給所有記錄在案的住宿訪客，並透過獨立的營運流程處理服務補救。如果您在結帳時依據情緒進行篩選，您所收集到的樣本將不再具有代表性。

4. 購買後零售評論請求

零售的時機取決於使用情況，而非購買時間。蠟燭的使用效果可以很快評估，外套則不行。請根據商品類別設定延遲時間，且切勿同時要求撰寫商品評論與門市體驗評論。

請將此視為觸發式的體驗後訊息，而非一般的行銷活動。產品評論請求的獨立基準數據 顯示，開信率約為 40% 至 55%，點擊率為 8% 至 15%，且 點擊者中約有 5% 至 12% 會完成評論。這些區間告訴您努力的方向何在。從點擊到完成的途徑，比再發想一個主旨更加重要。

觸發條件是將訂單或收銀交易與已同意的訪客進行比對。權標為 {first_name}、{product_name} 和 {purchase_date}，並顯示實際購買的商品。購物中心的零售商可以將 WiFi 登入紀錄與收據進行比對，並在購買一週後傳送。家居用品連鎖店則應在不同日期的獨立訊息中，分別詢問商品與門店反饋。

僅顯示實際上可以被評論的項目。提供該產品的深層連結，先詢問評分，並將文字細節設為選填。建立您自己的場地基準，然後測試延遲時間與 Landing Page 的摩擦力。長篇的多頁表單常常是這個範本流失使用者卻讓人浑然不覺的地方。

5. 多平台評論中心電子郵件

有些品牌確實需要在多個平台提升評價數量。此範本並列顯示 Google、TripAdvisor、Yelp 或 Facebook，並附上中立標籤與完全相同的字眼。這在全球各國都很有用，但也最容易變得雜亂無章。

將平台數量控制在 三到四個。根據顧客的地理位置或預訂來源，按照他們最可能使用的平台排序。歐洲酒店集團可能會列出 Google、TripAdvisor 和在地平台，並依國家/地區設定排序。餐飲集團可能會在英國將 Google 排在第一位，並在其他地區測試不同的首選平台。如果您正在決定該排序，這篇針對酒店的 TripAdvisor 與 Google 評論比較 說明了箇中權衡。

• 觸發條件：針對已同意的訪客記錄一次已完成的造訪、住宿或消費。
• 傳送時機：配合實際體驗時程，而非固定的每週群發。
• 權標：僅使用 {first_name}、{venue_name} 與 {visit_date}，請勿根據預測的情緒來個性化選擇平台。

實用規則：每個平台按鈕使用完全相同的文案。如果一個按鈕寫著「告訴其他人您的美好住宿體驗」，而另一個僅寫著「評論」，您就已經干預了結果。

使用對照組測試按鈕順序，並衡量每個平台完成的評論數，而非點擊次數。當選擇變成負擔時，此範本就會失效。如果住客必須仔細思考要點擊哪裡，您就以涵蓋率為名增加了阻力。

6. 評論提醒後續追蹤序列

一次提醒是合情的，兩次通常過多。顧客錯過電子郵件是因為繁忙，而非需要被說服，因此請將後續追蹤維持在三行簡短文字內，並使用同一個單一連結。

有證據顯示第二次提醒能增加評論，但必須保持克制。PowerReviews 關於何時要求評論的最佳做法指南 指出，77% 撰寫評論的人會在收到或使用產品後的一週內進行，且第二次請求可以帶來更多評論，有 28% 的人在再次收到請求後留下評論。請以此為由，在合理的時間窗口內測試一次提醒，而非將其視為不斷追蹤的許可。

觸發點是在第一封電子郵件後未完成評論。請在幾天後發送，更改主旨以避免看起來像是重複發送，並在發送前再次檢查同意狀態。咖啡館集團可能會在三天後提醒一次，然後停止發送。飯店品牌應事先決定是否要排除已點擊但未提交的人員，並將該規則套用到所有人。

對大多數受眾而言，這部分上限設定為一次提醒。請保留一個不接收提醒的對照組，如 這篇針對場地自動化評論邀請電子郵件的指南 所述。如果提醒郵件相較於該對照組無法帶來增量完成數，請停止發送。開信率無法告訴您這些資訊。

7. 調查轉公開評論請求（意見回饋循環）

這是最容易變成審查門檻（gating）的範本，因此請在撰寫文案之前先建立規則。訪客完成了一份私下問卷調查。之後，您在另一封獨立的電子郵件中，邀請他們根據意願發表公開評論。每一位被詢問反饋的訪客都會收到相同的公開邀請。

這種區隔對合規性至關重要。FTC 關於徵求與付費獲取線上評論的指南 指出，企業 不應只向被認為可能留下正面評論的顧客提出請求，不應向未體驗過產品或服務的人徵求評論，也不應將獎勵措施建立在正面評價的條件上。與特定評價傾向掛鈎的補償也是被禁止的。

酒店可能會在住宿後發送調查問卷，並於一天後向所有完成問卷的人發送公開評論請求。零售連鎖店也可能在門市 kiosk 問卷後採取相同作法。在這兩種情況下，問卷答案可以在內部轉送服務問題，但絕對不能用來決定誰會收到公開連結。

請使用中立的字眼，例如「與我們分享您的體驗」。避免在電子郵件中使用星級評等提示、記錄符合條件的人員與發送時間，並在意見調查和公開請求之間保持至少一天的間隔。這個簡短的指南示範了實務中的意見回饋循環。

這會產生一些具建設性的公開負面評論。這並非失敗。相比於透過篩選建構出更高的平均評分，廣泛且無偏見的樣本更具說服力，也更有助於改善營運。

每種評論請求電子郵件範本的觸發與時機安排

範本	觸發條件	發送時間點	管道與個人化代碼	合規邊界
Google 評論請求（直接連結）	已記錄的收銀或預訂事件	當天或隔天早晨	Email：名字、場館、造訪日期、直接 Google 連結	詢問每一次獲得同意且有紀錄的造訪；不設評分過濾畫面
造訪後餐飲旅宿評論請求	POS 帳單連結至顧客紀錄	結帳後 2 至 6 小時	Email：場館、地點、造訪日期	所有符合資格的造訪均獲得相同的請求；抑制重複發送
住宿後飯店退房評論請求	退房或帳單結案事件	離店後 1 至 3 天	Email：物業名稱、住宿日期、房型	客訴導向服務團隊處理，絕不刻意阻擋公開連結
購買後零售評論請求	完成購買	使用後 7 至 14 天	Email：產品、門市、訂單 ID	不提供與正面評價掛鈎的獎勵
多平台評論中心 Email	已記錄獲得同意之顧客的完成造訪、住宿或購買	符合實際體驗：場館為當天或隔天，住宿為 1 至 3 天，零售為 7 至 14 天	Email 中心：市場、地點、平台連結	對每位顧客發出相同請求；由顧客自行選擇平台
評論提醒跟進序列	對首次請求無回應	首次發送後 3 至 7 天	相同郵件串、原始代碼、取消訂閱	提醒上限為一次；收到回覆或提交時立即停止
問卷轉公開評論請求（意見回饋迴圈）	完成問卷或表單提交	問卷完成後至少 1 天	Email：問卷日期、中立請求	問卷答案絕不決定誰能收到公開評論請求

在撰寫文案前先選擇觸發條件

從系統中能可靠標記已完成體驗的事件開始。這可能是收銀機收據、退房、已交付的商品或已完成的問卷。如果您無法證明體驗確實發生過，就不應該發送邀請。將一個範本與該事件配對，設定適合評估該體驗所需時間的發送窗口，並在所有人撰寫主旨之前，先將資格規則明確記錄下來。

然後對所有人套用相同的規則。向 每位有記錄的顧客發送相同的請求，過濾重複者和已提交評論的人，並將提醒次數限制為一次。不要添加獎勵，不要預覽您希望獲得的評分，也不要在將滿意的顧客引導至 Google 時，把不滿意的顧客轉移開離公開回饋管道。符合法規的請求與高轉換率的請求並不相同，前者為後者設定了界限。

衡量真正重要的指標。建立對照組，以便觀察完成的評論是否增加，並將回訪次數與評論一同追蹤，確保您評估的是實際成果而非開信率。我們將每封郵件算作一個點數，因此簡潔一致的規則也有助於預測成本，因為您不必付費重複催促同位顧客，或向根本不符合條件的人發送郵件。我們在 Purple Engage 中採用的方法，是在記錄到顧客到訪後向每位顧客徵求評論，不進行分數過濾，也不提供任何回報，並在發送前確認已取得同意。

大多數營運商在第一天不需要全部七個範本。選擇一個與您最可靠的觸發點相符的範本，統一執行，並在重寫文案前先修復 Landing Page 的摩擦力。只有在對照組證明提醒郵件確實有價值時才新增提醒。只有在單一平台不足時才新增多平台中心。這樣的流程能為您帶來經得起檢驗的評論，數量合理且可預測，同時不會讓訪客養成期待誠實評論能獲得獎勵的習慣。

---

如果您正在咖啡館、飯店或商店營運評論邀請，Purple Engage 可以在記錄到造訪、住宿或消費後觸發相同的公正電子郵件，發送前會先確認同意狀態，並設有對照組來衡量完成的評論與再次造訪率。您可以建立一次範本，並套用到各個據點，讓每次發送都與真實的訪客記錄連結。請造訪 Purple Engage，了解它如何融入您的據點。