問い合わせ受付を自動化する｜保存・担当・対応漏れの照合手順

受付記録の基準を決める

最初に、問い合わせ一件が完了したと判断する条件を書きます。受信できた、台帳へ保存できた、担当者が読んだ、返信した、という状態は別です。受付番号と状態を対応させ、通知が流れたり担当者が休んだりしても、残っている問い合わせを一覧にできる台帳を基準にします。

送信ID、受付時刻、連絡先、要件、担当、状態を揃えます。通知が流れても記録が消えない構成にし、フォーム自体が保存する回答と自動化先をどう照合するかを残します。

重複と再問い合わせを区別する

同じ人が別の用件を送った場合を、重複と判定しないことが重要です。顧客の情報を更新する操作と、新しい受付を追加する操作を分けてください。確認用の入力には、同一受付の再送と、同じメールアドレスからの別受付を両方含め、作られる記録を先に決めます。

メールアドレスだけで一律に上書きすると、新しい用件を見落とすことがあります。既存顧客の更新と、新しい問い合わせの追加を別の操作として設計し、例外は担当者が確認できる状態へ置きます。

担当者へ渡す情報を絞る

担当者が行う次の行動に必要な情報だけを通知へ含めます。例えば受付番号、相談の分類、対応期限、台帳へのリンクです。チャットのチャンネルごとに本文を丸ごと複製するより、正しい閲覧権限のある台帳を参照する方が、訂正や担当交代の際に同じ情報を確認しやすくなります。

営業時間外の通知、担当不在、引き継ぎ先を決めます。通知送信に成功したことと、担当者が着手したことは別の状態として扱ってください。

製品を選ぶための同一仕様

製品選定の仕様には、フォーム受信だけでなく、顧客検索、受付の追加、担当割り当て、未対応の抽出を含めます。接続先のアプリ名が一覧にあるかだけで判断せず、必要な項目を読み書きできるかを確認します。通知と保存をどの順に実行し、途中で止まると何が残るかも比べます。

標準アクションで足りない部分は独自コードや追加サービスとして費用へ加えます。自己ホストが必要なら、保守担当を含めて比較し、単に最安表示が低い候補を選ばないようにします。

処理漏れを後から発見する

照合では、元のフォームに残る受付番号と、台帳へ登録した受付番号を比べます。単に件数が一致していても、別の受付が二重登録され一件が抜けている場合があります。未対応だけでなく、登録されていない受付、担当が空欄のもの、通知に失敗したものを別々に一覧にできるようにします。

通知が失敗しても元の受付記録から復旧できるかを、検証用のデータで確かめます。顧客へ送る返信文や対応期限を自動化する場合も、実際に守れる運営体制を先に決めてください。

月300件の受付で照合する例

月300件の想定では、担当者が一日に何回未対応を確認するか、営業時間外の受付をいつ引き受けるかまで決めます。処理量の試算には再送や復旧も加えます。受付が増えた時に担当不足を自動化の不具合と混同しないよう、登録完了までの時間と実際の返信までの時間は別々に観察します。

顧客台帳の新規行が300増えることを成功条件にせず、受付記録が300残り、それぞれ担当と状態へつながることを確認します。同じ人からの別件は残し、同じ送信の再送だけを適切に識別します。

どこで人が判断すべきかを残せば、入力を無理に全自動で処理して相談を失うことを防ぎやすくなります。

• 業務自動化ツールの選び方｜最初の仕事を決める比較手順
• 自動化ツールの費用比較｜タスク・クレジット・実行数を揃える
• Webhook自動化の選び方｜重複・順序・再実行をどう扱うか