MakeとGoogleフォーム連携：回答を担当者へ通知する方法
Googleフォームの回答を後からまとめて確認していると、急ぎの問い合わせや社内依頼に気づくのが遅れます。Makeを使うと、フォーム回答を記録し、条件に応じて担当者へ通知できます。
活用例：回答内容に応じて通知先を分ける
- Googleフォームに回答が届く
- 回答内容を管理表へ記録する
- 「問い合わせ」「依頼」「障害報告」などの種別で通知先を分ける
- 担当者が内容を確認してから対応する
フォームの選択肢が曖昧な場合は、無理に自動振り分けせず、共通窓口へ渡します。
設計時の確認項目
- 必須にする質問と任意の質問
- 通知してよい回答内容
- 担当者が不在の場合の代替先
- 回答を削除・訂正したときの扱い
小さく試す手順
テスト回答を3種類作り、通知先、記録内容、未入力時の挙動を確認します。本番フォームを変える前に、テスト用フォームで試すと安全です。
受付IDと確認欄を先に設計する
通知だけを作ると、再送・編集・担当交代で「どの申込の話か」が分からなくなります。Googleフォームの回答IDまたは受付番号を、Makeの全モジュールと通知本文に引き継ぎます。確認欄は、受付済み・確認担当・確認日時・差戻し理由を分け、通知送信と人の確認を混同しません。
| 項目 | 入力者 | 更新タイミング |
|---|---|---|
| 受付ID | 自動 | 受信時に固定 |
| 通知送信日時 | Make | 成功時のみ |
| 確認担当／日時 | 人 | 内容確認後 |
| 差戻し理由 | 人 | 不備がある時だけ |
再実行は受付IDで既存行を検索してから行い、通知済みなら停止します。フォーム回答の内容を後から変更する場合も、原回答・修正者・修正日時を残します。これにより、Makeは配信を担当し、承認判断は人が追跡可能な形で担えます。
シナリオを四つの段階に分ける
一つのシナリオで、受信、判定、通知、記録を同時に完結させると、どこで失敗したかを追えません。まず回答を受け取る段階、受付IDを採番・検索する段階、条件により担当へ通知する段階、結果を台帳へ記録する段階を分けます。モジュールを増やすためではなく、失敗時に止める場所を明確にするためです。
| 段階 | Makeが行うこと | 保存する証跡 | 失敗時の扱い |
|---|---|---|---|
| 受信 | フォーム回答を取得 | 回答ID・受信時刻 | 未処理として台帳へ |
| 照合 | 受付IDで既存記録を検索 | 検索結果・処理回数 | 重複なら通知しない |
| 通知 | 条件に合う担当へ送信 | 宛先・送信時刻 | 要確認キューへ |
| 記録 | 状態と次の担当を更新 | 実行ID・結果 | 個別に再処理 |
通知条件は文章ではなく列で管理する
「急ぎなら営業へ」「金額が大きければ責任者へ」といった条件をシナリオ内の分岐だけに置くと、担当変更のたびに改修が必要です。優先度、担当チーム、確認要否、SLAを管理表の列として持ち、Makeはその値を読んで通知します。値の候補はプルダウンなどで限定し、空欄や未定義の値は既定の通知先へ送らず要確認にします。
| 条件 | 通知先 | 期限 | 自動で確定してよいか |
|---|---|---|---|
| 資料請求 | 営業一次対応 | 当営業日 | 可。ただし重複確認 |
| 既存顧客の変更依頼 | 担当CS | 1営業日 | 内容を人が確認 |
| 個人情報を含む相談 | 限定した担当 | 即時 | 転送先を人が確認 |
| 値が不足している回答 | 受付管理者 | 当営業日 | 不可。差戻し案内 |
テストと引継ぎのチェックリスト
公開前には、正常回答だけでなく、同じ回答の再送、必須項目が空の回答、担当が未設定の回答、通知先が無効な場合を試します。テストには実在の顧客情報を使わず、テスト用回答とテスト用宛先を用意します。引継ぎ資料には、受付IDの意味、台帳の場所、通知先の変更方法、停止手順、失敗時に一件だけ再処理する方法を記します。
通知が届くことは完了条件ではありません。受付IDから、誰がいつ何を確認し、次に誰が動くかまで追えることが、GoogleフォームとMakeを業務の入口として安全に使う条件です。