Klenty 執行節奏序列，進入它的內容品質由你決定。
Klenty 為銷售互動而設計，CRM 同步的聯絡人、多步驟電子郵件節奏、大規模個人化，以及跨外向堆疊的工作流程自動化。它與 Salesforce、HubSpot 和 Pipedrive 緊密整合，意味著聯絡人通常直接從 CRM 同步流入活躍序列。
這種緊密整合非常高效，但也是一個風險向量。CRM 記錄會隨時間累積。18 個月前新增的聯絡人可能已換工作、網域到期或完全離開了一個組織。他們的電子郵件地址在發生這些事情時不會自動從你的 CRM 消失。當 Klenty 同步這些記錄並將其加入節奏序列時，名單品質問題就變成了即時發送問題。
Klenty 不對每個聯絡人是否應該接受外展做最終決策，那個判斷在上游屬於你，在名單到達節奏引擎之前。
Klenty 匯入前應檢查什麼。
進入 Klenty 的每份名單在匯入前都應通過欄位層面的審查，CRM 同步的名單需要特別注意，因為每筆記錄的年齡和來源往往不清楚。
| 欄位 | 重要性 |
|---|---|
| 電子郵件 | 進入節奏序列的地址 — 需要有效且可投遞 |
| 網域 | 決定 catch-all 狀態、MX 記錄有效性及公司是否仍活躍 |
| 來源 | Salesforce 同步、HubSpot 匯出、Pipedrive、手動上傳 — 各有不同的過期風險 |
| 抑制狀態 | 在之前活動中退信或取消訂閱的聯絡人，不應透過 CRM 同步重新進入 |
| 名單年齡 | 超過 90 天前新增到 CRM 的任何記錄，在節奏序列加入前都值得重新驗證 |
每種訊號類型帶來的風險。
Klenty 看到名單之前，訊號類型很重要。了解每個結果的含義，有助於在任何聯絡人進入序列之前套用正確的路由規則。
| 訊號 | 投遞行為 | 對 Klenty 節奏序列的風險 |
|---|---|---|
| 無效 | 在伺服器端永久被拒絕 | 硬退信 — 對發送網域聲譽的直接損害 |
| Catch-all | 網域接受所有地址，個別信箱不確定 | 可能投遞或退信 — 在節奏指標中增加不確定性 |
| 基於角色 | 共用收件箱（info@、sales@、support@） | 技術上有效但非具名外展目標 — 低互動，可能引發投訴 |
| 一次性 | 臨時或低信任地址 | 非真實業務聯絡人 — 匯入前移除 |
| 未知 | 驗證結果不確定 | 不應在無額外審查的情況下進入高量節奏序列 |
| 重複 | 同一地址出現多次 | 跨節奏步驟的重複發送，增加投訴風險 |
在匯入前驗證，而非退信後才驗證。
正確的干預點是在你將聯絡人匯入 Klenty 之前。一旦聯絡人在活躍的節奏序列中，他們會自動推進到各步驟。在運行中途停止節奏以移除不良記錄，既具破壞性又往往為時已晚，退信已經發生且聲譽損害已經開始。
Klenty 中的 CRM 同步功能不套用外部品質關卡，它帶入 CRM 擁有的內容。BillionVerify 位於 CRM 匯出和 Klenty 匯入之間，而非在 Klenty 本身內部。
在 Klenty 看到記錄前路由每個結果。
| BillionVerify 結果 | 行動 |
|---|---|
| 有效 | 匯入 Klenty 並加入目標節奏序列 |
| 無效 | 不匯入 — 加入抑制名單 |
| Catch-all | 獨立的低量節奏序列或發送前保留豐富化 |
| 基於角色 | 獨立節奏序列，訊息適合共用收件箱 |
| 未知 | 待人工審查 — 排除高量節奏序列加入 |
| 高風險或一次性 | 不匯入 |
在 CRM 同步中保持抑制文件的即時性。如果 Klenty 自動同步 CRM 中的新聯絡人，在他們進入任何活躍節奏序列之前，對這些新記錄執行驗證檢查。同步功能不知道地址是否過時。
名單驗證完成後。
已驗證聯絡人匯入 Klenty 後：
- 有效地址以你的標準步驟頻率加入目標節奏序列
- Catch-all 地址在獨立監控的低量節奏序列中執行
- 基於角色的地址收到不假設具名讀者的節奏訊息
- 無效和高風險地址被抑制，排除在未來 CRM 同步之外
- 未知地址在任何節奏決策前在審查佇列中等待