ウェビナーの出席者と欠席者、当日の質問を Zapier で受け、視聴の状況と質問の内容に合わせたフォローのメールを一人ずつ作り分ける

処理の起点を決める

取り込んだ記録を、担当が Zap に送ることで始めます。 Zapier Tables の公式ページでは、記録を取り込んでも、New Record のトリガーの Zap は動かないとされています。取り込んだ記録を選び、「Automate records」から Zap を選んで「Send to Zap workflows」で送る形で、1ページで10,000件まで送れます。

この「動かない」を、仕組みとして使います。 取り込んだ直後に全件が自動で動くと、社内の参加者や配信停止の人を外す前にメールが作られます。送る前に表を見て外す時間が取れるのは、取り込みでは動かないからです。

送る順は、質問の表が先、参加者の表が後です。 質問を参加者の記録に書き足し終わってから、参加者の表を Zap ②に送ります。順を逆にすると、質問した人に質問の無いメールができます。 Zap ①の実行が終わったかは、Zap の履歴で件数を見て確かめます。

承認のあとの送信は、Zapier Tables の Updated Record で動かします。 公式ページの一覧では、記録が変更されたときに動くトリガーです。承認の印が付いていて、送信済みが空の記録だけを Filter で通します。

入力データを集める

質を決めるのは、回ごとの章立てと時刻です。 「0〜15分：課題の整理」「15〜35分：事例」「35〜55分：デモ」のように持たせておけば、入室と退室の時刻から、その人が見ていない章が分かります。 章立てが無ければ、在室時間の長さしか使えません。

書き出した CSV の形を、取り込む前に確かめます。 配信ツールによっては、表の上に回の概要の行が付いたり、文字コードが UTF-8 でなかったりします。表の部分だけにして UTF-8 で保存し直してから取り込みます。 公式ページでは、表の項目が足りないと取り込めず、既存の表は少なくともファイルと同じ数の項目を持つ必要があるとされています。

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

レポートは、ウェビナーの主催者か、利用状況のレポートを見る権限のある人が書き出します。 Zoom の公式ページでは、主催者、管理者、または利用状況のレポートを見られる役割が必要とされています。担当が主催者でないなら、役割の設定を先に頼みます。

質問を参加者の記録に書き足すとき、同じ人の質問が続くと上書きが起きます。 Zap ①が同じ人の質問を同時に2件処理すると、後に書いた方が前の質問を消します。 そこで、Delay After Queue で1件ずつ順に処理します。公式ページでは、Delay After Queue は実行を列に並べ、決めた間隔で1件ずつ処理するとされています。

AIへ渡す前に整形する

1. 社内の参加者を外す … 自社のドメインのメールアドレスを、参加者の表で消すか「対象外」にします
2. 配信停止の人を外す … 配信停止の一覧にあるメールアドレスを「対象外」にします
3. 同意を確かめる … 登録のときにフォローのメールへの同意が無い人は、製品の案内を入れない区分にします
4. 視聴の区分を決める … 在室時間が全体の8割以上は「最後まで」、それ未満は「途中で退出」、出席でない人は「欠席」
5. 見ていない章を出す … 入室と退室の時刻を回の章立てと重ね、見ていない章の番号を並べます
6. 質問の区分を決める … 当日の回答があるものは「回答済み」、無いものは「未回答」

4番目と5番目は、AIではなく Paths の条件と数字の比較で決めます。 在室時間と章の時刻は数字で、比べれば決まることです。 AIに「この人は途中で抜けたか」を読ませると、在室時間の単位（分か秒か）を取り違えたときに気づけません。

入室と退室をくり返した人は、レポートに複数の行が出ることがあります。 取り込む前に、書き出した CSV をスプレッドシートで開き、同じメールアドレスの行の在室時間を合計して1行にまとめます。 Zap の中で合計しようとすると、行ごとに別の実行になり、まとめる場所がありません。

3番目の同意は、登録のときの回答で確かめます。 総務省のページでは、特定電子メール法は取引関係以外においては、事前に同意した相手に対してのみ広告・宣伝のメールを認める方式で、同意を証する記録の保存と、送信者の名称や受信を拒む連絡先の表示を求めています。登録のフォームの同意の欄の値が出席者レポートに含まれるかを、書き出しで確かめます。 含まれなければ、登録者のレポートから同意の欄を参加者の表に取り込みます。

AIに処理させる

AI by Zapier に、登録者ごとのフォローのメールと、未回答の質問への回答の案を作らせます。 公式ページでは、AI by Zapier はProfessional・Team・Enterprise のプランで使え、知識の元としてGoogle ドキュメントを1つずつ、1ステップに20個まで加えられるとされています。

当日の回答は、AIに書き直させません。 パネリストがその場で答えた言葉が正しい答えで、言い換えると意味が変わることがあります。 写すだけです。

2行目がいちばん起きやすい失敗です。 「〇〇との連携はありますか」に資料の記載が無いと、AIは「今後の対応を検討しています」と書きます。 その一文は、顧客には予定として読まれます。資料に無ければ、担当から連絡すると書かせます。

指示内容を固定する

あなたはSaaSの会社のマーケティング部の担当として、ウェビナーの登録者へ送る
フォローのメールの下書きを作ります。送る前に担当が読みます。

【入力】
- 氏名、会社、視聴の区分（full / partial / absent）、見ていない章の番号
- consent：製品の案内を含めてよいか（yes / no）
- 質問の一覧（質問、当日の回答。当日の回答が空なら未回答）
- 回の情報：題名、章立てと時刻、録画の URL、次回の案内
- 知識の元：製品の資料、よくある質問、回ごとの章の要点

【本文の組み立て】
1. 区分に合うお礼を1〜2文。
2. partial のときは、見ていない章の要点を章の要点の文書から2〜3行ずつ。
   absent と partial のときは、録画の URL と見ていない章の開始の時刻。
3. 質問があれば、回答済みは当日の回答をそのまま写す。
   未回答は、製品の資料とよくある質問にある範囲で答える。
   資料に無ければ「担当者より改めてご連絡いたします」とだけ書く。
4. consent が yes のときだけ、次回の案内を1文。

【厳守事項】
- 当日の回答は一字も変えずに写してください。
- 料金・割引・契約の条件・見積は、資料にあっても書かないでください。
  聞かれていれば「担当者より改めてご連絡いたします」と書いてください。
- 開発の予定、今後の対応、検討中のことを書かないでください。
- 資料に書かれていない機能について「できます」と書かないでください。
- 導入の時期・人数・料金・見積・試用を聞いている質問があれば sales_flag を true にし、
  sales_reason に該当した質問を原文のまま写してください。
- 本文は400字程度。署名は入れないでください。

「資料にあっても料金を書かない」を明記しないと、料金表のページから値を写します。 公開の料金表と同じ値でも、質問した会社の条件では違う値になることがあります。料金を聞いた人はインサイドセールスが連絡する相手なので、メールでは答えず、印だけを付けます。

「一字も変えずに写す」も効きます。 書かないと、話し言葉の当日の回答を丁寧な書き言葉に整えます。 整えた拍子に「基本的には可能です」が「可能です」になることがあり、条件が抜けます。

出力形式を固定する

AI by Zapier の出力項目で、次の形に決めます。 公式ページでは、出力項目ごとに名前・型・説明・必須かどうかを決めるとされています。

{
  "subject": "",
  "body": "",
  "answered_from_docs": ["Q2"],
  "deferred_questions": ["Q3"],
  "sales_flag": true,
  "sales_reason": "",
  "includes_next_invite": false
}

1つ目の理由は、deferred_questions で担当の宿題が分かることです。 「担当者より改めてご連絡いたします」と書いた質問が、記録ごとに並びます。答える担当を決めて、期限を付けられます。

2つ目は、sales_flag と sales_reason をインサイドセールスにそのまま渡せることです。 印の付いた記録を一覧にし、どの質問で印が付いたかを原文で見られます。

3つ目は、includes_next_invite で同意の扱いを検査できることです。 consent が no なのに真なら、Paths で本文を書かずに担当へ回します。

参加者の表に書く項目は次のとおりです。

システムへ連携する

Gmail の送信は、承認の印が付いた記録だけです。 Zapier の Gmail のページでは、Send Email は件名と本文を必須とし、宛先・返信先・署名などを指定できる送信の操作です。本文は、担当が直したあとの参加者の表の値を使います。 Updated Record のトリガーが返す値なので、直した本文がそのまま送られます。

1回150人を Gmail で送るのが重いなら、メール配信の仕組みに渡します。 その場合は、承認済みの記録の件名と本文をメール配信の仕組みに渡す形にし、Zap ③の送信だけを差し替えます。 作り分けと承認の部分は同じです。

人が確認する

担当が、参加者の表で全件の本文を読みます。 区分ごとに並べると、似た本文が続くので速く読めます。

1. 質問のある記録を先に読む … 当日の回答の写しが原文どおりか、回答の案が資料に沿っているかを見ます
2. deferred_questions の担当を決める … 製品の担当に回す質問に、期限を付けます
3. 料金・予定の表現がないかを見る … 「予定」「検討」「〇円」が本文にあれば消します
4. 区分ごとに流し見る … 質問の無い記録は、宛名と区分が合っているかだけを見ます
5. 承認の印を付ける … 付けた記録から送られます

1番目に時間を使い、4番目は速く進めます。 質問の無い記録は本文の形がほぼ同じで、数秒ずつで確かめられます。 時間がかかるのは、質問のある2割ほどです。

インサイドセールスは、sales_flag の付いた記録をその日のうちに見ます。 印は AI が質問の文から付けたもので、商談の対象とするかはインサイドセールスが決めます。

例外に対処する

上から4行目が、運用を始めた最初の月に起きやすいものです。 担当が交代した回で、送る順を忘れます。表の名前に「①質問」「②参加者」と番号を付けておくと、順を取り違えにくくなります。

記録を残す

• 書き出した CSV の元のファイル（回ごと）
• 参加者の表と質問の表（回の番号ごと）
• AIの下書きと、担当が直したあとの本文（直す前の値は別の項目に残す）
• deferred_questions と、答えた担当・答えた日
• sales_flag の付いた記録と、インサイドセールスの対応
• 承認した人、送信の日時、送信の結果

3つ目で直す前の値を残すのは、指示を直す材料にするためです。 担当が毎回同じところを直しているなら、それは指示か資料に戻すべき直しです。

5つ目は、印の付け方を見直す材料になります。 印を付けたのに商談にならなかった記録が多ければ、印の条件を絞ります。