電子報工具在 WordPress 生態裡的定位一直有些微妙。許多站長會先在外部平台建立訂閱名單，等到流量規模起來才回頭整合 CRM，結果發現名單散落在三四個系統，自動化流程也難以互通。這個痛點推動了一批以 WordPress 為核心的 wordpress 電子報外掛崛起，把訂閱管理、名單分群、自動化流程都收回到同一套後台。

目前在這個方向最成熟的兩款，一是 MailPoet，一是 FluentCRM。兩者的定位與設計邏輯差異明顯，選錯了之後要遷移會相當費力。本文以訂閱表單、自動化流程、名單分群三個面向逐一說明，並整理與現有表單外掛串接時要留意的關鍵節點。

MailPoet 的設計邏輯與適用情境

MailPoet 從一開始就把「寄信」放在第一位，其他功能圍繞發送流程搭建。這樣的設計讓初次接觸的站長可以在半天內完成「收集訂閱者→設定歡迎信→排程週報」的完整流程，不需要閱讀大量技術文件。

訂閱表單的嵌入方式

MailPoet 內建表單編輯器，提供固定位置嵌入（embedded）、彈出視窗（popup）、滑動進入（slide-in）、頂部列（top bar）等幾種版型，全部在後台拖拉設定，不需要額外安裝任何元件。建立完成後可以直接用短代碼（shortcode）或區塊（block）放進任何頁面，也可以設定觸發條件，例如進站停留 10 秒、滑到頁面 70% 深度才出現彈窗。

表單完成訂閱後，MailPoet 預設走雙重確認（double opt-in）流程，訂閱者收到確認信點擊後才算成功加入名單。這個設定可以在後台關閉，但若是收費清單或跨境受眾，建議維持開啟，有助於大幅降低退信率與垃圾郵件申訴。

自動化流程的觸發機制

MailPoet 的自動化（automation）從 3.x 版後重新設計，觸發點可以選擇「加入特定名單」「購買 WooCommerce 商品」「訂閱者生日」「手動觸發」等。每個觸發點下可以串接延遲等待、條件分支、發送郵件、新增標籤等動作，形成一條線性的自動化鏈。

邏輯設計上屬於「事件驅動」，每個訂閱者進入自動化序列後獨立追蹤，互不干擾。在大多數中小型網站的場景裡，像是「加入名單後立刻送歡迎信，3 天後送一篇精選文章，7 天後送一個優惠碼」這樣的序列，MailPoet 的介面可以讓非技術背景的操作者在 20 分鐘內設定完成。

名單分群的邊界

MailPoet 的分群邏輯以「名單（list）」為核心，一個訂閱者可以同時屬於多個名單；另外也支援「動態區段（segment）」，可以依條件自動歸類，例如「過去 30 天開信但未點擊的訂閱者」。

限制在於，MailPoet 的分群條件以郵件行為與 WooCommerce 購買紀錄為主，對於更複雜的自訂欄位比對或跨站行為分析，彈性不如定位更接近 CRM 的選項。

FluentCRM 的設計邏輯與適用情境

FluentCRM 把自己定義為「行銷自動化 CRM」，而非電子報工具。這一字之差在設計架構上體現得很清楚，它以「聯絡人（contact）」為核心單位，郵件只是管理聯絡人關係的其中一種溝通管道。

聯絡人模型與訂閱表單

FluentCRM 本身不帶內建的前端表單，它負責管理資料，表單的收集工作委由其他外掛處理，再透過整合介面把資料送進聯絡人資料庫。官方維護整合模組的表單外掛包括 Fluent Forms、WPForms、Gravity Forms 等，設定方式是在各外掛的「動作」或「通知」設定裡選擇「新增到 FluentCRM」，指定要加入的標籤或名單即可。

這個架構讓 FluentCRM 的前端採集非常靈活。舉例來說，同一個網站可以用 Gravity Forms 做活動報名、用 WPForms 做詢問表單，兩者收到的資料都能自動送入 FluentCRM，並根據表單種類打上不同標籤，後續的自動化序列再依標籤分流。

自動化流程的條件深度

FluentCRM 的自動化（automation）支援「觸發點→條件判斷→動作→等待→再觸發」的多層巢狀結構，條件判斷可以讀取自訂欄位、標籤、名單歸屬、歷史郵件互動、WordPress 使用者角色等多個維度。

這套架構對有會員制度或多種商品類型的網站特別有用。一個訂閱者購買商品後，可以依購買金額高低、購買品類、是否首次購買，分別走入不同的後續流程，而不是所有購買者都收到同一封感謝信。條件設定的語法近似一般的邏輯判斷，非技術人員需要一些時間適應，但熟悉邏輯後修改速度很快。

名單分群的維度

FluentCRM 使用「標籤（tag）」與「名單（list）」兩套並行的分類系統，標籤用來描述行為與屬性（例如「已下載白皮書」「高消費客群」），名單用來對應訂閱關係（例如「週報訂閱者」「VIP 會員」）。兩者可以組合作為自動化的觸發條件或篩選器，形成細粒度的受眾切分。

動態區段可以依多重條件即時篩選聯絡人，且可以把 WordPress 的自訂欄位（custom field）資料拉進條件裡。這對於內容型站台想要依「閱讀主題偏好」分群、或電商想要依「購買類別」做再行銷的場景，提供了充裕的操作空間。

MailPoet 與 FluentCRM 的核心差異對比

選定工具前，把兩者的關鍵維度放在一起看，可以讓決策更快收斂。下表以 2026 年各自的最新版本為基準整理。

若網站的核心需求是定期發週報、歡迎序列、購買後追蹤等標準電子報場景，MailPoet 的上手速度與介面成熟度是明顯優勢，免費版的 1,000 名限制對多數起步網站已夠用。一旦網站開始有明確的會員層級、多品類商品或需要依行為做複雜分流，FluentCRM 的架構才能發揮價值。強行用 MailPoet 湊功能，會讓自動化流程越設越難維護。

與現有表單外掛的串接方式

串接的核心問題是「表單提交後，資料如何進入電子報系統」。MailPoet 和 FluentCRM 在這個流程上有本質上不同的處理方式，釐清差異可以省去許多重複設定的工夫。

MailPoet 的串接架構

MailPoet 提供官方整合模組給主流表單外掛，包括 Contact Form 7、WPForms、Ninja Forms 等。整合後，在各表單外掛的「確認動作」設定裡會出現「新增到 MailPoet 名單」選項，選擇目標名單後即完成。對於使用 Gravity Forms 的站台，需要另外安裝 MailPoet for Gravity Forms 這個連接外掛，設定邏輯相同。

需要注意的是，MailPoet 在串接表單時，電子郵件欄位必須明確對應到其「Email」欄位，其他自訂欄位（例如公司名稱、電話）若要一起帶入，需要在 MailPoet 後台先建立對應的自訂訂閱者欄位，再在表單整合設定裡逐一對應。

FluentCRM 的串接架構

FluentCRM 的串接邏輯不走「在表單外掛裡選 CRM」的方向，而是在 FluentCRM 後台的「整合（Integrations）」頁面設定各表單外掛的觸發規則。操作上是在 FluentCRM 端建立一條「Feed」，指定「當收到來自 WPForms 表單 ID 123 的提交時，建立聯絡人並加上標籤 X」，形成從 CRM 端拉資料的架構。

這個設計的優點是，所有整合邏輯集中在 FluentCRM 一個地方管理，不必在各個表單外掛裡分別設定，後續若要新增觸發動作或修改標籤，只改 CRM 端即可。初次設定時需要切換兩個後台，對只用一種表單外掛的站台而言，複雜度相對高一些。

若網站同時使用 Fluent Forms 與 FluentCRM（兩者都來自 WPManageNinja），整合體驗最為順暢。表單提交的欄位對應、訂閱確認信、雙重確認流程都可以在同一套邏輯下完成設定，幾乎不需要額外手動配置。

站長在評估串接方案時，一個實用的判斷角度是先清點現有表單外掛的種類與數量。若表單外掛本就是 Fluent Forms，搭配 FluentCRM 幾乎是自然的延伸選擇；若已大量使用 WPForms 或 Contact Form 7，MailPoet 的串接設定反而更直覺，也能降低額外的學習負擔。