自動受付メールを人の返信として数えない営業集計

自動受付メールは、人が回答した件数や関心を示した企業数へそのまま加えません。原文と必要なヘッダーで自動受付、不在、人の回答、判定保留を分け、同じ企業の複数の受信をどの単位で数えるかを先に決めてください。

受信件数と人の回答を別の数値にする

最初に、報告したい数値の意味を定義します。受信した全メッセージ、人が回答したメッセージ、回答した相手の人数、回答した企業数は異なります。自動受付を含む受信件数は、その定義で残せます。ただし人が反応した数という名前へ置き換えません。相手の用件を扱う作業と、営業報告の集計単位を決める作業を分けてください。

集計票には、対象の送信群、対象期間、受信を確認する締め時点、使う定義を残します。後から届く返事をいつ反映するかも決めます。数字をよく見せるため、不在通知が来た企業だけ元の対象から外さないようにします。送信対象と受信イベントは別の集合であり、返信の分類を変えても当初の対象が自動的に変わるわけではありません。

返信ありというツールの表示が、何を数えているかも確認します。受信を検知しただけの状態か、人の回答と判断した状態かが分からなければ、定義未確認と残します。表示名だけで関心ありへ進めないでください。自動受付から人の回答へ変わったように見える場合も、後で別のメッセージが届いたのか、同じものの分類が変わったのかを区別します。

原文とヘッダーから判定の根拠を選ぶ

判定票の一行は、受信の参照、対応する送信、会社の参照、本文の要点、必要なヘッダー、分類、根拠、確認者です。原文には今回の質問への具体的な回答があるか、単なる受付番号か、不在期間の案内かを読みます。氏名や署名があるだけでは、人がその場で書いたと証明できません。人が定型文を使うこともあるため、文章の似方だけでも断定しません。

RFC3834は自動応答を扱い、Auto-Submittedというヘッダーを説明しています。自動応答に使われるauto-repliedと、自動生成のauto-generatedは異なる値です。確認できる値はそのまま残し、意味の範囲で扱います。本稿は受信ツールが全て同じ実装をしていると保証するものではありません。原文と実際に取得できる情報を照合し、矛盾があれば判定保留にします。

ヘッダーが見つからないことを、人の回答である証拠にはしません。件名の自動返信らしい語も手掛かりであり、常に決定的な判定規則ではありません。必要な情報を取得できない場合は、その限界を残します。生のメールを全員へ転送するのではなく、報告には必要な根拠と、権限を限定した参照先を用い、無関係な個人情報を広げないでください。

分類と購買の関心、企業の照合を切り離す

作業用の分類として、自動受付、不在通知、人の回答、判定保留などを定義できます。これは編集上の運用例であり、全ての会社やCRMが使う標準ではありません。配信エラーなど別の種類の通知は、必要な担当へ回す区分を持ちます。分類できないものを、集計に都合のよい人の回答へ押し込まないことが重要です。

人の回答が確認できても、関心ありとは限りません。連絡不要、担当外、内容への質問、資料の受領など、回答の意味は別に読みます。関心の集計を行うなら、どんな発言をその条件に入れるかを決めます。丁寧な文や短い了承から予算と決裁を推測しません。曖昧な返事の意味を扱う分類表と、自動か人かを扱う今回の判定票は分けて参照できます。

企業単位で数える場合は、既存の確認済みの企業参照に受信を結び付けます。同じドメインの全てを一つの企業とせず、同名の別法人やグループの関係も必要な範囲で確認します。企業の一致が分からなければ未照合と残します。今回の集計のために無理に法人を統合し、複数の独立した会社を一件へ変えることは避けてください。

架空の五件で、受信と企業数を数え直す

以下の受信、会社、件数は全て架空です。送信対象の企業A、B、Cに対し、Aから自動受付と後日の人の質問が一件ずつ、Bの同じ担当から人の回答が二件、Cから不在通知が一件届いたとします。受信イベントは五件です。人の回答のメッセージは三件で、人の回答を確認できる企業はAとBの二社になります。実際の配信や測定を示す例ではありません。

判定票では、Aの自動受付はそのまま自動受付として残し、後日の質問を別の人の回答として関連付けます。Bの二件は二つのメッセージですが、企業単位の同じ集計では一社です。Cは不在通知だけなので、人の回答企業数へ入れません。ただし、当初の送信対象企業からCを削って結果をよく見せることはしません。どの数値の定義を使ったかを併記します。

対照の架空ケースでは、一件の本文とヘッダーが確認できず、ツールには返信ありとだけ表示されています。この一件は判定保留です。人の回答の推定割合を足して報告しません。後で根拠が得られたら新しい判断を記録し、最初から人の回答と分かっていたように履歴を変えないでください。保留も報告の読者が理解できる状態として残します。

修正の対象行と報告の版を確定する

分類の誤りが見つかったら、元の分類、変更後、根拠、確認者、変更日を記録します。一件の自動受付を見つけたことだけで、同じ会社から来た全てのメールを自動と決めません。どの範囲を見直す必要があるかを限定します。ツールの分類規則を変える場合も、それが過去のどの行へ影響するかは、実際のデータと権限を持つ担当が確認します。

報告の修正版には、対象期間と締め時点、集計単位、修正した行、判定保留の件数を残します。分類修正で数字が下がったことと、相手の行動が変わったことは別です。前回より反応が悪くなったと結論づける前に、定義や判定の違いを確認します。メッセージ数を企業数へ変えた比較も、同じ基準の増減として扱わないでください。

確認者同士で判断が割れたら、原文と必要な根拠へ戻ります。多数決で不明な受信を人の回答へ確定するのではなく、どの情報が足りないかを示します。少数の確認例から分類器全体の精度を測ったとの主張もしません。実際の評価方法と母集団がない限り、判定精度や改善率の数値を作らないようにします。

集計の修正と次の営業作業を別に引き継ぐ

不在通知を人の回答から外したら、期間中の連絡をどう扱うかは別の業務判断です。受付メールなら、受付された範囲と誰の回答を待つかを確認します。報告の分類を直したことで予約送信も止まったとは限りません。必要な運用変更には担当を付け、実際に処理した結果を照合します。人の回答ではなかったから再送してよい、という許可にも読み替えません。

今回の完成物は、根拠付きの判定票と定義をそろえた集計です。共有窓口から名乗った人を記録する記事や、不在通知から転記する情報を選ぶ記事とは判断が異なります。LDMへ返信集計を相談する場合は、現在の数値の定義と確認できない範囲を示してください。自動返信の完全検知、人の意図の自動認定、送信許可の判断を保証する機能は確認していません。

一次資料、確認日2026年10月18日：RFC3834「Recommendations for Automatic Responses to Electronic Mail」 https://www.rfc-editor.org/rfc/rfc3834.html 。自動応答とAuto-Submittedの説明のみを参照します。全ての受信環境での実装や判定精度を保証しません。判定票、集計方法、件数と全ての例は編集上の提案と架空例です。

実際には無料の受信トレイ到達テスト（check.live-direct-marketing.online）で確認できます。

よくある質問