自社サイトから試供品・サンプルを請求した企業に、到着後の感想と次の検討の段取りを尋ねるフォローメールを時期をずらして下書きする

処理の起点を決める

サンプル請求のテーブルで、到着予定日の欄が更新されたことを起点にします。 Zapier Tables では、欄の名前から Zap を作ると、その欄が更新されたときだけ動くトリガーがあらかじめ入った Zap ができます。

フォームの送信を起点にしない理由は、そこから到着までの日数が決まらないからです。 在庫の有無や物流部の都合で、請求から出荷まで2日のことも10日のこともあります。フォローの時期は請求の日ではなく、相手の手元に届いた日から数えます。

到着予定日は、物流部が送り状を出すときに運送会社の予定の日付を入れます。実際の到着日まで追わないのは、運送会社ごとに追跡の取り方が違い、それを足すと最小構成から遠くなるからです。 1〜2日のずれは、1回目を到着の2日後に置くことで吸収します。

Zap は請求1件ごとに1回動き、3回分の待機と下書きを1本の流れで持ちます。 到着予定日まで Delay Until で待ち、そこから Delay For を2日・12日・14日と重ねると、到着の2日後・14日後・28日後になります。日付の計算のステップを置かずに済むのが、この並べ方の利点です。

入力データを集める

質を決めるのは、用途と評価の予定の2つです。 「塗料の密着性の改善」「来月から試作」と書かれていれば、2回目に聞くことが具体的になります。フォームでこの2つを必須にしておかないと、下書きはどの請求にも同じ文面になります。

品番の一覧は、AIに作らせません。 特長や追加で出せる資料は、営業と技術の担当者が書いた要約を使います。品番の性能をAIに書かせると、カタログに無い数字が入ります。

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

引き直しは、毎回の下書きの直前に行います。 トリガーで受け取った値は出荷の時点のものなので、待機の後に使うと古い状態で判断することになります。 検索は請求番号の1つで行います。Zapier Tables の検索は、指定したすべての条件に合うレコードだけを見つけるとされており、条件を増やすほど見つからない原因が増えます。

見つからなかったときは、そこで止めます。 検索の設定には「見つからなければレコードを作る」という選択肢もありますが、ここでは使いません。 見つからないのは、営業事務が請求を消したか、番号を書き換えたときです。新しく作ると、存在しない請求に下書きが作られます。

AIへ渡す前に整形する

1. 日付の書き方をそろえる … 到着予定日は日付の型の欄にし、物流部が自由な書き方で入れられないようにします。Delay Until にはこの欄をそのまま割り当てます
2. 時刻を入れる … 到着予定日には朝9時の時刻を添えて入れる決まりにします。待機の解除が朝にそろい、営業が出社してすぐに下書きを確かめられます
3. 土日の扱い … 下書きが土曜・日曜にできても、送る日は営業が決めます。 相手の会社が休みの日に送っても読まれないので、月曜の朝に送ります
4. 過去の日付の確認 … 物流部が到着予定日を後から入れた場合、その日付がすでに過ぎていることがあります
5. 品番の正規化 … フォームに書かれた品番の大文字・小文字と全角・半角をそろえ、品番の一覧で引けるようにします
6. 請求の振り分けの確認 … 同業他社・個人・学生と思われる請求は、営業事務が状態を「配信不要」にしてから出荷します

4番目は、Delay Until の設定で扱いを決めておきます。 解除の日時が過ぎていたときにどこまで続けるかを、15分以内・1時間以内・1日以内（既定）・常に続けるから選べます。ここでは「1日以内」のままにします。 1週間前の日付でそのまま続けると、1回目の時期がずれ、相手が評価を始めた後に「届きましたか」と尋ねることになるからです。過ぎて止まった請求は、下の例外処理で拾います。

6番目は人の仕事です。 請求者が誰かを見て、フォローすべきかを決めるのは営業事務です。ここをAIに判定させると、名前の知られていない取引先を同業他社と取り違えます。

AIに処理させる

させるのは、その回のフォローメールの件名と本文を、請求の内容と時期に合わせて書くことだけです。 3回で尋ねることは、あらかじめ決めておきます。

右端の列が、この構成でいちばん大事な決まりです。 1回目で見積の話をすると、まだ箱を開けていない相手には押しつけに見えます。3回目で値引きや納期を書くと、営業の権限を超えた約束がメールに残ります。

4行目がいちばん起きやすい失敗です。 2回目の時点で返信が無いと、AIは「ご期待に沿えなかったかもしれませんが」と書きがちです。返信が無いのは忙しいだけのことが多く、その一文で相手の印象が下がります。

指示内容を固定する

あなたは機能性樹脂メーカーの営業担当の補助です。
自社サイトからサンプルを請求した法人のお客様に送る、フォローメールの下書きを書きます。
下の【請求の内容】と【この回の決まり】だけを使ってください。書かれていないことを推測しないでください。

【この回の決まり】
回: {round}（1, 2, 3 のいずれか）
- 1回目（到着の2日後）: 届いたか、量と荷姿に問題がないか、評価の条件と予定の時期を尋ねる。
  評価の結果や見積のことは書かない。
- 2回目（到着の14日後）: 評価の進み具合を尋ね、追加の資料や別の品番が要るかを尋ねる。
  採用するかどうかは尋ねない。
- 3回目（到着の28日後）: 評価の結果と、次の段取り（追加のサンプル、技術の打合せ、見積）のどれが
  よいかを尋ねる。値引き、納期、最小ロットについては書かない。

【厳守事項】
- 品番の性能・規格値・数値は書かないでください。資料の案内は【品番の資料】にある資料名だけを使ってください。
- 価格、納期、在庫、最小ロットについて書かないでください。
- 返信が無いことを、評価が良くなかったと解釈する文を書かないでください。
- 他社の材料や競合について書かないでください。
- 用途や評価の予定が「不明」の場合は、そのことに触れず、一般的な尋ね方にしてください。
  用途を推測して書かないでください。
- 本文は400字以内。敬語は丁寧語を基本とし、過度にへりくだらないでください。
- 返信しやすいように、尋ねることは2つまでにし、番号を付けて並べてください。
- 署名は書かないでください（Gmail の署名を使います）。

【請求の内容】
会社名: {company} / 部署: {dept} / 氏名: {name}
用途: {use_case} / 評価の予定: {eval_plan}
品番と数量: {items} / 到着予定日: {arrival_date}
自由記入欄: {note}

【品番の資料】{item_docs}
【これまでに作った下書きの件名】{past_subjects}

「返信が無いことを、評価が良くなかったと解釈しない」を明記しないと、2回目と3回目にお詫びの調子が混ざります。 指示に書かない限り、AIは返信の無さに理由を付けようとします。禁じるのは、無い情報に意味を読み込むことそのものです。

これまでの件名を渡すのは、同じ件名が3回続くのを防ぐためです。 件名が同じだと、相手のメールソフトで1つのスレッドにまとまり、3回目が前の2通に埋もれます。

出力形式を固定する

AI by Zapier の出力の項目として、次の形で受け取ります。

{
  "subject": "",
  "body": "",
  "questions": ["", ""],
  "docs_offered": [""],
  "used_unknown_fields": ["use_case | eval_plan"],
  "needs_attention": "none | free_text_has_request | free_text_has_complaint"
}

項目はどれも必須にし、型は subject と body が文字列、questions と docs_offered が文字列の並び、used_unknown_fields は「不明」として扱った欄の名前、needs_attention は3つの値のどれかです。

1つ目の理由は、件名と本文を Gmail の欄にそのまま入れられることです。 Create Draft の件名と本文にそれぞれ割り当てるだけで、文字列を切り分ける手間がありません。

2つ目は、questions と docs_offered を台帳に残せることです。 何を尋ね、何の資料を案内したかが請求ごとに残るので、次の回で同じことを聞かずに済みます。 返信の内容と並べると、どの問いに答えが返りやすいかも見えてきます。

3つ目は、needs_attention で人に知らせる請求を分けられることです。

3行目で下書きを作らないのは、定型のフォローを送ってはいけない相手だからです。 「前回のサンプルが固まっていた」と書いた相手に「届きましたか」と送ると、読んでいないことが伝わります。

システムへ連携する

Gmail へは下書きを置くだけで、送りません。 Zapier の Gmail には送信の操作（Send Email）もありますが、この構成では使いません。 送る操作を足すと、止め忘れた請求にそのままメールが届きます。

担当の営業ごとの分岐には Paths を使います。 1つのグループに最大10本の分岐を置けるので、6名の営業はそれぞれ1本ずつに収まります。どの条件にも当たらないときに動くフォールバックの分岐を1本置き、担当が空欄の請求は営業事務の Gmail に下書きを置きます。

基幹のシステムには書き込みません。 商談に進んだら、営業が今までどおり見積と案件の登録を行います。この構成が持つのは、フォローの段取りまでです。

人が確認する

下書きは全件、担当の営業が開いて確かめます。 自動で送る設計にはしません。目標は、1通あたり3分です。

1. 台帳の状態を確かめる … 電話や展示会で話した請求なら、下書きを捨てて状態を「返信あり」にします
2. 尋ねることを確かめる … questions が相手の用途に合っているかを読み、合っていなければ直します
3. 資料の案内を確かめる … docs_offered の資料を、本当に添付するか、リンクで送るかを決めます
4. 送る … Gmail の下書きから送ります。送った後に台帳の状態は変えません（返信が来たときだけ変えます）

1番目を省かないでください。 台帳に書かれていないやり取りは、営業の頭の中にしかありません。下書きを作るかどうかは台帳で決まりますが、送るかどうかは営業が決めます。

返信が来たら、状態を「返信あり」に変えることだけは徹底します。 これを忘れると、次の回の下書きが作られ、返信をくれた相手に定型のフォローが届きます。

例外に対処する

3行目と4行目がいちばん気づきにくい落とし穴です。 Zapier の Delay では、待機中に Zap のどこかを変えると、その実行は再開しても続かないとされています。止めている間に予定されていた処理も、再開後には動きません。指示の文面を1語直しただけで、待機していた請求のフォローがまとめて消えます。

対策は、台帳の側で拾うことです。 「フォローの予定日を過ぎたのに、下書きの回数が増えていない」請求を絞り込む表示（ビュー）をテーブルに作り、営業事務が毎朝見ます。Zap を直すのは月初の決まった日にし、直した日の前後はこの表示を担当の営業にも配ります。

記録を残す

• フォームの送信内容と、請求を受けた日時
• 発送日、到着予定日、同梱した資料、担当の営業
• 回ごとの下書きの日時、件名、questions、docs_offered、needs_attention
• 状態を変えた日時と、変えた人（返信あり・商談化・辞退・配信不要）
• 止めた理由（状態による停止、引き直しで見つからない、日付が過ぎていた）
• 営業が下書きを大きく直した回の記録（件名を変えた、尋ねることを差し替えた）

4つ目で「変えた人」を残すのは、止め忘れの原因を追うためです。 返信をくれた相手に定型のフォローが届いたとき、誰がいつ状態を変えるはずだったかが分からないと、同じことがくり返されます。