問い合わせの初回対応時間を設計する手順と判断基準
問い合わせへの初回対応時間をどう決め、どう運用するか。対応時間の定義、問い合わせ種別ごとの目標設定、担当割り当て、計測と改善のループ、よくある失敗までをBtoBマーケティング責任者向けに整理します。
公開 2026年10月4日
結論：初回対応時間は「速さ」ではなく「設計」の問題
初回対応時間は、努力目標ではなく運用ルールとして設計する対象です。設計すべき要素は、起点の定義・種別ごとの目標時間・一次対応の担当・不在時の代替経路の4つです。この4つが決まっていない組織では、担当者の勤務状況によって対応時間がばらつきます。
「速く返そう」という号令だけでは、対応時間は安定しません。誰が、どの問い合わせを、何分以内に、何を返すのかを文書化して初めて運用になります。本記事では、その設計手順と判断基準を整理します。
※本記事は2026年10月時点の情報をもとに作成しています。
初回対応時間とは
初回対応時間とは、見込み顧客が問い合わせを送信してから、自社の担当者による最初の個別応答が届くまでの経過時間を指します。英語では First Response Time と呼ばれます。
重要なのは「個別応答」という条件です。自動返信メールは初回対応に含めません。自動返信は受付確認であり、相手の問い合わせ内容に答えていないためです。
混同しやすい指標との違い
| 指標 | 計測の起点と終点 | 主な用途 |
|---|---|---|
| 初回対応時間 | 問い合わせ送信〜最初の個別応答 | 一次対応の運用管理 |
| 商談設定までの時間 | 問い合わせ送信〜日程確定 | 営業プロセスの管理 |
| MQL引き渡し時間 | MQL判定〜営業への受け渡し | マーケ・営業間の連携管理 |
3つを混ぜて1つの数字で語ると、どこが詰まっているのか判断できなくなります。分けて計測します。
設計手順1：問い合わせを種別に分ける
最初に行うのは、問い合わせの種別分けです。すべての問い合わせに同じ目標時間を設定すると、優先度の高い問い合わせが埋もれます。
種別は、フォームの選択肢と記入内容から機械的に判定できる粒度にします。判定に人の解釈が必要な分類は、運用時に揺れます。
| 種別 | 判定の手がかり | 一次対応の性格 |
|---|---|---|
| 商談希望・デモ依頼 | フォームの目的欄、価格や導入時期への言及 | 担当営業が個別に返答 |
| 機能・仕様の質問 | 具体的な機能名、連携製品名 | 根拠資料を示して回答 |
| 資料請求・情報収集 | 目的欄が「情報収集」、記入量が少ない | 一次対応は定型＋追加質問 |
| 既存顧客からの問い合わせ | 既存ドメイン、契約IDの記載 | サポート経路へ振り分け |
| 採用・取材・営業提案 | 件名や本文のキーワード | 対象外として別経路へ |
対象外の振り分けを先に設計しておくと、営業が本来対応すべき問い合わせに集中できます。
設計手順2：種別ごとに目標時間を決める
目標時間は、種別ごとに別々に設定します。一律の数字は、守れないか、緩すぎるかのどちらかになります。
目標時間を決める判断基準は3つあります。第一に、見込み顧客が他社にも同時に問い合わせている可能性の高さ。第二に、回答に社内確認が必要かどうか。第三に、一次対応を定型文で成立させられるかどうかです。
| 種別 | 営業時間内の目標 | 営業時間外の扱い |
|---|---|---|
| 商談希望・デモ依頼 | 当日中に個別返信 | 翌営業日の始業後に最優先 |
| 機能・仕様の質問 | 当日中に一次回答 | 翌営業日中に一次回答 |
| 資料請求・情報収集 | 翌営業日中 | 翌営業日中 |
| 既存顧客 | サポート契約の規定に準拠 | 同左 |
数字そのものより、「守れる数字を宣言し、守れたかを数えること」が重要です。達成できない目標を掲げると、計測自体が形骸化します。
設計手順3：担当の割り当てと一次対応の型
目標時間は、担当が一意に決まって初めて守られます。「気づいた人が対応する」という運用は、誰も対応しない状態を生みます。
割り当てルールは、問い合わせ種別・担当エリア・既存取引の有無の順で分岐させるのが扱いやすい構成です。分岐が4段を超えると、運用側が覚えられなくなります。
未対応を検知する仕組み
- 割り当てから一定時間が経過しても一次対応が記録されていない場合に、上長へ自動通知する
- 担当者の不在予定を登録し、不在期間は自動的に代替担当へ回す
- 週次で「目標時間を超過した件数」と「超過理由」を一覧で確認する
超過理由は、個人の怠慢ではなく原因の分類として記録します。「回答に必要な情報が社内になかった」「振り分け先が誤っていた」といった分類が、次の改善点になります。引き渡しの取り決め全般はMQLの引き渡しSLAの設計でも整理しています。
一次対応に含める要素
速く返すだけでは、やり取りの回数が増えるだけです。一次対応に何を含めるかを、種別ごとにテンプレート化します。
- 問い合わせ内容の要約（自分の言葉で言い換える）
- 質問への直接的な回答、または回答できる時期の明示
- 根拠となる資料やページの提示
- 次のアクションの提案と、相手が選べる選択肢
テンプレートは「穴埋め」ではなく「構成の型」として配ります。穴埋め型は、文面が機械的になり、質問に答えていない返信を量産しがちです。
回答の正確さを保つには、何を根拠に答えてよいかの範囲を決めておく必要があります。考え方はAIの回答範囲を統制する設計で扱っています。
よくある失敗のパターン
初回対応時間の設計でつまずく型は、おおむね次の5つに分類できます。
全種別に一律の目標を置く。 守れない目標は無視されます。種別ごとに分け、守れる水準から始めます。
自動返信を初回対応に数える。 数字は良く見えますが、実態は改善しません。個別応答のみを計測対象にします。
計測の起点が揃っていない。 フォーム送信時刻、CRM登録時刻、通知受信時刻が混在すると比較できません。起点は1つに固定します。
平均値だけを見る。 平均が目標内でも、長時間放置された件が隠れます。超過件数と最長時間を併せて見ます。
営業時間外の設計がない。 夜間や週末の問い合わせが翌週に流れます。営業時間外の受付方針を明文化し、始業後の処理順序を決めます。
イベント起点のリードは滞留しやすいため、ウェビナー後72時間のフォロー設計も併せて確認してください。
この進め方が向いていないケース
初回対応時間の厳密な設計が適さない場面もあります。
第一に、問い合わせ件数が月に数件程度の段階です。この規模では、ルール整備より1件ずつの丁寧な対応のほうが現実的です。仕組み化はボトルネックが見えてから行います。
第二に、問い合わせの大半が既存顧客のサポート依頼である場合です。サポート契約の応答規定が別にあるため、新規問い合わせの設計とは分けて扱います。
第三に、そもそも問い合わせが来ていない場合です。対応時間を縮めても、母数がなければ何も変わりません。この場合は流入とLPのCVR改善が先です。
第四に、商材が高額かつ検討期間が年単位の場合です。初回対応の速さより、回答の内容と担当者の専門性が重視されます。
よくある質問
初回対応時間は短ければ短いほどよいのでしょうか。
短さと内容の質はトレードオフになり得ます。質問に答えていない即時返信は、やり取りを増やします。「回答を含む一次対応」を基準に時間を設計してください。
営業時間外の問い合わせはどう扱うべきですか。
受付方針を明文化し、計測上は営業時間ベースで換算する方法が一般的です。合わせて、翌営業日の処理順序を事前に決めておきます。
自動返信は不要ということでしょうか。
受付確認としては有効です。ただし初回対応の計測には含めません。自動返信には、次に何がいつ起きるかを明記します。
計測はどのツールで行えばよいですか。
MAとCRMのどちらかに起点と一次対応の時刻を揃えて記録できれば十分です。ツールの新規導入より、起点の定義を1つに固定することを優先します。
目標時間を守れない月が続く場合はどうしますか。
目標を緩めるか、割り当てと一次対応の型を見直すかを選びます。超過理由の分類を集計し、人員の問題か設計の問題かを切り分けてください。
まとめ
初回対応時間の設計は、種別分け・目標時間・担当割り当て・一次対応の型という4点に集約されます。
まず起点の定義を1つに固定し、自動返信を計測から外します。次に種別ごとに守れる目標を置き、超過件数と最長時間を週次で確認します。超過理由を分類して記録すれば、改善すべき箇所が自然に浮かび上がります。
費用面からの検討はAI商談ツールのCPLとROI、関連する考え方はナレッジ記事一覧にまとめています。
UniAgentは、Webサイト上で登録資料を根拠に説明・ヒアリングを行い、その内容を文脈付きで担当者へ引き継ぐAIです。