WooCommerce 信件外掛拆解：改得動版面，管不到送達

先架一個虛構情境對焦問題：一間接單預售的甜點工作室，週五傍晚湧進一批訂單，陸續有客人在手機的垃圾信匣裡翻找出貨通知；老闆收到同業訂單信的截圖，開始嫌自家的信太過陽春；行銷夥伴則追問，出貨信裡能不能放一段回購推薦。三個要求出現在同一天，指向的卻是三個不同的系統層。

把層次攤開，結論有點反直覺：這三個願望裡，信件客製化外掛解決得了一個半。沒收到信，卡在投遞層，要修的是寄信管道與網域驗證；圖片顯示不出來，卡在郵件客戶端的解讀層，跟範本無關；想要條件式內容，或想接管第三方外掛寄出的信，才真正進入外掛的管轄範圍。順序錯了，等於裝修蓋在沒打好的地基上；先修投遞、再談美化，是全篇的主軸。

規模感也先擺上桌。依 W3Techs 的長期追蹤（查詢於 2026 年 6 月），WooCommerce 是網站採用最廣的電商系統（見 W3Techs 的市佔追蹤），圍繞它發展出來的信件工具因此自成一個市場，值得在動工前把規則看清楚。以下依序處理：信件問題怎麼歸段、送達層怎麼自查、原生設定的極限在哪、三款外掛各接管哪一層、免費與付費的邊界畫在哪裡，以及行銷需求的天花板與最終的驗收順序。

快速重點：信件外掛只接管範本渲染層。沒收到信先查 SMTP 與 SPF、DKIM，換模板救不了投遞；版面重排與條件內容才輪到 YayMail、Kadence、VillaTheme 三條路線，免費與付費的分界落在條件、多語系與第三方信件。

信件的問題出在哪一段：渲染、交寄，還是解讀？

先給判定法。按下送出訂單後，一封信要經過四個接力點才會出現在客人眼前：範本先被組成信件內容，WordPress 把信交給系統的寄信程式，投遞服務把信送到對方的郵件伺服器，郵件客戶端再決定怎麼呈現。行銷名單與分眾發送，又是另一套系統。模板外掛只接管第一段；其餘每一段，都有自己的失敗模式與驗證訊號。

帶著症狀進場的人，可以先對照下面的歸屬表，把抱怨翻譯成系統層：

• 沒收到信、信進垃圾匣：投遞層。客訴原話通常是「我這邊看不到訂單信」。對應動作是查發信紀錄與信件標頭，送達自查那節有完整流程。
• 信太陽春、不像自家的：呈現層的原生設定極限。客訴原話像「這封信看起來不像你們寄的」。對應動作是把後台的信件設定用滿，再考慮升級。
• 要條件內容、改不動其他外掛的信：功能層，外掛的戰場。例如點數異動的信想加一段說明，卻找不到可編輯的介面。對應動作是拿官方功能表逐項核對。
• 想養名單、發回購推薦：名單層，電子報系統的職責。對應動作是檢查訂閱同意與資料同步，而非升級信件模板。

兩個誤判最常見。一個是把投遞問題當版面問題：外掛換了、信變體面了，該進垃圾匣的照樣進垃圾匣，因為投遞層根本沒被動到。另一個是把行銷期待押在交易信上：交易信被期待的是即時與正確，促銷塞多了只會稀釋它的可信度。還有件事容易被低估：核心自帶的新訂單、處理中、完成、退款與密碼重設各有對應的信件，出貨與到店這類狀態信則多半來自後來裝上的擴充功能，信件的種類比多數店主想像的多。

把症狀歸段還能救預算。不少店主是在客訴高峰時緊急採購，業務推銷什麼就裝什麼，三個月後後台多了好幾套功能重疊的工具；回頭用歸段法檢視，常會發現其中一半解的是投遞層的問題，跟範本根本無關。先判定、後採購的紀律，比任何選購懶人包都省錢。

歸段還有一個附帶好處：對內溝通的語言會統一。跟工程師回報「投遞層的 SPF 是 fail」，比「信好像怪怪的」快得多；跟行銷夥伴說「這屬於名單層，不歸模板管」，討論會直接跳到對的工具類別。症狀翻譯成層次，每一種抱怨都有明確的去處，這是後面所有章節共用的判定框架。

場景不同，起點也不同。還沒開店的讀者，先順著 WordPress 開店的整體流程把站架起來，再回頭對照 WooCommerce 的基礎設定與操作；想先把生意全局想清楚的人，可以從 電商經營的完整輪廓讀起。已經在營運的店，直接從下一節的送達自查開始。

信還沒進收件匣，模板改得再美也沒用

這節先講結論：客人反映沒收到信，第一個動作絕對不是挑信件外掛，是把投遞鏈查一遍。模板工具在這一層沒有施力點，花再多預算美化範本，也改變不了信件被分類到哪裡。

檢查有固定的順序。先確認網站用什麼方式寄信：交給主機自帶的郵件功能，還是串接專業的發信服務。共享主機的郵件功能常有數量限制與信譽問題，正式營運的店後來多半改走 SMTP 搭配發信服務。接著到網域的 DNS 補上 SPF 與 DKIM 兩筆紀錄，讓收端伺服器確認這封信有權以你的網域名義寄出。完整的操作細節，SMTP 與發信服務的設定步驟有逐步說明。

底層機制方面，WooCommerce 的信件交由 WordPress 的 wp_mail() 發出，這支函式內部使用 PHPMailer；至於信怎麼送出去，取決於主機端的設定。延遲、退信或被歸進垃圾信，通常源自驗證沒設、寄送信譽不足或缺乏紀錄可查，而不是 PHPMailer 在共享主機上一律不可靠。

驗收只要十分鐘。寄一封測試信到 Gmail 帳號，確認它被歸進收件匣，還是被扔進垃圾信匣；進了垃圾匣，就打開「顯示原始郵件」，找 SPF 與 DKIM 的驗證結果是 pass 還是 fail。fail 代表網域驗證沒設好或設錯，回 DNS 修；pass 卻仍被歸類，問題通常出在寄送信譽或內容特徵，要從發信服務的紀錄往回追。排查時一次只動一個變數，改善了才知道原因是哪一個。

發信紀錄的位置也先記下來。串接發信服務的站，到服務後台看每一封信的投遞狀態：已送達、被延遲、被退回，各自有紀錄可查；還在用主機郵件功能的站，紀錄取決於主機方案，有的要登入主機後台看，有的根本不保留。這也是正式營運的店後來多數改走發信服務的原因之一：排查時有紀錄可看，吵架有憑據。

信譽的觀念值得多花兩分鐘。寄送信譽是收端伺服器對你網域的長期印象，由投遞量、退信率、垃圾投訴與驗證紀錄慢慢累積；新網域突然大量寄信，就像新面孔開口借車，被從嚴審視是正常反應。進階的店家會把行銷信與交易信分到不同的子網域寄送，兩種信譽各自累積，一方出事不拖累另一方；這個功夫在導入發信服務時順手就能做，事後再拆等於要搬家一次。

主機環境的整備可以順手一起做：整理快取與效能設定時，確認寄信行為沒有被快取干擾，能把環境問題與信件問題分開，減少誤診。這條線索到維護債那節還會再接上。

預設範本不是不能改，是被郵件格式綁住

「WooCommerce 的信完全不能客製化」是流傳很廣的說法，事實是核心設定早就涵蓋商標、配色、頁尾文字與基本字型，新版的信件設定甚至能直接套用佈景主題的配色（見 WooCommerce 官方的信件設定文件）。真正改不動的是版面結構與條件內容，而這個限制有它的技術根源，不是功能吝嗇。

信件 HTML 是另一個時代的網頁。多數郵件客戶端對現代 CSS 的支援參差不齊，可靠的排版方式仍然是表格結構加行內樣式；網頁端習慣的彈性版面，原封不動搬進信件就是災難。範本因此天生保守，WooCommerce 也把多種信件類型放在同一套骨架上，確保跨客戶端的一致性。代價是：想改結構，面對的是整個範本家族，不是一封信。

直接去改範本檔同樣行不通，核心更新會把修改覆蓋掉；正規做法是透過覆寫機制，把範本放到自訂位置再調整。這正是信件外掛存在的技術理由：把覆寫這件事包裝成圖形介面，讓不寫程式的人也改得動。原生能力與外掛能力的邊界，可以簡單對照：

• 後台設定能改的：商標圖片、品牌色、基本字型與頁尾文字，以及信件主旨的開頭片段。
• 後台設定改不動的：欄位順序、區塊的增刪與重排、依訂單條件顯示的內容、其他外掛觸發的信件。

還有一塊常被忽略：信件主旨。主旨不歸範本美醜管，但歸設定層管，後台能替每種信件加上一致的字首。訂單完成信的主旨寫清楚店名與事由，客人在收件匣裡找信、客服在信件往來裡對單，都省力。這個調整五分鐘就能做完，效益卻比想像中持久。

判斷原則很樸素：能用設定解決的，不要裝工具。把原生設定用滿，剩下的缺口自然會顯形，再看它屬於哪一層。範本檔與覆寫機制的完整脈絡，信件範本系統的底層結構有更深入的拆解。

你寄出的版面，不等於客人看到的畫面

設計稿在編輯器裡完美、客人手上卻走版，原因多半不在設計，在郵件客戶端的主導權。CSS 支援不一致、預設不載入圖片、深色模式自動換色，都會改寫寄出的版面。設計的底線只有一條：以手機上的閱讀為準，桌面當第二驗證。

幾個細節值得在設計階段就想清楚。寬度以單欄窄幅為底，多欄排在手機上會堆疊成一長列；字級不要壓到多數裝置的舒適下限；資訊層級用留白與粗細區分，不要只靠顏色，深色模式會把顏色換掉。行動閱讀的重要性可以從流量結構側面推想，但網頁的行動流量組成，不能拿來直接推斷信件會在哪些裝置上被打開（見 Statista 對行動網頁流量的長期追蹤），驗證仍要涵蓋桌面與常見的郵件客戶端。

按鈕與連結也要備援。大量按鈕是用圖片做的，被擋圖時整顆消失，客人想追蹤包裹卻找不到入口。穩妥的做法是圖片按鈕之外，同一段落用純文字再放一次連結；追蹤物流、查看訂單、聯絡客服這三個動作，值得文字版永遠在場。

圖片是另一個容易被高估的元素：多數郵件軟體收到信時，預設不載入圖檔。把訂單金額、物流編號這類關鍵內容做進圖片裡，等於把資訊押在對方願意按下「顯示圖片」的那一下。文字層必須自給自足：圖片摔掉，信照樣讀得通。成熟品牌的通知信經得起這個檢驗，把圖檔全部擋掉再看，結構與資訊仍然完整。範本動工前先做一次這樣的壓力測試，比上線後回頭補救省事得多。

字體也有信件版的現實。網頁能用的豐富字型，到了信件端只剩系統預設字集堪用；想在信裡維持品牌感，靠的是字級層級、粗細與間距的紀律，特殊字型幫不上忙。深色模式的換色同樣繞不過系統字集的限制，設計時把這些約束當成畫布的一部分，成品才不會在客人手機上變調。把字做成圖檔看起來像解方，但圖片預設不載入，把品牌押在會被擋的元素上，等於把招牌掛在沒開的路燈上。

三款外掛動的其實是同一批範本檔

三款的差異常被講成美醜之爭，實際的分歧點只有一個：它們動的都是 WooCommerce 那批信件範本，差別在接管方式。Kadence 走全域樣式覆寫，在類似客製化器的介面裡統一調整既有信件的外觀；VillaTheme 走範本管理與條件配送，免費版就能自建範本，依訂單條件自動套用的規則官方畫在付費版；YayMail 走拖放建構器，用區塊把範本重建一次。依「要動到哪一層」選路線，而不是依品牌知名度。

機制上，三者都掛在 WooCommerce 產生信件的環節，把原本交給範本檔的工作接過去。這表示兩件事。第一，它們互斥：兩款同時啟用，後接管的那套會蓋掉先前的設定，寄出的信時對時錯。第二，它們與其他同樣碰信件的外掛比鄰而居，安裝前先盤點現有外掛生態，能少踩 hook 衝突的坑；這份功課可以併進 WooCommerce 必裝外掛的總體檢查一起做。

三條路線對應三種維護成本。樣式參數最輕，改動集中、影響範圍清楚；範本管理居中，多出來的範本要自己命名與維護；建構器重建最重，彈性最大，但範本結構是自己定義的，核心更新後的檢查工作也最多。成本沒有好壞，只有對應：一年改不到兩次的店，重的路線是負債；每季都在調信件內容的店，輕的路線很快會碰到天花板。

預覽方式也是路線差異的一部分。樣式覆寫在調整的當下就能看到整體樣貌；範本管理要逐張範本點開確認；建構器則是邊組邊看，即時但耗時。習慣一次看全貌的人與習慣逐封打磨的人，對同一條路線的體感會差很遠，試用時把「改一封信要點幾次、看幾個畫面」也算進去。

除錯的分工也照路線走。樣式覆寫的問題多半出在繼承，關掉再開、逐項還原設定就能定位；範本管理的問題常出在配送條件設錯，信寄了卻套到別張範本；建構器的問題最藏在細節裡，區塊刪了、變數斷了，症狀要等到那張範本被觸發才浮出來。知道每條路線常見的故障位置，回報問題時描述才會準，求助時也少一輪雞同鴨講。

網路上流傳的模板數、元素數、安裝數，會隨版本變動，抄進文章三個月就過期。能力與範圍以官方當期說明頁為準，這也是下一節把比較軸放在「官方文件畫的邊界」上的原因：文件比心得文耐放，也比較不會被行銷話術上色。

免費與付費的邊界，官方文件畫在哪裡

同一張功能清單，不同店家會讀出相反的結論，因為免費與付費的分界都落在同一刀附近：條件邏輯、多語系、第三方信件，但三款下刀的位置不同。這一節逐款對照官方文件怎麼分界；先講明，沒有優勝者，只有對應關係。

讀功能表有個訣竅：把「能編輯」與「能套用到哪些信」分成兩欄看。多數爭議出在某一類信到底吃不吃這套編輯，編輯器好不好用反而是次要；頁首頁尾能換，不等於正文能改；核心信件能改，也不保證第三方外掛的信跟著吃到設定。兩欄分開之後，功能表上的每一行才對得上自己的需求，免費與付費那條線畫在哪，也才看得清楚。

Kadence：全域樣式覆寫的路線

Kadence 的賣點是集中與輕量。設定在類似客製化器的介面裡完成，既有信件的外觀一次調整，負擔小、上手快；相對地，它管不到的範圍也同樣明確，適合需求停在外觀層的店。

Kadence 的重點是以 WordPress 客製化器調整既有信件的樣式與文字，不是區塊編輯器，也沒有與 Kadence 主題 Pro 綁定的信件付費方案可直接推定。它對部分第三方信件提供整合；其他信件可能只繼承頁首、頁尾與色彩，無法預覽或修改正文。

VillaTheme：範本管理加條件配送的路線

VillaTheme 的 Email Template Customizer（在 WordPress.org 上的現名為 Mailonix）走另一條路：範本自己建，免費版就提供拖放編輯與 WooCommerce 的專屬元素，空間比「調樣式」三個字大得多；至於根據訂單狀態自動挑範本的配送規則，官方列在付費方案。

就能力邊界而言，拖放編輯與 WooCommerce 專屬元素確實在免費範圍內，把它講成只能改改樣式是低估。但條件邏輯、多語系與第三方信件各自的涵蓋程度，加上免費與付費之間的界線，都會隨版本移動；下載前以官方功能表與測試環境逐項核對，才是可靠的做法。

YayMail：拖放建構器重建的路線

YayMail 出自 YayCommerce 團隊，把範本整個拆成區塊重組，彈性是三條路線裡最大的，代價是結構自己扛。它的免費與付費分界不在「能不能拖放」，而在條件與整合的深度。

YayMail 可編輯 WooCommerce 核心交易信件，Pro 擴充部分動態資料與整合。條件式顯示有獨立的 Conditional Logic 加購，第三方外掛自訂的信件也可能需要對應 Addon；不能把購買 Pro 當成所有條件、會員欄位與信件範本都已包含。

免費版最容易漏接的縫，是第三方外掛觸發的信件。裝了 優惠券的設定邏輯相關的加強工具，到期與使用的提醒信才會多出來；點數與購物金制度的外掛自己會推點數異動信；串上 付款與配送的狀態設定的金物流服務，出貨與到店通知由它們發，核心管的退款信是少數例外；動態定價改了訂單金額之後，信裡的數字也得跟著對。這些信不屬於 WooCommerce 核心，免費版涵蓋到哪裡，要逐項對功能表，不能憑印象。

矩陣的用法是先勾需求，再沿行讀。要動的只有外觀，第一行就夠；要自訂範本與配送條件，看第二行；要重排結構與深度條件，看第三行。多數店會停在唯一解；需求橫跨兩行的，用組合判斷處理，不要兩款並裝。

付費之前的檢查只有三件事，每件都在自己的環境裡做：

• 功能表逐項核對：條件、多語系、第三方信件三格分開確認，看到「支援」兩個字先問清楚支援到哪裡。
• 測試環境驗證：用自己的核心版本、佈景主題與訂單範例跑過一輪，再談上線。
• 官方文件確認範圍：能力以當期說明與已測試版本為準，過期的心得文只當線索。

授權結構也值得看一眼再付錢。加購制的總成本，要把將來可能需要的加購全部加起來算；單一方案則看涵蓋範圍是否真的用得到。授權到期對更新與支援的影響各家不同，續約前把這兩件事看清楚。價格數字以官方頁面為準，這裡不代抄，免得過期誤導。

要橫向比較，也有省事的安全做法：在測試環境裡逐一安裝、輪流啟用，一款看完就停用、清快取，再換下一款，全程保持單一外掛接管。同一張測試訂單寄出來的信並排存檔，編輯邏輯、預覽方式與預設樣式的差異會直接顯形，比讀十篇比較文都快，也順便驗了與你站上環境的相容性。

再架一個情境（同樣虛構）：一間多語系選品店，中文與英文站並行，信件要跟著語系切換，還想依客戶等級在信裡帶不同折扣。這種需求直接踩在三款付費邊界的那一刀上。挑選時與其比價，不如把自己的語系外掛、信件類型、條件清單列成表格，對著官方功能表逐格打勾；哪款先全綠，答案就自己浮出來。

交易信裡的行銷紅線

想在訂單信裡放推薦商品、養名單、做行銷自動化，先畫一條紅線：交易信的首要任務是準確傳達訂單資訊，行銷是延伸，不是本體。訂閱同意與資料同步是兩件分開的事，分眾與自動化屬於電子報系統的職責。

這條紅線畫清楚之後，行銷自動化有自己的去處：交易信只管即時通報，購買紀錄要靠相容的電商整併工具同步到電子報平台，才能成為分眾的素材，而分眾郵件的寄送對象必須建立在顧客同意的基礎上。像買過某類商品後三十天收到回購提醒、超過三個月沒再下單時收到喚醒信，這類流程由名單工具安排，不屬於信件客製化外掛；若在規劃交易信時一併設想，內容的編排會更貼近長期經營。結帳頁的訂閱勾選與資料同步各有專屬機制：前者看表單工具能不能掛進 WooCommerce 的結帳流程，後者多半畫在電子報平台的付費方案裡。通知與名單，終究是兩套要分開管理的系統。

同意紀錄要當成資產來管。結帳頁的勾選、活動頁的表單、客服往來裡留下的許可，來源不同，證據力也不同；真被質疑濫發時，拿得出每筆名單的來源與加入時間，比任何口頭解釋都有說服力。退訂機制則要真的能退：交易信是服務通報，本來就不掛行銷退訂；行銷信的退訂一按就要生效，而且要整個名單系統同步。這兩封信各自的責任分界，正好對應前面把系統分層的邏輯：哪封信歸哪套系統管，同意與退出的路就跟到哪裡。

條件式內容在交易信裡有正當用途：依商品類別給不同的售後說明、依會員等級帶對應的折扣資訊，這一層正是三條路線付費邊界所在的那一層。成效追蹤則要保守：開信率會被圖片載入與隱私保護干擾，只能當輔助訊號；行銷投報的調查數字（見 HubSpot 的行銷統計調查）講的是整體市場，不能推論單一商店把推薦塞進訂單信就會得到相同回報。

同意與退訂的實務細節，決定行銷延伸的底線。結帳時的訂閱勾選要預設不勾，讓同意是客人自己的動作；交易信裡若引用折扣，連到的是訂單相關服務而非促銷頁。這些規則各地規範不同，但方向一致：交易通報與行銷接觸分開取得同意、分開提供退出的路。

名單層的長期經營，交給專責的工具：挑系統時看訂閱管理、範本彈性與發送量能，經營時看分眾的切法與寄送的節奏。把行銷需求導向正確的工具類別，交易信保持即時與乾淨，兩邊都好維護；這是範疇的劃分，不是誰取代誰。

裝完外掛才開始的維護債

外掛裝完上線，維護才要開始。三件事會在幾個月後浮現：WooCommerce 更新造成範本與動態變數的漂移、兩款信件外掛互相接管範本、快取讓舊信殘留誤導判斷。這些債在安裝當下就簽了字，只是付款日期在後面。

換外掛有正確順序：停用舊款、清掉快取、確認新版型正常，才移除舊檔，全程不要雙開。雙開的症狀很陰險，信時對時錯，客訴查不到穩定的重現條件，往往要到後台看啟用清單才真相大白。

安裝前的盡職檢查花不了幾分鐘：看最近更新日期、標示的已測試版本與變更紀錄，再進測試站跑一輪。三款的維護狀態隨時間變動，這裡不概括宣稱誰持續更新，以你安裝當下看到的紀錄為準。

信件外掛也不該被單獨看。把它放進整站的外掛盤點，與 快取外掛的設定、SEO 工具一起檢視，hook 衝突的面積會小一截；用不到的外掛順手停用，環境單純，問題就好查。

維護的節奏可以跟著核心的更新走。WooCommerce 有較大版本更新時，先在複製出來的環境升級、點開幾種信件範本確認版面與動態變數，再更新正式站；平時的小更新照一般流程即可。把這個動作變成習慣，漂移造成的客訴會少一大半。

範本異動的留痕也有便宜的做法。每次大改前，把當下的範本設定截圖或匯出存檔，註明對應的核心版本；更新後對照一次，漂移的區塊一眼就看到。這份紀錄在換外掛時另有用處：舊範本長什麼樣、哪些區塊是自己客製的，遷移到新路線時就是驗收的對照組，不必憑記憶重建。

上線前，用一張測試訂單走完驗收

驗收的單位是訂單，不是預覽信。一封預覽只能看版面，驗不了資料；從安裝到切上正式站之前，用一張測試訂單把全流程走完，才算真的驗收。

順序照著走：照 安裝外掛的標準流程裝妥，先寄測試信確認送達，再下測試訂單觸發訂單完成信；接著手動把訂單狀態逐一改過（處理中、完成、退款），站上若另裝了出貨追蹤之類的外掛狀態，也一併觸發，讓每一種範本都被點名，檢查垃圾信匣的放置結果，用手機打開每一封看版面。開站的整體檢查，可以併進 商店設定的開站檢查一起收尾。

測試訂單順便驗動態變數：品名、金額、收件資料、物流單號都對了，這張範本才算過關。任何一格顯示成原始的變數代碼，代表外掛沒接上對應的資料來源，先修再上線，不要賭它正式環境會自己好。

動態變數的檢查可以列成固定清單：品名、數量、單價、總額、稅額、收件人姓名、地址、電話、物流編號、付款方式，一格一格對著後台的訂單資料核。清單化的好處是可交接，今天你測、下個月換工讀生測，走的都是同一張表；測出問題也能直接指出是哪個變數沒接上，回報外掛支援時省一輪來回。

即時觸及有另一個管道可補位：訂單通知改走 LINE 的店，出貨與到店訊息可以更即時。但兩個管道的同意與封鎖處理各自獨立，也不能假設通訊軟體的觸及率必然較高；它是互補，不是替代。

升級順序比選哪一款更重要

預算有限、需求又還不明確時，順序就是答案：核心設定能解決的，不裝外掛；免費覆寫能解決的，不付費；付費只留給條件與多語系的明確需求。每一階段往前走之前，用一封訂單完成信加一筆測試訂單驗收，過了才前進。

停在哪一階，用四個問題決定：要動的到底是哪一層；信件由誰長期維護，那個人吃不吃得動這套編輯器；第三方外掛觸發的信件占多少比例；以及不裝會發生什麼事。第四題的答案若是「其實也不會怎樣」，就停在原階段，把預算留給別的。

四個問題也可以換成半年的回顧儀式：把期間內的客訴歸段統計，看哪一層的抱怨最多、哪一項工具裝了之後沒再打開。這份回顧會給出下一階段的優先序，比憑感覺升級有依據；多數店回顧完的結論是「先把現有的用滿」，鮮少需要再買一套；工具的帳面功能會讓人心動，店裡真實發生的問題才值得花錢。

上線後把信件當營運資產疊代：定期看投遞紀錄與開信數據的趨勢，檔期前預演版面與內容。節奏保持定性判斷就好；信件的第一指標是準時抵達與內容正確，其他成果是慢慢疊出來的，沒有保證數字。

搜尋流量與信件轉換是互補的兩面：站內的內容與結構顧好搜尋（SEO 工具的設定教學是另一條戰線），交易信顧好下單之後的每個接觸點。客人抱怨的症狀會一直換，分層判斷法不會：先問這封信卡在哪一段，再決定動工具、動設定，還是動順序。