Frontのコンタクトをクリーンで配信可能な状態に保つ
Frontは返信が届かなかった場合にバウンスを会話に返すため、担当者はメッセージが届かなかったことを確認できます。しかし、一度もメールを送っていないアドレスについては判断できません。インポートしたコンタクトや新規登録に含まれる、送信実績のない無効なアドレスこそが、サポートの返信を誰にも気づかれないまま失敗させる原因です。Qualisendはこのギャップを埋めます。FrontのネイティブコネクターでコンタクトをFront上で直接検証して結果を反映するか、手動でエクスポート、検証、タグの付け直しを行えます。REST APIやZapier、Make、n8nのフローを使えば、新しいコンタクトを取得した瞬間にすべて検証できます。
CSV不要で、Frontと直接連携
必要なのはAPIキーだけ
FrontのAPIトークンを貼り付けます。トークンはFrontの「Settings → Developers → API Tokens」で作成できます。その後、qualisend_statusというコンタクトのカスタムフィールドを追加します。
- Frontのすべてのコンタクトをクリーニング
- 結果を各コンタクトのカスタムフィールドに保存
- 新しい受信メールの送信者をリアルタイムに検証
- 7日・14日・30日ごとに自動クリーニング
CSVやAPIでの利用も可能です。詳しくは下記をご覧ください。
Frontが標準でクリーニングするもの
Frontはチームのメールチャネルをつなぐ共有受信トレイです。そのため、リストメンテナンスの仕組みは、実際にメールを送信するプロバイダーに依存します。Frontからの返信がハードバウンスすると、mailer-daemonの通知が会話または受信トレイに戻ってくるため、そのチケットを担当している人が失敗に気づけます。しかしFrontには、ESPのような配信除外リストも、バウンス済み・クリーニング済みといったステータスの仕組みもありません。バウンスを表示するだけでアドレスを除外はしないため、翌日に別の担当者が同じ無効なメールボックスに返信するのを止めるものは何もありません。何らかの仕組みでその判定をコンタクトに反映しない限り、失敗したアドレスへの対応は手作業になります。
検出できないもの
問題は、Frontがバウンスによってアドレスの状態を知るのは、誰かがすでにメールを送り、返信が失敗した後だということです。コンタクトのインポートで入った送信実績のない無効なアドレス、登録フォームや問い合わせフォームで受け付けた使い捨てアドレス、役割アドレス、昨年までは問題なかったのに使われなくなったメールボックス、すべてを受け付けて何も明かさないキャッチオールドメインは、最初の返信で問題が判明するまで、どれも問題なく使えるように見えます。そしてそのタイミングこそ、メールプロバイダーがサポート用ドメインの第一印象を形成する瞬間です。最も深刻なのは、インポートしたコンタクトリストです。バウンス履歴が取り除かれた状態で取り込まれるため、別のシステムですでに配信に失敗していたアドレスも、Frontにはまったく新しいアドレスに見えます。
Frontのリストをクリーンに保つべき理由
Frontの料金はコンタクト数ではなくチームメンバー数で決まるため、コンタクト数で課金するESPとは違い、リストをクリーニングしてもサブスクリプション料金は変わりません。ここで問われるのは、顧客とのサポート上の関係と送信者レピュテーションです。チケットへの返信、発送のお知らせ、パスワード再設定の通知がバウンスすれば、SLA違反、チケットの再オープン、そして無視されたと確信する顧客が生まれます。しかも担当者は、メッセージが届いていないことに気づきません。さらに、送信する返信の1通1通がドメインの評価を形づくります。無効なメールボックスに送り続ける共有受信トレイはバウンス率を押し上げますが、GmailとYahoo!の2024年の送信者ガイドラインはまさにその数値で送信者を評価するため、正常な返信まで迷惑メールフォルダーに振り分けられやすくなります。
CSV・APIを使う場合：手動での手順
最も手早いのはネイティブコネクターですが、CSVでの手順はFrontのどのプランでも利用できます。Frontからエクスポートし、Qualisendで検証して、結果に応じて対処します。
Frontからコンタクトをエクスポート
Frontのサイドバーから「Contacts」を開き、対象を絞ってメンテナンスしたい場合はコンタクトグループで絞り込んで、コンタクトをCSVにエクスポートします（ネイティブコネクターならこの手順は不要で、Front上のコンタクトを直接読み込みます）。
Qualisendでファイルを検証
CSVをQualisendの一括クリーニングにアップロードするか（1回の処理で最大100万件、重複アドレスの課金は1回のみ）、サンプルを直接貼り付けます。Freeプランで初回のみ付与される100クレジットは有効期限がなく、最初の抜き取り確認に使えます。
結果を確認
各アドレスには、配信可能・要注意・配信不可・不明のいずれかの判定が、理由コードとサブフラグ（キャッチオール、使い捨て、役割アドレス、容量超過）とともに返ります。根拠となるMXプロバイダーとSMTP確認の詳細、0～100の信頼度スコアも表示されます。クリーニング済みのCSVをダウンロードします。
Frontで配信不可アドレスにフラグを付ける
Frontには配信除外リストがないため、無効なアドレスを除外するには、セグメント分けするのが適切です。「配信不可」というコンタクトグループ（またはカスタムのコンタクトフィールド）を作成し、配信不可アドレスを追加して、その未解決の会話をアーカイブしてください。担当者が届かない相手に返信することを防げます。ネイティブコネクターなら、判定を各コンタクトのqualisend_statusカスタムフィールドに自動で書き込みます。
または登録時に自動で検証
最も速い方法はFrontのネイティブコネクターです。7日・14日・30日ごとにスケジュールに沿って再クリーニングを行い、各判定をコンタクトのqualisend_statusカスタムフィールドに直接書き込みます。新しく届くコンタクトを検出するには、QualisendのREST API（スコープ付きキー、レート制限、Webhook）や、Frontの新規コンタクトをトリガーとするZapier、Make、n8nのフローで、アドレスの取得時点で検証してください。入力ミスや使い捨てアドレスを、担当者が返信しようとする前に検出できます。
Qualisendがすべてのアドレスで検出するもの
- 担当者が返信した瞬間にバウンスする、送信実績のない無効なアドレス
- 登録フォームや問い合わせフォームで受け付けた使い捨てドメイン
- 誰も確認していない共有メールボックスに届く役割アドレス（info@、support@）
- セグメント分けして重要な通知には頼らないよう、フラグを付けたキャッチオールドメイン
- すべてのアドレスに付く0～100の信頼度スコアと、機械判読可能な理由コード
Frontのネイティブコネクターを提供中です。Qualisendの「連携」でFrontと連携すると、CSV不要でFrontのリストを直接扱えます。
結果ごとの対処法
各アドレスには判定とサブフラグが返されます。まだ届くコンタクトを失わずにFrontのリストをクリーンに保つための対処法は次のとおりです。
配信可能通常どおり返信・送信します。配信可能 + 役割アドレスフラグ残して返信してかまいませんが、共有メールボックスであることを踏まえ、チーム全員が状況を把握できるようタグを付けます。要注意 + キャッチオールフラグ専用のコンタクトグループに移し、急ぎの通知には頼りません。要注意 + 使い捨てフラグ対応を見送るかアーカイブします。期限切れを前提に作られたメールボックスなので、SLAを費やす必要はありません。不明アクティブのまま残し、次回のクリーニングで再検証します。多くはグレーリスティングによるもので、メールボックス自体の判定ではありません。配信不可タグを付けて「配信不可」グループに追加し、アーカイブして担当者が返信しないようにします。レコードが不要であれば、コンタクトを削除します。Frontのメールアドレス検証に関するよくある質問
Frontのリストを数分でクリーニング
有効期限のない100クレジットで無料で始められます。クレジットカード登録は不要です。連携して検証するだけで、次のキャンペーンを守れます。