SaaSの
偽のユーザーや連絡のつかないユーザーがプロダクトに入る前にメールアドレスを検証し、無料トライアル、デモリクエスト、オンボーディングシーケンス、プロダクト分析をクリーンに保ちます。
次のクリーニング前に正確なコストを知りたいですか？ VeriMailsの料金をご確認のうえ、無料クレジットから始めましょう。
要約
- 新規登録、デモリクエスト、購買意欲の高いフォーム送信の時点で検証し、使い捨て、無効、打ち間違えのメールアドレスがプロダクトやCRMのレコードにならないようにします。
- 有効な結果は通常のオンボーディングに回し、無効なレコードは抑制し、リスクありやキャッチオールの結果は営業シーケンスや大量のライフサイクルメールの前にレビューします。
- 既存のユーザーやリードには、再アプローチ、製品のお知らせ、契約更新、アカウントベースの営業キャンペーンの前に一括検証を実行します。
SaaS
SaaSの登録データの質が影響するのは、到達率だけではありません。不正確なメールアドレスは、トライアルのコンバージョン、プロダクトのアクティベーション、営業への引き継ぎ、カスタマーサクセスのレポート、ライフサイクルメールの成果を歪めかねません。使い捨ての受信箱や打ち間違えた会社のアドレスで無料トライアルが作成されると、プロダクトチームにはユーザーとして見えても、オンボーディングや営業はその人に確実に連絡できません。
VeriMailsは、ユーザーレコードが作成される前、またはリードがCRMに送られる前に配置しましょう。結果に応じて、アプリケーションは受け入れる、修正を求める、抑制する、レビューする、というシンプルなポリシー判断ができます。特に、無料トライアル、デモリクエスト、ウェビナー登録、フリーミアム製品、セルフサーブのオンボーディングなど、量が多く手動レビューが現実的でないフローで役立ちます。
開発者は、メール検証APIを使って登録ハンドラーに組み込めます。RevOpsチームは、一括検証を使えば古い登録データをクリーニングできます。HubSpot、Salesforce、またはマーケティングプラットフォームをすでにお使いなら、連携ガイドから始め、検証結果をライフサイクルやルーティングの項目として書き戻しましょう。
登録フローを
偽アカウントをシステムに入る前に阻止します。
登録
登録フローにAPI呼び出しを1つ追加するだけです。VeriMailsは構造化された検証結果を返すため、無効または使い捨てのアドレスをユーザーデータベースに入る前に拒否できます。
使い捨て
Mailinator、Guerrilla Mail、YOPmailをはじめ、数百もの使い捨てプロバイダーの一時的なアドレスをブロック。恒久的なアドレスを持つユーザーだけがトライアルを開始できるようにします。
トライアルの
不正な登録では、使い捨てメールで無料トライアルを何度も取得することがよくあります。これをブロックすれば、トライアルの仕組みを守り、コンバージョン指標を意味のあるものに保てます。
ライフサイクルメールの
オンボーディングシーケンス、新機能のお知らせ、更新のリマインダーは、届く受信箱があってこそ機能します。検証により、ライフサイクルメールのデータをよりクリーンに保てます。
プロダクト
偽のユーザーアカウントは、アクティベーション率、リテンションカーブ、ファネル指標を歪めます。登録データがクリーンになれば、プロダクトデータを信頼しやすくなります。
開発者に
APIリクエスト1回で、JSONレスポンス。標準的なHTTPエンドポイントを呼び出せるあらゆる技術スタックで動作します。
SaaSの
顧客体験はシンプルに保ちつつ、プロダクトを守るのに十分なシグナルをバックエンドに提供します。
ユーザー
フォーム送信時にVeriMailsを呼び出します。明確に有効な結果はそのまま登録に進みます。明らかに無効または使い捨ての結果であれば、アカウント作成前に修正メッセージを表示できます。
ポリシーに
検証カテゴリをプロダクトのデータベースやCRMに書き込みます。有効なユーザーはオンボーディングに残し、無効なアドレスは抑制し、キャッチオールやリスクありのレコードは営業アウトリーチの前にレビューします。
ライフサイクルと
オンボーディングメール、更新のリマインダー、アップセルキャンペーン、アクティベーションのコホート、デモ後のフォローアップが、明らかな偽登録ではなく、よりクリーンなレコードから始まります。
プロダクト
適切なポリシーはフォームによって異なります。無料トライアルの登録には、通常ニュースレターの購読よりも厳しいフィルタリングが求められます。企業ドメインからのデモリクエストは、個人の受信箱で作成されたフリーミアムアカウントとは別の扱いが必要かもしれません。VeriMailsが提供するカテゴリを使えば、レコードごとに個別のレビューキューを作らずに済みます。
セルフサーブの登録では、使い捨てアドレスと明らかに無効なアドレスをブロックします。デモリクエストでは、疑わしいレコードを担当者に届く前にセールスオペレーションへ回します。アプリ内招待では、招待者が信頼できればリクエストを受け入れつつ、招待されたアドレスに印を付け、ライフサイクルメールや請求関連の連絡を監視できるようにします。インポートしたイベントやウェビナーのリストは、通常のナーチャリングシーケンスに入れる前に一括で検証します。
これにより、プロダクトチームとGo-to-Marketチームの足並みがそろいます。プロダクトはアクティベーションデータをクリーンに保ち、ライフサイクルマーケティングは避けられるバウンスを防ぎ、営業は連絡がつく可能性の高いリードに集中できます。
推奨する
アカウントを作成してオンボーディングを開始し、そのメールアドレスをプロダクトやライフサイクルのメッセージの配信対象として維持します。
連絡のつかないアドレスには、アクティベーション、ナーチャリング、営業のメールを送りません。
キャッチオール、リスクあり、または通常と異なる結果は、大量の営業キャンペーンやライフサイクルキャンペーンの前に別のキューへ移します。
導入後に
まずは、SaaSチームにとってすでに重要な運用指標から始めましょう。登録からアクティベーションへの転換率、デモリクエストの質、オンボーディングメールのバウンス、営業メールの返信率、そしてフォームで検出した使い捨てアドレスや無効なアドレスの割合です。目的は単にアカウント数を減らすことではありません。残ったアカウントを、プロダクトや収益のワークフローにとってより信頼できるものにすることです。
到達率については、プロダクトとマーケティングのどちらの配信でも同じバウンス率の運用範囲を使いましょう。3%未満は健全、3-5%はクリーニングや注意が必要、5%超は高リスクです。ライフサイクルキャンペーンが警告範囲に入っているなら、次の大規模配信の前に古いユーザーを検証します。デモ後のフォローアップがバウンスしているなら、インバウンドのリクエストを営業キューに入る前に検証・セグメント化します。
分析については、明らかに不正なアドレスを除外した後でトライアルのアクティベーションが改善するかを確認しましょう。登録データがクリーンになれば、プロダクトの利用状況、メールのエンゲージメント、営業への引き継ぎが、そもそも届かなかったレコードによって薄まらないため、ファネル分析がしやすくなります。