Mailshake 負責處理外部序列。您決定哪些內容進入其中。
Mailshake 專為直接的外部推廣電子郵件而建 — 清晰的序列、收件匣輪換、投遞率控制，以及不需要銷售運營團隊設定的活動管理。它在有直接潛在客戶開發活動而無需複雜編排開銷的銷售團隊、創始人和代理商中廣受歡迎。
Mailshake 擅長的是讓活動易於啟動。這種易用性是它的特性，也是名單品質決策被跳過的地方 — 因為當啟動活動只需十分鐘時，就會有人想要匯入一個尚未驗證的名單，事後再處理退信問題。
小型外部推廣團隊的退信預算有限。用於冷郵件推廣的域名沒有深厚的信譽儲備。一次高退信率的活動可能導致收件匣定位問題，需要數週時間才能恢復。
Mailshake 匯入前應檢查的事項。
Mailshake 活動通常從 CSV 匯出、Apollo、LinkedIn 或手動潛在客戶開發匯入名單。每種來源的默認品質水平不同。以下是在任何名單進入 Mailshake 活動之前需要注意的欄位。
| 欄位 | 重要原因 |
|---|---|
| 電子郵件 | 接收每個序列步驟的地址 — 活動啟動前必須驗證 |
| 域名 | 決定 catch-all 狀態、MX 健康狀況，以及該域名是否仍在使用中 |
| 來源 | Apollo、LinkedIn 匯出、CSV、手動研究 — 每種來源的衰減率和錯誤率不同 |
| 封鎖狀態 | 之前退信或取消訂閱的地址，不應再進入任何 Mailshake 活動 |
| 名單年齡 | 超過 90 天的名單存在顯著的過時風險 — 重複使用前務必重新驗證 |
每種信號類型帶來的風險。
使用 Mailshake 的小型團隊比大型組織更容易受到退信率後果的影響。五千行名單中的幾百條無效記錄，就可能將退信率推入危險區域。
| 信號 | 投遞行為 | 對 Mailshake 活動的風險 |
|---|---|---|
| 無效 | 被接收伺服器永久拒絕 | 硬退信 — 直接損害發送域名和收件匣信譽 |
| Catch-all | 域名接受所有地址，信箱狀態不確定 | 不可預測的投遞 — 扭曲退信率和效能數據 |
| 角色型 | 共享收件匣（info@、sales@、hr@） | 技術上可投遞，但作為具名推廣聯絡人效果較弱 |
| 一次性 | 臨時或低信任地址 | 不是真實的商業聯絡人 — 在任何序列中都毫無價值 |
| 未知 | 驗證結果不確定 | 若未經刻意決策，不應進入活動 |
| 重複 | 同一地址被匯入超過一次 | 多次向同一聯絡人發送 — 投訴和取消訂閱風險 |
在匯入前驗證，而非在退信後補救。
對名單品質採取行動的機會，在 Mailshake 活動建立之前。一旦名單載入並且第一批郵件發送出去，任何退信損害就已經開始了。在第一次活動波發送後審查效能統計數據，已經太晚，無法保護域名。
匯入是一個承諾點。Mailshake 活動通常設計為在啟動後完整執行。在匯入前讓名單正確，意味著活動可以按照預定的時程執行，而不需要在發送途中緊急暫停來清理無效記錄。
將每個結果導向正確的分組。
| BillionVerify 結果 | Mailshake 匯入前的動作 |
|---|---|
| 有效 | 匯入目標 Mailshake 活動 |
| 無效 | 不要匯入 — 新增到封鎖清單 |
| Catch-all | 單獨的低量活動分組，在擴大規模前監控投遞情況 |
| 角色型 | 使用適合共享收件匣的文案，設立單獨活動 |
| 未知 | 納入前先審查 — 不要混入主序列 |
| 高風險或一次性 | 不要匯入 |
維護持續更新的封鎖清單。在前一次 Mailshake 活動中退信、取消訂閱或產生投訴的任何地址，都應從所有未來的匯入中排除，無論它出現在哪個名單或來源中。
名單驗證完成後。
通過審核的記錄匯入 Mailshake 後：
- 有效地址進入標準量的主活動序列
- Catch-all 地址在獨立於主活動的低優先級分組中執行
- 角色型地址獲得適合共享收件匣的調整後郵件內容
- 無效和一次性記錄永久新增到您的封鎖檔案
- 未知地址在做出任何活動決定之前先接受審查