Salesforce Service Cloud — 問い合わせ一体管理の導入設計
Salesforce Service Cloudを検討している方へ
問い合わせ対応をCRMと一体管理すべき理由
顧客対応の履歴と商談・契約情報が分断していると、機会損失と対応品質のばらつきが発生します。
Service Cloudなら問い合わせ管理とCRMを1つのプラットフォームで運用できます。
あなたの状況
診断の結果、あなたの組織では顧客対応の履歴と商談・契約情報が別々のシステム（またはExcel・メール）で管理されており、情報の分断による対応品質のばらつきや機会損失が発生している段階にあります。
Salesforce Service Cloud（Salesforceの問い合わせ管理・カスタマーサポート向け製品）を導入すると、営業が扱う商談・契約情報と、サポートが扱う問い合わせ履歴を同じプラットフォーム上で一体管理できます。
ただし、導入前に「最小運用ルール」を定めないと、入力が定着せず形骸化するリスクがあります。まずは問い合わせの分類と優先度ルールの整理から始めてください。
なぜ問い合わせ管理をCRMと一体化すべきなのか
顧客からの問い合わせ対応と、営業の商談・契約情報を別々に管理していると、以下の問題が発生します。
- サポート担当者が顧客の契約内容や商談状況を把握できず、的外れな対応になる
- 営業担当者が過去のクレームやトラブル履歴を知らないまま訪問し、顧客の信頼を損なう
- 重要顧客からの問い合わせと通常の問い合わせを区別できず、対応の優先順位が付けられない
Service Cloudは、Salesforceの商談・取引先情報と問い合わせ（ケース）を同一画面で確認できるため、「この顧客の契約内容を確認しながら対応する」ことが標準機能で可能です。
問い合わせ管理が分断した場合に起きる損失
これまでの運用改善支援の中で、問い合わせ管理とCRM（顧客関係管理システム）が分断した企業に共通する問題です。
- 対応漏れ・遅れ：メールの受信箱やスプレッドシートで管理していると、見落としが発生する
- 二重対応：複数の担当者が同じ問い合わせに別々に回答し、顧客に矛盾する情報を伝えてしまう
- 重要顧客の埋没：年間契約額1,000万円の顧客からの緊急連絡が、無料ユーザーの質問と同じ優先度で処理される
- 引き継ぎの断絶：担当者の異動・退職時に、過去のトラブル経緯が引き継がれず、同じ問題が再発する
- クレームの増加：過去の対応履歴を踏まえない対応が繰り返され、顧客の不満が蓄積する
サポート機能の限界を示す5つのサイン
以下に心当たりがあれば、問い合わせ管理の仕組みを見直す段階です。
- ベテラン社員しか対応できない問い合わせが増え、属人化が進んでいる
- 「この顧客の前回の対応内容を確認して」とチャットで聞く場面が日常化している
- 顧客から「前も同じことを説明しましたが」と言われることがある
- 対応期限が個人の判断に委ねられており、組織としてのSLA（対応期限の目標値）がない
- 同じ質問に何度も回答しているが、FAQやナレッジとして蓄積されていない
最小運用ルール：そのまま使えるテンプレート
Service Cloudを導入する前に、以下の運用ルールを整理してください。ツールの設定はこのルールに基づいて行います。
問い合わせ管理 最小運用ルール テンプレート
1) 問い合わせの分類：
– 種別（例：不具合、使い方、請求、解約、要望）
– 分類数は5〜8に抑える（多すぎると迷う）
2) 優先度ルール：
– 高：（条件と初動期限）
– 中：（条件と初動期限）
– 低：（条件と初動期限）
3) 必須入力項目：
– 件名、顧客名、種別、優先度、担当者、期限、状況、次アクション
4) エスカレーション条件：
– いつ・誰に・どう引き継ぐか
5) FAQ化のルール：
– 完了時に「再発する可能性があるか」を判定し、再発可能性が高いものをナレッジとして保存
6) 週次見直し：
– いつ・誰が・何を確認するか
記入例（従業員40名・BtoB SaaS企業の場合）
1) 分類：不具合（システム障害）/ 使い方（操作方法の問い合わせ）/ 請求（料金・契約関連）/ 解約（解約手続き）/ 要望（機能追加リクエスト）/ その他
2) 優先度：
高＝サービス停止・データ消失に関わる問題 → 1時間以内に初動
中＝通常の操作問い合わせ・請求確認 → 4営業時間以内に初動
低＝機能要望・急がない質問 → 2営業日以内に初動
3) 必須項目：件名、顧客名（取引先）、種別、優先度、担当者、対応期限、状況（未対応/対応中/保留/完了）、次アクション
4) エスカレーション：対応期限を超過 → 自動でマネージャーに通知。重大な不具合 → CTOに即時エスカレーション
5) FAQ化：完了ケースのうち「再発可能性あり」にチェックされたものを月1でナレッジ記事化
6) 週次見直し：毎週金曜16時、CS（カスタマーサクセス）チームで未完了ケースの棚卸しと優先度の見直し
ケース管理の必須項目と入力ルール
Service Cloudのケース（問い合わせ1件ごとのレコード）に入力する必須項目を明確にしてください。入力項目は少ないほど定着率が上がります。
- 件名：問い合わせ内容が一目で分かる要約（例：「ログインできない」「請求書の再発行依頼」）
- 顧客名：Salesforceの取引先/取引先責任者と紐付け
- 種別：不具合 / 使い方 / 請求 / 解約 / 要望 / その他
- 優先度：高 / 中 / 低
- 担当者：個人名で指定（「サポートチーム」ではなく「田中太郎」）
- 対応期限：優先度に応じた期限を自動設定
- 状況：未対応 → 対応中 → 保留 → 完了
- 次アクション：「何をいつまでにするか」を1行で記載
※ 「担当者」を「チーム」ではなく「個人名」にするのが重要です。チーム割り当てにすると、全員が「誰かがやるだろう」と思い、対応が遅れます。
優先度とSLA：対応期限の設計
SLA（Service Level Agreement：顧客への対応品質の約束。回答・解決までの期限目標）を設定し、対応期限を仕組みで管理します。
- 高（緊急）：サービス停止・データ消失など即時対応が必要 → 1時間以内に初動
- 中（通常）：操作方法の問い合わせ・請求確認など → 4営業時間以内に初動
- 低（計画）：機能要望・急を要さない質問 → 2営業日以内に初動
Service Cloudでは、優先度に応じたSLAを「エンタイトルメントプロセス」で自動管理できます。期限超過時に担当者とマネージャーに自動通知を設定してください。
FAQ・ナレッジ活用：同じ質問に何度も答えない仕組み
サポート工数を削減する最も効果的な方法は、よくある質問をナレッジとして蓄積し、再利用することです。
- ケース完了時：「この問い合わせは再発する可能性があるか？」をチェックする
- 再発可能性「あり」の場合：回答内容をナレッジ記事（FAQ）として保存する
- 次回以降：同じ質問が来たら、ナレッジ記事のリンクを引用して回答する
Service Cloudの「Knowledge」機能を使えば、ケース対応画面から関連するナレッジ記事を検索・引用できます。ゼロから回答を書く時間を削減できます。
エスカレーションルール：誰に・いつ・どう引き継ぐか
エスカレーション（対応困難な問い合わせを上司や専門部署に引き継ぐこと）のルールを事前に決めておくことで、対応の遅延を防ぎます。
- 時間ベース：SLAの期限を超過した場合、自動でマネージャーに通知
- 内容ベース：データ消失・セキュリティインシデントは発生時点で即時エスカレーション
- 顧客ベース：年間契約額が一定以上の顧客からの問い合わせは、自動で上位の対応キューに振り分け
エスカレーション先が曖昧だと、「誰に聞けばいいか分からない」状態が生まれ、対応が止まります。名前付きで引き継ぎ先を指定してください。
用語解説
- Service Cloud
- Salesforceが提供するカスタマーサポート向け製品。問い合わせ（ケース）管理、SLA管理、ナレッジベース、エスカレーション機能などを標準で備えています。
- ケース（Case）
- Service Cloudにおける問い合わせ1件のレコード。チケットと同義。顧客からの質問、不具合報告、要望などをケースとして記録・管理します。
- SLA（Service Level Agreement）
- サービスレベル合意。「問い合わせ受付から初回回答までの時間」「解決までの時間」などの対応品質目標を数値で定めたものです。
- エスカレーション
- 現在の担当者では対応困難な問い合わせを、上位の権限を持つ人や専門部署に引き継ぐこと。引き継ぎの条件とタイミングを事前にルール化しておくことが重要です。
- ナレッジベース（Knowledge Base）
- よくある質問と回答、操作マニュアル、トラブルシューティング手順などをまとめたデータベース。サポート担当者の回答品質の均一化と工数削減に役立ちます。
- エンタイトルメントプロセス
- Salesforce Service Cloudの機能で、SLAに基づく対応期限を自動管理する仕組み。優先度ごとに期限を設定し、超過時の自動通知やエスカレーションを構成できます。
- CRM（Customer Relationship Management）
- 顧客関係管理。顧客情報・商談履歴・対応履歴を一元管理し、営業やサポートの品質を高めるシステム・考え方です。
- カスタマーサクセス（CS）
- 顧客の成功を支援する活動・部門。問い合わせへの受動的な対応だけでなく、能動的に顧客の課題解決や活用促進を行います。
よくある失敗と対策
入力項目が多すぎて、サポート担当者が入力を省略する
必須項目は8個以内に絞ってください。「あれば便利」な項目は任意にし、入力率を見ながら必須化を判断します。最初のハードルを下げることが定着の鍵です。
担当者を「チーム」で割り当て、誰も対応しない
ケースの担当者は必ず個人名で設定してください。「サポートチーム」ではなく「田中太郎」です。個人に紐付けることで対応責任が明確になります。
期限超過のケースが放置され、対応品質が低下する
SLA超過ケースをダッシュボードで可視化し、毎朝の朝会で確認するルールを設けてください。超過ケースの件数をKPIに含めることも効果的です。
次にやること
- 上記の「最小運用ルール テンプレート」を記入する
- 問い合わせの種別（5〜8分類）と優先度ルールを合意する
- 直近1ヶ月の問い合わせを振り返り、よくある質問を5件リストアップする
- SLA（優先度別の対応期限）を設定し、チームで合意する
- エスカレーションルール（条件・引き継ぎ先）を文書化する
- 週次の未完了ケース棚卸しミーティングを開始する
これを書いた著者
広告・マーケ・インサイドセールス・営業・サポートを横断して、KPI定義・計測・運用ルール（MOps/RevOps）の整理と改善設計を支援しています。
WEBマーケティングとシステム開発で66社のビジネスを支援。SEOに強い会員サイトの構築を得意とし、新規会員獲得と既存顧客のLTV改善に寄与。
stripeを使った月額課金システムやキントーンやsalesforceとの連携。実績として動画配信サイト、ポイントシステム構築、フリマサイト、旅行予約サイト、オンラインサロン、モノのサブスクなど一般消費者向けのサービス設計とサイト設計を得意としています。
2025年7月 AIパスポート取得済
本コンテンツはコンテンツ制作ポリシーにそって、当社が独自の基準に基づき制作しています。
>>コンテンツ制作ポリシー