共有受信箱で最初に決めることは何ですか？

受信経路より先に、未割り当て、対応中、顧客待ち、社内待ち、完了の状態と、各状態の責任者を決める。担当者名だけでは、保留や不在時の責任が曖昧になる。

担当者が休みのときはどう運用しますか？

代理担当を人名で固定せず、チームまたは当番へ戻す条件を決める。休暇、異動、繁忙、専門外など再割り当て理由を記録し、次の担当が必要な文脈を一画面で読めるようにする。

返信速度を改善する記事との違いは何ですか？

この記事は問い合わせが共有キューへ入った後の所有権と完了判定を扱う。自動返信、文章生成、営業時間外対応など返信方法や速度の設計とは分けて考える。

共有受信箱の担当割り当て設計｜未対応・再割り当て・期限超過をなくす運用表

代表メール、問い合わせフォーム、チャットを一つの受信箱へ集めても、対応漏れはなくならない。「誰かが見るだろう」「返信した人が担当だろう」という暗黙の運用では、全員が見えているのに誰も所有していない連絡が残るからだ。

この記事は、連絡が共有キューへ入った後の担当割り当てに限定する。返信文や営業時間外の一次対応は問い合わせ返信の自動化、受付から営業接続までの全体像は問い合わせ対応フローで扱っている。ここでは業種を問わず、所有者、再割り当て、保留、期限超過を管理する。

共有受信箱は「見える場所」ではなく仕事の台帳

受信箱を単なるメール一覧として使うと、未読と未対応が混ざる。内容を読んだが担当できない連絡、返信済みだが社内確認が残る連絡、顧客からの追加情報を待つ連絡が、すべて既読になる。管理単位をメッセージではなく「解決すべき一件」に変える。

必要項目	判断に使う意味
受付ID・受信日時	経路が違っても一件を識別し、滞留時間の起点をそろえる
相手・会社・関連案件	誰から何の文脈で来た連絡かを特定する
要件・分類・優先理由	振り分けと確認順を決める。ただし分類だけで緊急度を断定しない
現在状態・担当・担当確定時刻	誰が持ち、いつ引き受けたかを分けて記録する
次回行動・期限・待ち先	次に誰が何をするか、どこからの返答待ちかを示す
完了条件・完了確認者	返信しただけでなく、依頼が閉じたことを確認する

件名や本文をそのまま担当表へ転記するのではなく、受信原文へ戻れる受付IDを持たせる。個人情報や機密情報を必要以上に複製せず、判断に必要な要約と原文の場所を結ぶ。

状態を「未読・既読」の二択にしない

状態	入る条件	抜ける条件
未割り当て	受付済みだが所有者未確定	担当者が引き受けた
対応中	担当と次回行動が確定	返信、待ち、完了へ更新
顧客待ち	確認事項を相手へ返した	返答受領または再確認日到来
社内待ち	承認・調査・専門回答を依頼	回答受領または期限超過
完了	定義した完了条件を満たす	追加連絡なら再開または新規受付

「保留」は理由が広すぎるため使わない。顧客待ちと社内待ちを分け、待ち先、依頼内容、再確認日を必須にする。待ち状態にも所有者を残し、返答が来ないことを理由に案件を無人化しない。

担当割り当ては分類表と受諾で二段階にする

受付時に要件、顧客、関連案件、優先理由を仮分類する。
分類に応じたチームまたは当番へ候補として割り当てる。
担当候補が内容と期限を確認し、受諾して担当を確定する。
担当できない場合は理由と引き継ぎ先を付けて再割り当てする。
管理者は未割り当てと受諾待ちを別々に確認する。

自動振り分けを使っても、誤分類や担当不在は起こる。システムが名前を入れた時点を担当確定にせず、人が受諾した時刻を分ける。これにより「割り当て済み表示だが本人は知らない」を検出できる。

期限は一律の時間ではなく約束と次回行動で持つ

すべての問い合わせへ同じ期限を付けると、簡単な連絡ばかり先に処理され、経営判断や専門確認が必要な案件が見えにくくなる。外部へ約束した回答日、社内で次に動く日、完了目標を分ける。この記事では特定の時間基準を置かず、自社の営業時間、顧客との約束、影響度に合わせて定義する。

初回確認の期限：内容と担当候補を決める日
受諾期限：候補者が担当可否を返す日
次回行動日：返信、調査依頼、再確認をする日
顧客約束日：相手に回答すると伝えた日
完了目標日：依頼を閉じる判断をする日

期限超過時は赤くするだけで終えない。現在の担当へ通知する、代理へ戻す、管理者が優先順位を決める、顧客へ見通しを伝える、という次の動作までルールにする。

再割り当てで文脈を失わない

引き継ぎ先へメールを転送するだけでは、何を判断してほしいのか分からない。再割り当て時は、理由、現在地、完了済み作業、未解決事項、次回行動、相手への約束を更新する。過去の全履歴を読ませるのではなく、判断の入口を作る。

再割り当て理由	必要な処理
専門外	必要な専門領域と質問を明記
休暇・退職・異動	チームへ戻し、期限と約束を再確認
負荷集中	優先理由を保ち、代理候補へ受諾依頼
承認待ち	所有者は維持し、承認者を待ち先に設定

承認や助言を求めるだけなら、担当そのものを上司へ移さない。顧客への説明と完了確認を担う所有者、部分的な判断を返す協力者を分ける。

未対応一覧は四つの穴に分ける

受付されたが担当候補もいない「未割り当て」
候補はいるが本人が引き受けていない「受諾待ち」
担当はいるが次回行動がない「行動未設定」
次回行動日や顧客約束日を過ぎた「期限超過」

件数の合計だけでは原因が分からない。分類ごとに、受付経路、要件、チーム、再割り当て回数を見て、入口の分類が悪いのか、受諾できないのか、判断待ちなのかを切り分ける。問い合わせ数が増えたときに社長や一人の管理職へ例外判断が集中していないかも確認する。

完了は「返信済み」ではなく解決条件で決める

受領連絡を送っただけで完了にすると、その後の見積もり、修正、返金、社内登録が抜ける。要件分類ごとに完了条件を置く。資料送付なら指定資料を送って到達を確認、苦情なら対応方針を合意して必要処理を記録、営業相談なら案件責任者へ受諾付きで引き渡す、といった形だ。

顧客情報と次回行動を営業へつなぐ設計は電話・LINE・メールの反響一元管理も参考になる。ただし共有受信箱の完了と、商談や契約の完了は別の状態として、関連IDで結ぶ。

導入は一経路・一チームで試す

現在の未対応例を集め、漏れた理由を状態へ変換する。
受付ID、状態、担当、次回行動、期限、完了条件の最小項目を作る。
一つの受信経路と一チームで、受諾と再割り当てを運用する。
毎日、四種類の穴と期限超過理由を短く確認する。
分類や自動化は、実際の例外が分かってから追加する。

外部市場でも、チャットやメールでの問い合わせ対応に加え、顧客情報・進捗・履歴の管理やマニュアル改善を含む業務募集が見られる（CrowdWorks掲載例）。個別案件の条件を一般化するのではなく、返信だけでなく状態管理まで求められている現場需要の一例として扱う。

運用開始後は、担当者ごとの処理件数を競わせる前に、再割り当て理由と完了後の再開を確認する。専門外への誤配が多ければ分類表、受諾待ちが多ければ当番と不在設定、完了後の再開が多ければ完了条件を直す。個人評価に直結させると、難しい問い合わせを避けたり、早く完了へ移したりするため、まず業務設計の改善材料として扱う。

また、同じ相手から複数経路で連絡が来た場合の統合ルールも決める。本文が似ているだけで自動的に一件へまとめず、顧客、要件、関連案件、時間関係を確認する。統合した場合は残した受付IDと統合理由を記録し、別件だった場合に元へ戻せるようにする。二重返信の防止と、異なる依頼の取りこぼしを両立させるためだ。

ツール選定は最後でよい。必要なのは、誰が所有し、いつ動き、どの条件で別の人へ渡し、何をもって閉じるかという運用だ。共有受信箱がこの判断を表示できれば、連絡量が増えても一部の管理者の記憶に頼らず、未対応を構造として見つけられる。