フォームの項目変更で自動化を壊さない｜名称・選択肢・必須項目の移行

表示名と内部の項目を分ける

「問い合わせ内容」を「相談内容」へ変えても、接続先が同じ項目を参照し続けるか確認します。表示順を入れ替えて列番号で読む処理がずれる場合もあるため、フォームの項目、受信データのキー、台帳の列、通知文の差し込みを一列の対応表へまとめます。削除する前に旧項目の保存値を数件確認し、未回答と空文字を同じ意味として扱うかも決めておきましょう。単なる文言変更とデータ形式の変更を別の作業にすると、問題の場所を追いやすくなります。

選択肢の変更には変換表を用意する

問い合わせ種別の「その他」を「導入相談」と「契約変更」へ分ける場合、過去の「その他」をどちらへ移すかは自動では決まりません。旧値を残す欄と新分類を記録する欄を分け、判定できない回答は確認待ちにします。選択肢の表記揺れや複数選択の区切りも変換表へ書き、通知条件が一致しない回答を黙って捨てないようにします。集計を比較するときは分類方法が変わった日を示し、変更前後の件数を同じ定義として説明しないことも必要です。

旧形式の回答を受け取る期間を決める

公開中のフォームを開いたままの利用者や、別のページへ埋め込まれたフォームから旧形式が届くことがあります。切り替え後もしばらくは旧キーを受け付け、受信形式を識別して同じ台帳形式へ変換する設計にします。識別できない形式は保存して担当者へ知らせ、無理に通常処理へ流しません。互換期間の終了は日付だけで決めず、埋め込み先の更新と旧形式の到着状況を確認して判断します。フォームの新旧を区別できない場合は、専用の受付先を分ける方法も検討できます。

通知と担当振り分けまで試す

テストは「送信できた」で終わらせず、台帳の値、担当者、返信に必要な情報、通知文を照合します。新しい選択肢、旧選択肢、空欄、長い文章を含む架空の回答を用意し、それぞれの期待結果を先に書きます。通知を実際の顧客へ送らない検証先を使い、フォームの送信完了画面だけでは後続処理の完了を判断しません。失敗したときに受付番号から回答を探せるかも確認し、入力内容を修正して再実行する手順まで一度通しておきます。

変更日は受付件数を突き合わせる

変更の前後で、フォーム側の受付数と台帳側の登録数を比べます。台帳にない受付は再処理候補、複数ある受付は重複候補として、同じ受付番号を基準に調べます。単純な総数の一致だけでは、二件の欠損と二件の重複が相殺されるため十分ではありません。作業を急いで旧フォームを削除するより、旧回答の書き出しと変更内容の控えを先に残します。公開後の確認担当と、異常を見つけたら元の受付へ戻す条件も決めておきましょう。

変更記録を次の担当者へ残す

変更記録には、新旧の項目対応、変換できない旧値、切り替え時刻、確認した受付番号、残っている例外を記載します。フォームの編集者が変わっても、何を残し何を廃止したか分かる状態が完成です。今回の変更で対象外だった通知や集計も明記し、後から「全部対応済み」と誤解されるのを防ぎます。次の変更ではこの記録を出発点にし、旧形式を受け付ける処理を残し続ける必要があるか見直します。受付全体の設計とフォーム製品の違いは、関連ガイドで確認できます。

• 問い合わせフォームを自動化する｜受付から担当者の対応まで
• TallyとTypeformを比較｜250件の申込みを受付後まで確認