商談・デモの予約に来なかった見込み客を予約ツールから拾い、申込のときの回答に合わせた再調整のメールを下書きして担当者が送る

処理の起点を決める

担当者が Calendly で no-show の印を付けたことを起点にします。 Zapier の Invitee No Show Created のトリガーが、その印を拾います。時刻で決めて自動で no-show と判断する作りにはしません。 第5章の1番目のとおり、来たかどうかを知っているのはその場にいた担当者だけです。

印を付ける時機は、デモの終了予定の時刻までと決めます。 10分待って来なければ退出し、その場で印を付けます。印が翌日に回ると、下書きも翌日になり、第3章の（a）が残ります。

Calendly 側の自動化と二重にならないようにします。 Calendly にも no-show の人へ再予約を促すメールを送る機能があります。両方を動かすと、相手には定型文と下書きから送ったメールの2通が届きます。 この Zap を使う予約の種類では、Calendly 側の no-show 向けの自動化を止めておきます。

印を取り消したときの扱いも決めておきます。 誤って付けた印を取り消しても、作られた下書きは残ります。下書きは送らずに削除し、商談の管理表の状態を担当者が直します。 取り消しを拾って下書きを消す作りは、最初は作りません。

入力データを集める

質を決めるのは、いちばん下の話題の材料です。 困りごとに触れるといっても、AIに自由に書かせると「御社の課題を解決できます」のような中身の無い一文になります。「締めの集計が遅い」なら「月末の集計画面を5分でお見せします」のように、社内で用意した一言を困りごとの種類ごとに表にしておき、そこから選ばせます。

Calendly の招待者の情報には、予約フォームの回答（questions_and_answers）、再予約と取消のURL、no-show の記録が含まれます。 回答は質問・答え・並び順の組で入っています。

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

no-show の記録だけでは、フォームの回答がそろわないことがあります。 Calendly の開発者向けの FAQ でも、Webhook で届く情報は招待者のすべてを含まないので、招待者のURIから招待者の情報を取り直すよう案内されています。 Zapier では、トリガーで届いたメールアドレスで Find Invitee by Email を呼び、予約の日時が一致するものを選びます。

商談の管理表は、Lookup Spreadsheet Row で引きます。 検索の列はメールアドレス、補助の検索の列は予約の日時です。同じ人が何度か予約していると、メールアドレスだけでは古い予約の行に当たります。 補助の検索で、両方の条件に合う行だけを取ります。行が無ければ「行が無い場合に作る」の設定で新しく作ります。

予約ページのURLは、文面の決まりの表から取ります。 URLの末尾に utm_campaign=noshow_rebook を付けておくと、再予約がこのメールから来たかを Calendly の予約の記録で見分けられます。 Calendly の FAQ では、独自の値を予約に渡すには UTM パラメータを使え、その値は Webhook の内容や招待者の一覧の tracking に入るとされています。

元の予約の再予約のURLは使いません。 招待者の情報には再予約のURLが含まれますが、開始時刻を過ぎた予約のURLが使えるかは確かめられていないためです。 予約ページそのもののURLを使います。

AIへ渡す前に整形する

1. 回数を数える … 商談の管理表から、この人の no-show の回数を数えます。1回目だけをAIに渡し、2回目以降は Filter で止めて担当者に知らせます
2. 回答の形をそろえる … questions_and_answers を「質問：答え」の行に並べ直します。空の回答は「回答なし」とします
3. 不要な情報を外す … 電話番号など、文面に要らない回答はAIに渡しません
4. 困りごとの種類を付ける … 自由記述の「困っていること」から、話題の材料の表の種類を1つ選ぶのはAIの仕事にし、表に無い種類は作らせません
5. 担当者の名前と署名を付ける … 商談の管理表の担当者から、署名の形をそろえます

1番目で2回目以降を止めるのが、第3章の（d）への答えです。 2回続けて来なかった人に何を送るか、送らないかは、担当者が商談の管理表のメモを見て決めます。

3番目は、外へ出す情報を減らすための処理です。 文面に使わない情報は、AIにも渡しません。

AIに処理させる

させるのは、再調整のメールの件名と本文を作り、どの回答を話題にしたかを書くことだけです。

「来なかった理由に触れない」がいちばん大事な決まりです。 「お忙しかったかと存じますが」「URLが分かりにくかったでしょうか」は、どちらも推測です。当たっていなければ相手は居心地が悪くなり、当たっていても指摘されたことになります。

4行目は、AIが製品の機能を作り話で書くのを防ぐためです。 困りごとに応えようとすると、AIは「ワンクリックで給与計算と連携できます」のようにありそうな機能を書きます。 話題の材料の表にある一言だけを使わせます。

指示内容を固定する

あなたは勤怠管理の SaaS の会社のインサイドセールスの担当者です。
デモの予約に来られなかった方へ、もう一度デモの日程を選んで
いただくためのメールの件名と本文を作ってください。
与えられた情報だけを使ってください。

【書き方】
- 書き出しは、文面の決まりの書き出しから1つ選んでください。
- 予約フォームの「困っていること」から、話題の材料の表の種類を
  1つ選び、その種類の一言を本文に入れてください。
  どれにも当てはまらない、または回答が無い場合は topic_type を
  generic にし、話題を入れないでください。
- 予約ページのURLと、デモの所要時間を書いてください。
- 本文は全体で300字程度、段落は3つまでにしてください。
- 署名は与えられた署名をそのまま使ってください。

【厳守事項】
- 来られなかった理由を推測して書かないでください。
  「お忙しかったかと」「分かりにくかったでしょうか」のような
  言い回しも使わないでください。
- 来られなかったことを責める、残念がる言い回しを使わないで
  ください。
- 値引き、特典、期限を書かないでください。
- 予約フォームに書かれていない困りごとを足さないでください。
- 話題の材料の表に無い機能、事例、数字を書かないでください。
- 日時を指定しないでください。予約ページから選んでいただく
  形にしてください。

【予約フォームの回答】{answers}
【予約していたデモの日時と種類】{event}
【文面の決まり】{style_rules}
【話題の材料の表】{topic_materials}
【予約ページのURL】{booking_url}
【担当者の署名】{signature}

「残念がる言い回し」まで禁じるのは、「お会いできず残念でした」が丁寧なつもりで書かれやすいからです。 書いた側は気遣いのつもりでも、読む側には「来なかったこと」を改めて突きつけられる一文です。

本文の長さを書いておかないと、AIは製品の紹介を足して長くします。 再調整のメールの役目は、予約ページを開いてもらうことだけです。

出力形式を固定する

AI by Zapier の出力の項目として、次のものを定義します。

{
  "subject": "",
  "body": "",
  "topic_type": "closing_delay | overtime_check | shift_management | paper_timecard | generic",
  "used_answer": { "question": "", "answer": "" },
  "needs_review": false
}

1つ目の理由は、件名と本文を別の項目で受け取れることです。 Gmail の Create Draft の件名と本文に、そのまま割り当てられます。

2つ目は、topic_type で話題の種類が後から数えられることです。 どの困りごとの人が再予約しやすいかを、商談の管理表で月ごとに数えられます。 話題の材料の表を見直す材料になります。

3つ目は、used_answer で担当者の確認が速くなることです。 下書きを読む前に、どの回答を拾ったかが分かります。 回答と本文の話題が合っているかを、一目で確かめられます。

Zap の側では、受け取った後に次の確認をします。

topic_type を決まった値に絞るのは、話題の材料の表と1対1で結び付けるためです。 表に無い種類をAIが作ると、本文に入る一言の出どころが無くなり、製品に無い機能を書く入口になります。 種類を足すときは、表に行を足してから出力の選択肢を足します。

needs_review が立っても、下書きは作ります。 件名の先頭に「【要確認】」を付け、担当者が直してから送ります。

システムへ連携する

Gmail の接続は、担当者ごとに分けます。 下書きは、接続した Gmail のアカウントに保存されるためです。Zap の中で担当者ごとに分かれ道を作り、その担当者の Gmail の接続で Create Draft を動かします。 共有のアドレスから送ると、相手から見て誰からのメールか分からなくなります。

Send Email のアクションは置きません。 Gmail のアクションには送信もありますが、この構成では下書きまでにします。 送信の上限を超えるとアカウントが最大24時間止まることがある、と Zapier のヘルプにもあります。

人が確認する

1. 件名に「【要確認】」が付いたものを先に見る … URL の抜けや禁止の言い回しを直します
2. used_answer と本文の話題を見比べる … 回答の読み違いがないかを確かめます
3. 自分の言葉で一文を足すかを決める … デモの前にやり取りがあった相手なら、そのことに触れます
4. 送る … 印を付けてからできるだけ早く、遅くとも当日中に送ります
5. 2回目の no-show の知らせを見る … 下書きは作られていません。電話にするか、連絡をやめるかを決めます

3番目が、下書きを人が送る理由です。 予約の前に電話で話していた、資料を送っていた、という経緯は商談の管理表のメモにしか無く、AIの下書きには入っていません。 担当者が一文を足すだけで、定型文との差がはっきりします。

4番目の「当日中」には理由があります。 相手がデモの時刻を空けていたのなら、その日のうちはまだデモのことを覚えています。翌日以降のメールは、ほかの営業メールに埋もれやすくなります。 下書きを夕方にまとめて送るのではなく、デモの合間に1件ずつ送る運用にします。

目標は、120件をならして1件5分です。 回答を読み直し、メールを書く時間が下書きを読む時間に置き換わります。

例外に対処する

最後の行は、商談の管理表に「連絡不要」の列を持たせて実現します。 前のやり取りで連絡をやめてほしいと言われた人には、no-show でも下書きを作りません。

記録を残す

• no-show の記録（予約の日時、担当者、印を付けた日時）
• AIに渡した回答とAIが返した項目（subject・body・topic_type・used_answer）
• 担当者が送った文面（下書きからどこを直したか）
• 送った日時と、再予約の有無（utm_campaign で見分ける）
• 2回目以降の no-show で担当者が選んだ対応

3つ目の「どこを直したか」が、文面の決まりと話題の材料の表を直す材料になります。 同じ箇所を何人もの担当者が直していれば、表の側が現場に合っていません。