SaaSの無料トライアルに登録した見込み客の登録情報と利用状況から、フォローの優先度とメールの下書きを作って営業の担当に渡す

処理の起点を決める

起点は2つあります。 1つはトライアルの登録で、製品が登録の完了時に Catch Hook のURLへ登録情報を送ります。もう1つは毎晩の集計で、製品が深夜に「登録から2日目」と「期間終了の4日前」に当たる登録者を抜き出し、利用状況をJSONの配列にまとめて別の Catch Hook へ送ります。

登録の時点では、メールの下書きを作りません。 登録の直後はまだ何も使っていないので、利用状況にもとづく文面が書けません。登録の時点で行うのは、台帳への記録と除外の判定だけです。 最初の連絡は、2日目の利用状況が届いてからにします。

2日目と期間終了の4日前を選んだ理由は、手を打てる時点だからです。 2日目なら、最初の設定でつまずいた登録者に間に合います。期間終了の4日前なら、使い込んでいる登録者に本契約の相談を持ちかけ、期間内に答えを出してもらう時間が残ります。 時点の日数は、実際の継続率を見て後から動かします。

入力データを集める

質を決めるのは、利用状況の項目の選び方です。 ログインの回数だけでは、「何度も開いたが設定でつまずいている」のか「毎日使っている」のかが分かりません。招待の人数、案件の登録件数、取引先の取り込みのように、使い込みの段階が分かる項目を選びます。製品の担当と相談して、継続した顧客がトライアル中に何をしていたかから決めます。

利用目的の自由記述は、文面の切り口に使います。 「営業案件の見える化」と書いた登録者と「請求書の作成を楽にしたい」と書いた登録者では、勧める機能が違います。

データの取得方法を決める

毎晩の利用状況は、製品から次の形のJSONの配列で送ってもらいます。 配列の要素ごとに後のステップが動くので、1件ずつ送る必要はありません。

[
  {
    "trial_id": "TR-20261006-0123",
    "timing": "day2",
    "login_days": 2,
    "invited_members": 3,
    "deals_created": 5,
    "clients_imported": false,
    "integration_configured": false,
    "last_login_at": "2026-10-06T09:12:00+09:00",
    "contact_allowed": true
  }
]

項目は、製品の側で集計した数字だけにします。 案件の名前や取引先の名前のような、登録者が製品に入れた中身は送りません。送ってもらう項目を最初に決めておけば、後から「この項目も」と製品側に頼み直す手間が減ります。 contact_allowed を毎晩送ってもらうのは、登録の後で連絡の可否を変えた人を、その日のうちに除くためです。

台帳の検索には Lookup Spreadsheet Row を使います。 指定した列から値の一致する行を探し、その行の値を返します。「最後の行から検索する」を有効にすると、下から探せます。 同じ登録者が2回登録している場合に新しい行を取るため、これを有効にします。補助の検索列と値も指定でき、トライアルIDと時点の両方が一致する行に絞れます。

既存顧客の照合は、会社名ではなくメールのドメインで行います。 会社名は「株式会社」の有無や略称でずれます。ドメインなら表記ゆれがありません。 ただし、フリーメールのドメインは照合の対象から外します。

AIへ渡す前に整形する

1. 除外の判定 … 営業からの連絡を「不可」とした登録者、既存顧客のドメイン、自社のドメイン、明らかなテスト用の登録（氏名が「test」など）を除外し、台帳に除外の理由を残します
2. フリーメールの印 … フリーメールのドメインで登録した人には印を付けます。除外はしませんが、文面の宛名と切り口を変えます
3. 担当者の割り当て … 従業員規模と地域で担当者を決めます。決まっていない登録者は、インサイドセールスの責任者に回します
4. 前回の連絡の確認 … 期間終了の4日前の時点では、2日目に送った内容を台帳から取り出し、同じことを繰り返さないための材料にします
5. 利用状況の整形 … 数字を「招待したメンバー：3名」のような日本語の事実の一覧に直します。AIに渡すのは、この一覧です
6. 期間の残り日数の計算 … 登録日時から、期間の終わりまでの日数を計算します。日数の計算はAIにさせません

5番目が文面の質を決めます。 JSONの項目名のまま渡すと、AIは invited_members: 3 を「3名のチームでご利用」と言い換えるなど、事実を少しずつ膨らませます。 日本語の事実の一覧にして渡し、それ以外を書かせない指示と組み合わせます。

AIに処理させる

AIに任せるのは文面の下書きだけです。 優先度と連絡の切り口は、その前に規則で決まっています。

Paths は条件ごとに違う手順に分ける機能で、1つのグループに最大10本の分岐を置けます。 分岐は左から順に評価され、条件の重なる分岐は両方動くので、条件が重ならないように規則表を作ります。 どれにも当たらないときの分岐は1つだけ置けます。

指示内容を固定する

あなたは業務向けSaaSのインサイドセールスの担当者です。
無料トライアルの登録者に、担当者の名前で送るフォローメールの下書きを作ります。

【渡す情報】
- 登録者：{name}（{company}、{department}）
- 利用目的（登録者の記述）：{purpose}
- 時点：{timing}（day2 または end_minus_4）
- 期間の残り日数：{days_left}日
- 優先度と連絡の切り口：{priority} ／ {angle}
- 利用状況の事実：{usage_facts}
- 前回の連絡の内容：{previous_contact}
- 担当者の名前：{rep_name}

【厳守事項】
- 本文で触れてよい事実は「利用状況の事実」と「利用目的」に
  書かれていることだけです。数字は書かれたとおりに使い、
  言い換えたり、膨らませたりしないでください。
- 登録者の会社、業界、課題について、渡されていないことを推測して
  書かないでください。
- 値引き、無料期間の延長、特典を約束しないでください。
- 「ご活用いただきありがとうございます」のような、利用していない
  登録者に合わない書き出しを使わないでください。時点と利用状況に
  合わせてください。
- 前回の連絡と同じ案内を繰り返さないでください。
- 本文は400字以内。次の一歩は1つに絞ってください。
- facts_used に、本文で触れた事実を「利用状況の事実」から
  そのまま写してください。
- 利用目的が空欄、または意味の取れない記述のときは、
  利用目的に触れずに書いてください。
- 書けない項目は空欄のままにしてください。

「数字は書かれたとおりに」と「膨らませない」を並べて書いています。 片方だけだと、数字は合っていても「すでにチームで本格的にお使いいただいており」のような評価を足します。登録者が読んで違和感を持つのは、たいていこの評価の部分です。

「利用していない登録者に合わない書き出し」を名指しで禁じるのは、優先度Cの文面で起きやすいからです。お礼から始める型の文章は、一度もログインしていない人には皮肉に読めます。

出力形式を固定する

AI by Zapier の出力項目を次のように定義します。 項目ごとに名前・型・説明を付けます。

1つ目の理由は、台帳の列に分けて入れられることです。 出力項目を定義しないと、1つにまとまった結果が返り、件名と本文を分けられません。

2つ目は、facts_used で確認が速くなることです。 担当者は、本文を読む前に、どの事実を使って書いたかを1行で見られます。facts_used に無い数字が本文に出ていたら、それはAIが足したものです。

3つ目は、宛名と署名を本文から外していることです。 宛名と署名は Zapier の側で差し込みます。AIに書かせると、敬称や会社名の表記がそろいません。

Gmail の下書きは次の形で作ります。

件名：{subject}
本文：
{company}
{name} 様

{body}

――――――――
{rep_signature}

台帳には、優先度、切り口、subject、facts_used、下書きを作った日時を書き込みます。 本文は Gmail の下書きにあり、台帳には要点だけを残します。

システムへ連携する

下書きは、インサイドセールスの共有のGmailアカウントに作ります。 担当者ごとの送信元のアドレスは、Gmail の別名（エイリアス）として設定しておく必要があります。下書きの差出人を担当者の別名にしておけば、担当者は自分の名前で送れます。

送信は Zapier からは行いません。 Gmail の Send Email の操作もありますが、使いません。送るかどうか、電話に切り替えるかどうかは担当者が決めます。 Gmail には1日に送れる数の上限があり、超えるとアカウントが止まるおそれがあるとされていることも、自動送信を避ける理由の1つです。

人が確認する

1. 朝、Slack の一覧で優先度Aから見る … A の登録者は、下書きを確かめたうえで、電話に切り替えるかを先に決めます
2. facts_used と本文を見比べる … 本文に、facts_used に無い数字や評価が混ざっていないかを確かめます
3. 言い回しを自分の言葉に直す … 下書きはたたき台です。担当者が普段使う言い回しに直してから送ります
4. 結果を台帳に記録する … 「送った」「電話した」「送らなかった（理由）」のいずれかを記録します

4番目の「送らなかった理由」が、規則表を直す材料になります。 優先度Aと出たのに担当者が送らなかった登録者が続くなら、規則の条件がずれています。月に1回、送らなかった理由を集計して、規則表を見直します。

優先度Cは、一覧で件名だけを見て送る運用にしてもよいと考えます。始め方の案内は文面の差が小さく、1件ずつ深く確かめる必要は薄いからです。

例外に対処する

最後の行は見落とされがちです。 Zap を止めている間に届いた送信は受け取られず、その日の対象がまるごと抜けます。 製品側の送り出しで、失敗した送信を記録して翌日に送り直すようにしておきます。

記録を残す

• 受け取った登録情報と利用状況のJSON（トライアルIDと時点ごと）
• 除外の判定とその理由
• 決まった優先度と切り口、そのときの規則表の版
• AIに渡した事実の一覧と、返ってきた出力項目の全文
• 担当者が送った本文（下書きとの差を見るため）
• 連絡の結果（送った／電話した／送らなかった理由）と、その後の本契約の有無

3つ目で規則表の版を残すのは、規則を後から直すためです。 優先度の条件を変えたあと、本契約につながる割合がどう変わったかを比べるには、どの規則で優先度を付けたかが残っている必要があります。

最後の行で、この構成の効果を確かめます。 優先度ごとに本契約の割合を並べると、規則が成果と結びついているかが見えます。