Salesforceキューのメンバー・所有権管理｜未対応リードとケースを滞留させない方法
Salesforceでリードやケースをキューへ集めていても、担当者が引き取らなければ対応は進みません。「チーム全員が見られる」ことと「誰がいつ対応するか決まっている」ことは別です。受付が増える時間帯、担当者の休暇、異動や退職が重なる時ほど、キューの名簿と実際の対応状況のずれが表面化します。
キューの棚卸しは、直接・間接メンバー、対象オブジェクト、キュー所有のレコード、引き取り期限、例外の責任者を一緒に確認します。必要な利用者が対象レコードを見て引き取れるかを確かめ、期限を超えた未対応を担当者へ渡し、是正後に残件と権限を再確認することで完了します。メンバー一覧を整えるだけでは、滞留の解消は確認できません。
キューの受付・引き取りを日常業務へ組み込むには、CRM管理者の業務一覧で扱う設定管理と現場の対応確認を分け、キューごとの業務責任者を決めておくと整理しやすくなります。
本記事のポイント
- キューの棚卸しは、直接・間接メンバーとレコード所有者、引き取り担当・期限を一緒に照合します。
- キューへの割り当て、個人への引き取り、初回対応は別々に確認し、更新日時を滞留時間と同一視しません。
- 退職・異動時は所属経路と担当レコードを見直し、後任の操作とキューの残件・例外を再確認します。
キューのメンバー、レコード所有者、対応担当を区別する
Salesforceのキューは、対応待ちのレコードをチームで扱うための仕組みです。公式Helpの「Sharing and Record Access Features」は、キューのメンバーやロール階層の上位ユーザーが、キューのレコードへアクセスして所有権を引き取る仕組みを説明しています。リードやケースを個人の担当者が決まる前の受け皿へ集めると考えると、キュー所有とユーザー所有の違いが明確になります。
棚卸しでは三つの情報を分けます。一つ目はキューの設定上のメンバーです。二つ目は現在のレコード所有者で、キューを所有者にしているレコードと、ユーザーへ引き取られたレコードを区別します。三つ目は、日々の引き取りや期限超過の確認を担う業務上の責任者です。業務責任者を決めてもレコードの所有者が自動で変わるわけではなく、キューの名前に部署名があっても、その部署の全員が対応できるとは限りません。
同じキュー名だけで判断せず、キューを識別するID、対象オブジェクト、利用目的、受付経路、業務責任者、代替担当、確認頻度を台帳に残します。リードとケースでは対応の完了条件が違うため、同じキューで扱う場合もオブジェクト別に確認します。対応可能なオブジェクトや画面・機能は組織の契約・設定で確認し、他社の例だけで自組織でも使えると判断しないでください。
| 確認対象 | 確認すること | 残す記録 |
|---|---|---|
| キュー本体 | 対象オブジェクト、目的、受付経路、責任者 | キューID、設定確認日、承認者 |
| 直接・間接メンバー | ユーザー登録、公開グループ、ロール等の所属経路 | 到達者、所属経路、在籍・業務根拠 |
| キュー所有のレコード | 未対応、対応中、保留、完了の区別 | レコードID、所有者、状況、期限 |
| 引き取り運用 | 通常担当、代替担当、期限超過時の連絡先 | 担当者、引き取り時刻、初回対応記録 |
| 例外 | 調査待ち、顧客返信待ち、権限不足などの理由 | 例外責任者、次の行動、再確認日 |
キューへ振り分ける条件と、キューから個人へ仕事を渡す方法も分けて確認します。割り当てルールでキューを所有者にすることだけでは、担当者の引き取りや初回対応まで完了したことにはなりません。Omni-Channelなどのルーティングを使っている場合は、その設定と受け取りの運用を別に点検します。キューにレコードがあるという事実だけで、自動配信が成功したとは判定できません。
直接・間接メンバーと実際の引き取り権限を照合する
メンバー確認では、設定画面に表示されるユーザーだけでなく、公開グループやロールを経由する対象者も確認します。たとえば「東日本営業」という公開グループを登録している場合、そのグループに誰が含まれるかを展開しないと、現在の利用者は確定できません。ロールやその配下を登録している場合も、実際に割り当てられているユーザーと業務上の対象範囲を照合します。
直接登録と間接所属を一つの名簿へまとめる際は、一意のユーザー数と所属経路を両方残します。同じ人がユーザー登録と公開グループの二経路で含まれる場合、直接登録だけを外しても対象者から外れない可能性があります。グループの展開方法は、Salesforce公開グループのメンバー棚卸しと合わせて確認すると、経路を消し忘れにくくなります。
名簿を在籍・所属・職務・委託期限と照合し、現在も引き取りを担当する人、閲覧だけ必要な人、不要になった人を分類します。「過去に対応した」という履歴だけで今の権限を維持せず、承認者と理由を残します。一方で、担当者を減らす前に、残るメンバーの勤務時間、休暇時の代替、繁忙時の受け皿を確認します。権限の削減と業務継続の両方を満たす必要があります。
メンバーであることだけで、必要な操作が必ずできるとは断定しません。実効アクセスは、オブジェクト権限、組織の共有設定、ロール階層などの影響も受けます。代表的なリード・ケースを選び、通常担当者と代替担当者の権限で、一覧表示、レコード参照、必要な編集、所有権の引き取りを確認します。管理者での操作成功だけを、現場の操作成功の証拠にしないでください。
権限不足が見つかった場合は、失敗したユーザー、レコード、操作、日時、現在の権限を記録します。すぐに広い管理権限を付けるのではなく、対象オブジェクトとレコードへの必要なアクセスを切り分けます。閲覧できる人の全員に引き取りを任せる必要もありません。業務として誰が処理するかと、システム上誰が操作可能かを別々に管理します。
キュー所有のレコードを引き取る操作と、既にユーザーが所有するレコードを別のユーザーへ移す操作も区別します。Salesforceの公式Helpは、所有者変更では編集権限、所有者・共有やロール階層との関係、新しい所有者の参照権限などを確認するよう説明しています。個別の変更と一括移管でも必要条件が異なり、検証ルールやApexトリガーで拒否される場合があります。「キューのメンバーだから全ての担当レコードを移せる」と扱わず、オブジェクトと操作方法ごとに確認してください。
未対応レコードを抽出し、期限と例外を決める
滞留確認の最初の条件は、対象のキューが所有者になっているレコードを抽出することです。そのうえで、リードなら現在の状況や初回接触、ケースなら対応状況や保留理由など、自組織で合意した業務項目を使います。キューに残っている件数をそのまま「未対応件数」としないでください。処理済みでも所有者がキューのままのレコードや、承認済みの保留が混ざると、件数だけでは優先順位が決まりません。
一覧やレポートには、レコードID、キュー、状況、優先度、受付日時、引き取り期限、初回対応記録、例外理由、例外責任者を揃えるのが実務上の一例です。必要な日時項目が標準で揃っていると決めず、現在取得できる項目を確認します。追加項目や自動記録を設ける場合は、初回割り当てとキューへの戻しを区別し、上書きの条件を先に決めます。
更新日時だけで滞留日数を決めないでください。レコードの更新日時は、所有者以外の項目変更でも動き得ます。作成日時も、作成後しばらくしてキューへ移されたレコードではキュー到達時刻と一致しません。キュー到達日時を記録していない場合は、作成日時からの経過を「作成後の経過時間」として表示し、キュー滞留時間と呼ばない運用にします。履歴を使う際も、取得対象と保存範囲を確認し、欠落している時刻を推測で確定しないことが大切です。
期限は、受付の営業時間、優先度、約束した応答時間に合わせます。たとえば、通常リードは当日中、重要ケースは受付後に優先確認する、といった基準を業務責任者が定めます。これは組織で決める運用例で、Salesforce共通の標準期限ではありません。休日や夜間、顧客返信待ちをどう扱うかも明記し、単純な暦時間と営業時間内の経過を混同しないでください。
期限超過を見つけた時は、担当者へ引き取りを依頼し、所有者変更と初回対応を別々に確認します。所有者だけを変えても、顧客への連絡が始まったとは限りません。例外にするレコードは、理由だけでなく責任者、次の行動、再確認期限を持たせます。毎回同じ「調査中」の理由で一覧から除外されるレコードは、例外の期限超過として再び確認します。
日次確認では、対象件数、期限超過件数、責任者未設定の例外、引き取り後も初回対応がない件数を分けます。前日より件数が減った理由が、対応完了なのか、別キューへの移動なのか、抽出条件の変更なのかも確認します。CRMデータを使う営業会議では、集計値だけでなく、次の行動と担当者を特定できる例外一覧を持ち込むと判断しやすくなります。
退職・異動時の変更を小さく分け、残件を再確認する
退職・異動時はユーザーの有効・無効と、キューのメンバー変更、レコードの引き継ぎを別の確認として進めます。ユーザーを無効化した事実だけで、キューの残件が解消したり、本人が所有するレコードが後任へ移ったりしたと判断しないでください。本人の担当レコードと、本人が参加していたキューの両方を確認する必要があります。
- 変更前の状態を保存する。キュー設定、直接・間接メンバー、本人所有のレコード、キュー所有の未対応、割り当て経路を記録します。対象IDを残すと、後から件数の増減を照合できます。
- 後任と代替担当を決める。後任に必要な参照・引き取り・編集の操作が可能かを先に確認し、引き継ぎ時点と業務上の受領者を決めます。
- 担当レコードを引き継ぐ。本人所有とキュー所有を分けて対象を確定し、必要な所有者変更を行います。進行中の対応、顧客への約束、次回連絡日も受領確認します。
- 所属経路を見直す。キューの直接ユーザー、公開グループ、ロール等の経路を確認します。複数経路のうち一つだけを削除して終了しないよう、変更後の展開名簿を作ります。
- 流入と残件を再確認する。変更後の代表レコードを実ユーザー権限で確認し、新しく入ったレコードが意図したキュー・担当へ届くか、期限超過や例外が残っていないかを確認します。
一度にキュー、グループ、ロール、割り当て条件をまとめて変更すると、問題が起きた時に原因を特定しにくくなります。変更単位を分け、確認者、変更日時、対象、期待する結果、戻す条件を記録します。後任が引き取れない、必要な担当者の一覧から消えた、想定外の利用者が操作できる、といった状態は、広い権限追加や一括移動で隠さず原因を切り分けます。
完了条件は「退職者を名簿から削除した」だけではありません。必要な人が対応でき、不要な所属経路が残らず、引き継ぐべきレコードが後任へ渡り、キューの未対応と例外に責任者が付いたことを確認します。CRM運用体制の役割分担に合わせ、設定を変える管理者と業務の引き継ぎを承認する責任者を分けると、確認が一人に集中しにくくなります。
よくある質問
キューのメンバーが増えれば、未対応は減りますか？
人数だけでは減るとは限りません。引き取り担当、確認頻度、期限超過時の連絡先が曖昧だと、全員が他の人の対応を待つ状態になります。必要なメンバーと実効権限を確認したうえで、時間帯ごとの担当と代替を決めます。
キューに入れたケースは、自動で担当者へ配信されますか？
キューへの割り当てだけでは、その後の自動配信まで確認できません。手動で引き取る運用か、Omni-Channelなどでルーティングする運用かを分け、後者はルーティング設定と実際の受け取りを確認します。
キュー所有の全レコードを未対応として数えてよいですか？
所有者に加え、状況、初回対応、保留理由を照合します。処理済みのレコードや承認済みの保留が含まれる場合があるため、組織で合意した未対応の定義を抽出条件へ反映します。
更新日時からキューの滞留時間を計算できますか？
更新日時だけでは正確なキュー到達時刻を確定できません。別項目の編集でも更新され得るためです。到達日時を記録しているかを確認し、記録がなければ作成後の経過など、確認できる指標として表示します。
退職者を無効化すれば、キューの棚卸しは完了しますか？
無効化だけでは完了と判断しません。直接・間接の所属、本人所有のレコード、キューの残件、後任の権限と初回対応を確認し、変更後の代表レコードで再検証します。
関連ページと関連記事
管理の全体像はCRM管理者の業務一覧、間接メンバーの展開は公開グループの棚卸し、責任分担はCRM運用体制の記事で確認できます。キューの点検結果を営業会議へつなげる場合は、担当者と次の行動が分かる例外一覧を用意してください。
Salesforceの公式仕様を確認する
以下の公式資料で、キューの設定とケースの割り当て・引き取りを確認できます。画面の名称や使える機能は自組織のエディション・権限・設定に合わせて確認してください。
