問い合わせ管理を一元化する｜担当・返信待ち・完了の分け方

問い合わせ管理を一元化するなら、受付経路、現在の担当、誰の回答待ちか、次の回答期限を別々に記録します。担当者が応対できなくなったときは受付チームが引き取り、新しい担当者が引き受けるまで期限を管理するルールが必要です。

担当者名だけでは、顧客からの返事を待っているのか、社内確認が止まっているのかは判別できません。同じ用件への再返信は、元担当が応対できれば戻し、できなければ未割り当てとして受付チームへ渡します。別経路から同じ用件が届いた場合も、履歴と返信担当を確認してからまとめます。

F-RevoCRM、Zoho Desk、Zendeskの在席状況アプリの仕様は2026年10月3日に確認しました（参照ページに公開日・更新日の記載なし）。台帳とルールはこれらを参考にした架空の設計例であり、Cotomuの標準機能や導入実績ではありません。

問い合わせ管理の一元化で、担当と状態を分ける

電話、メール、フォームを一か所へ集めても、担当と状態が同じ欄に混ざっていれば判断は止まります。「担当者が決まっている」と「いま回答できる」は別の情報だからです。

F-RevoCRMの問い合わせ管理機能は、メール・電話・フォームからの問い合わせをチケットに統合し、担当者と「回答待ち・進行中・完了など」の状況を可視化すると説明しています。同社は、メールや口頭の管理で担当者・状況が分からなくなることを、対応漏れや重複対応の要因に挙げています。

一元化する対象は、単なる連絡先一覧ではありません。問い合わせ1件について、少なくとも次の項目を独立させます。

この分け方なら、「担当はいるが顧客待ち」と「担当が決まらず止まっている」を混同しません。担当者名は責任の所在、状態は次に動く側、期限は見直す時点を示します。

「顧客待ち」を完了にしない

返信を送った問い合わせは、処理済みに見えます。しかし、顧客の確認や追加情報を待っているなら、用件そのものは閉じていません。ここで完了にすると、顧客から返事が来たときに、新規問い合わせとして扱うのか、元の担当へ戻すのかが曖昧になります。

Zoho Deskの問い合わせステータスに関する公式説明では、ステータスの種類を未完了・保留中・完了に分け、「顧客からの返信待ち」のような独自ステータスを設定できます。標準の動作では、完了済みも含めて、顧客が返信すると未完了へ戻ります。返信時に未完了へ戻すかどうかは、ステータスの設定で変更できます。

自社で決めるのは、どの出来事で状態を変えるかです。架空の設計例として、受付チーム内の当番が未割り当てを管理する場合を考えます。

「顧客待ち」でも現在の担当を残し、返信後に確認する人を明らかにします。その担当者が応対できない場合は、受付当番へ管理責任を移します。完了後に同じ用件への返信が届いた場合も、同じ条件で戻し先を決めます。

担当不在・再問い合わせ時の扱いを決定表にする

元担当へ自動的に戻せば、経緯を知る人が続けられます。とはいえ、その担当者が応対できないなら、元担当を残すこと自体が返信漏れの原因になります。担当者を維持する原則には、解除する条件が必要です。

Zendeskの在席状況アプリに関する公式説明では、設定を有効にすると、担当者が応対不可になった際にオープンチケットの割り当てを自動解除できます。この設定は初期状態では無効です。また、保留中または待機中のチケットへ顧客が返信し、元担当者が応対不可なら、親グループへ戻して担当者を空にする挙動が示されています。

担当になれるエージェントが一人だけのグループでは、親グループへ戻らない例外もあります。利用に必要なタグ編集権限と、処理を実行するトリガの設定を確認します。更新エラーで解除できない場合もあるため、実際の担当と未割り当ての一覧まで確かめます。

自社の設計では、元担当を外すと同時に受付当番へ管理責任を移し、新担当が引き受けるまで当番が期限を確認します。担当者名を空にしただけでは、引き継ぎ完了にしません。

期限超過時に別担当者や上位ユーザーへ引き継ぐ運用例は、Zoho Deskの公式説明にも示されています。自社の台帳では、期限を変更しても以前の期限と変更理由を残し、超過していた事実を消さないようにします。

別経路の連絡をまとめるときは、受付当番が顧客、対象の取引、用件を照合します。同じ顧客というだけでは統合せず、別の用件は別IDで扱います。判断できない間は元のIDを保ち、関連付けて確認します。

同じ用件と確認できたら、統合先IDと返信担当を決め、元ID、受付経路、受信・返信履歴を残します。返信前には統合先の最新履歴と担当を確認し、統合元からは新たな回答を送らない運用にします。

二重対応と返信漏れを防ぐ運用手順

台帳を作っても、更新する順序が人によって違えば、担当と状態はすぐにずれます。問い合わせを受けてから完了するまでの操作を、次の順序にそろえます。

1. 受信時に、問い合わせIDと受付経路を記録する。同じ用件らしい記録があれば、担当を増やす前に既存の履歴を確認する。
2. 現在の担当を一人決め、同時に次の回答期限を置く。新担当が引き受けるまでは、受付当番が未割り当てとして管理する。
3. 回答や確認を行ったら、履歴だけでなく状態も更新する。顧客へ返事を求めた場合は、完了ではなく顧客待ちにする。
4. 同じ用件への返信は、元担当が応対可能なら対応中へ、応対できなければ受付当番が管理する未割り当てへ戻す。
5. 次の回答期限を過ぎた問い合わせは、状態と担当を確認する。継続する場合も、期限だけを先送りせず、担当を維持する理由か変更理由を残す。
6. 完了にする前に、顧客待ちや社内待ちが残っていないことを確認する。完了後の再返信にも、決定表を適用する。

これで、重複回答を避ける確認点は「問い合わせIDと現在の担当」、返信漏れを探す確認点は「状態と次の回答期限」に分かれます。すべてを一つのステータス名へ詰め込まないことが、運用判断をそろえる土台です。

既存の表計算から移す場合は、先に列を増やすより、Excelから業務システムへ移行する際の考え方と照らし、どの記録を引き継ぐかを整理します。既製サービスと個別開発の選択から検討する場合は、SaaS・kintone・独自開発の比較も判断材料になります。

不在中の再返信を試して、引き継ぎ先を確かめる

試作では、顧客待ちの問い合わせに返信を入れ、元担当が応対できる場合とできない場合を比べます。前者は元担当の対応中へ、後者は受付当番が引き取る未割り当てへ戻るか。新担当が引き受けるまでの管理責任と、次の回答期限も確認してください。完了後の再返信にも同じ確認を行います。

別経路から届いた連絡も試します。同じ用件なら、元の履歴と未対応の期限を残して返信担当を一人に絞れるか。別の用件や判定できない連絡は、統合せずに残せるか。再返信と重複受付の両方で、この条件を満たすことを試作の合格基準にします。

台帳を共有するだけでは、同時送信は止められません。複数人が同時に引き受け・送信を試みる場面でも、担当を一人に確定し、送信直前に担当や返信履歴が変わっていたら送信を止められるかを確かめます。

Cotomuでは、自社業務に合わせたWebアプリを、受発注、申請承認、作業報告など困っている業務ひとつから設計・開発します。初期開発と運用保守は個別見積もりです。問い合わせ台帳を業務アプリにする場合も、連携、移行、権限、データ出力の範囲は契約前に確認します。業務アプリの相談から、現在の受付経路と担当ルールをご相談ください。