フォーム受付を表と通知へつなぐ前に：項目と状態の設計

最初に、回答の保存先を一つ決める

Google公式の回答保存ガイドを参考に、フォームとリンクするスプレッドシートを確認します。既存一覧を使う場合も、試行中は本番とは別のフォームと表を用意すると、試験回答を顧客データと区別できます。

受付担当者が「どの一覧が正しいか」を答えられることが先です。チャット、メール、表の三か所に同じ内容を持たせるなら、更新元と確認場所を決め、コピーごとに状態を編集する運用は避けます。

項目は受付に必要なものへ絞る

設計例では、受付ID、受付日時、種別、担当、確認状態を管理します。氏名やメールアドレスは業務上必要な場合だけ集めます。問い合わせ本文に不要な個人情報を書かない案内も用意してください。

通知は、保存を確認してから出す

設計する順序は、入力を受け取る、必須項目を検査する、一覧へ記録する、通知する、です。通知には受付IDと必要最小限の概要を載せ、詳細は閲覧権限のある保存先で確認する形を候補にします。

通知先へ送る前に、架空の正常入力、項目不足、同じ受付IDの再入力を試します。項目不足を空欄のまま通すか、保留するかも決めておきます。実装できる機能は利用するアプリごとに確認が必要です。

一覧の状態と通知の状態を分ける

表への保存が成功し、通知だけが失敗する場合があります。この時に受付全体をやり直すと、同じ回答を二重登録する可能性があります。保存済みかと通知済みかを別々に追える設計にします。

例えば、保存済み・通知未確認という状態なら、受付IDで記録を探してから通知を確認します。通知を再送する必要があるかは、相手側の履歴も見て判断します。失敗したという表示だけで、未送信とは決められません。

フォームと一覧の権限を別々に確認する

Google公式ガイドには、フォームとリンク済みシートの権限変更が自動同期されない場合があると説明されています。担当替えの際はフォーム側だけでなく、保存先の共有範囲も確認してください。

• 回答を読む人と、項目を変更する人を分ける
• 保存先を知っているだけで閲覧できる設定になっていないか確認する
• 通知から開くリンクを、実際の担当者の権限で確かめる
• 不要になった共同編集者を双方のファイルで確認する

本番化の条件を記録する

Make公式「Schedule a scenario」は、実行間隔などの設定を説明しています。受付をいつ検知するかと、担当者がいつ対応するかは別です。翌営業日の確認でよい仕事に、常時の即時処理が必要かを考えます。

まずは架空データで、入力件数と保存件数、保留件数、通知済み件数が説明できる状態を目指します。通知が来るから安心という感覚ではなく、受付IDから保存と対応の経過を追えることを完成条件にしましょう。

ここまで確認できたら、次へ

• 正しい保存先は一つか
• 不足入力の扱いがあるか
• 保存と通知を別に追えるか
• フォームと表の権限を確認したか

確認できない項目は理由と確認先を残します。説明例の結果を、自分の環境で確かめた結果へ置き換えないでください。