目次
この記事のポイント
- Service Cloudの中心はケース（Case）。問い合わせ種別ごとに項目・対応手順・SLAを変える
- SAP側の受注・出荷・請求・保証は参照中心で連携し、更新はSAPに限定する（正の所在を崩さない）
- エスカレーションは「時間」ではなく顧客への影響（重要顧客・停止中）を条件にすると現場が納得する
- ナレッジは対応後に書くのではなく、対応中に作りながら参照する運用にする
01WHAT ケースは「顧客の困りごと」、SAPデータは「事実」を担当する
Service Cloud では、顧客からの問い合わせを Case（ケース）として登録し、優先度・種別・対応状況・SLA を管理します。ケースは取引先（Account）・責任者（Contact）に紐づき、過去の対応履歴が顧客単位で残ります。一方、納期・出荷状況・請求額・保証期間といった「事実」は SAP 側が持ちます。ケースは対応プロセス、SAP は取引の事実と役割を分け、Service Cloud から SAP のデータを参照できるようにするのが基本設計です。
ケース種別の整理がすべての起点になる
「問い合わせ」「障害」「請求照会」「返品・交換」などを同じケースで扱うと、必要な項目も対応時間も混ざります。種別ごとに、①必須項目 ②SLA（一次応答・解決までの目標時間） ③エスカレーション条件 ④完了条件を決めます。特に「請求照会」は SAP の請求データ、「納期照会」は受注・在庫データを参照するため、種別と参照データを対応表にしておくと実装が迷いません。
参照と更新を分けて設計する
Service Cloud から SAP へ書き込みを行うと、SAP 側の整合性チェック（与信・在庫・締め処理）と衝突するリスクがあります。基本は読み取り専用の参照とし、更新が必要な場合は「SAP の該当画面へ遷移する」「申請として起票する」形にします。これにより、基幹側の数字を崩さずに現場の利便性を上げられます。
補足：SLA は「顧客との約束」を表す数字
SLA は目標時間を決めるだけでは機能しません。「重要顧客」「停止中」など顧客影響度に応じた複数段階を用意し、未達時に誰が何をするかまで決めておくことが実効性につながります。
02POINTS Service Cloud×SAP を設計する4つの手順
- ケース種別と参照データを対応表にする。種別ごとに、参照するSAPデータ（受注・出荷・請求・保証）を一覧化します。連携の対象と目的が明確になります。
- SLAとエスカレーションを定義する。影響度別の目標時間と、未達・重要顧客時のエスカレーション先を決めます。
- 参照項目を絞って連携する。納期・出荷状況・請求額など、1画面で答えるべき項目に限定して連携します。全項目連携は性能と保守の負担になります。
- ナレッジを対応フローに埋め込む。ケース画面からナレッジ候補を提示し、解決後に記事として残す循環を作ります。
「顧客が次に知りたいこと」を1画面に集める
問い合わせの多くは「今どうなっているか」「次はいつか」「いくらか」です。ケース画面に受注番号・出荷状況・請求額・次回アクションを並べるだけで、平均対応時間と転送率が下がります。まず画面を設計し、そのために必要な連携項目を決める順序が有効です。
03INSIGHT 顧客対応の数字は、経営指標としても使える
ケースの種別・SLA・解決時間・エスカレーション件数を記録すると、単なる問い合わせ管理を超えて、製品・物流・請求プロセスの問題点が見えるようになります。たとえば「納期照会」が特定の出荷拠点に集中していれば、物流側の改善テーマになります。CRM を顧客対応の道具ではなく、業務改善のセンサーとして使うのが定着の近道です。
当社は Service Cloud の設計（ケース種別・SLA・画面）と、SAP の受注・出荷・請求データとの連携実装をまとめて支援しています。特に「どの項目を参照するか」「エラー時にどう振る舞うか」を先に決めて実装するため、運用開始後の突合トラブルが起きにくい設計になります。
運用が始まると、「Salesforce が遅いのか、SAP が遅いのか」の切り分けが必要になります。そのために、連携のたびに取得時刻・取得元・処理結果を記録し、ケース画面に「最終更新」を表示しておくことを推奨します。参照データが古いのか、そもそも未取得なのかが画面で分かると、対応者は不要な問い合わせをせずに済みます。監視項目は連携の失敗率と遅延時間の 2 つに絞ると、運用負担を増やさずに品質を保てます。
豆知識：エスカレーションは「ルール」と「例外」を分ける
時間ベースの自動エスカレーション（ルール）と、担当者が判断する上位エスカレーション（例外）を分けておくと、現場が過剰に反応せず、本当に重要な案件へ集中できます。
まとめ
- ケースが対応プロセスの正、SAPが取引事実の正。更新はSAPに限定する
- ケース種別ごとに必須項目・SLA・エスカレーション・完了条件を決める
- 参照項目は「顧客が1画面で知りたいこと」に絞って連携する
- 重要顧客・停止中など顧客影響度をエスカレーション条件にする
- 対応記録を経営指標として使い、業務改善につなげる
出典・参考
- Salesforce 公式サイト（製品・機能の一次情報） https://www.salesforce.com/jp/
- Salesforce Help（設定・データモデルの一次情報） https://help.salesforce.com/
- Trailhead（公式学習コンテンツ） https://trailhead.salesforce.com/ja
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-12）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
Service Cloud と SAP CRM／サービス管理はどう使い分けますか？
顧客対応の現場（ケース・SLA・ナレッジ・チャネル）は Service Cloud、修理・交換・保証判定や在庫・請求の確定処理は SAP 側に置く分担が一般的です。判断軸は「顧客接点か、取引事実か」です。
連携はリアルタイムである必要がありますか？
すべてをリアルタイムにする必要はありません。納期・在庫など変化の速い項目は都度参照、請求・保証など確定情報は日次でも実務上は足りることが多いです。まずは参照のみ・数項目から始めます。
SAP 側で項目を追加した場合の影響は？
参照項目を一覧表で管理していれば、追加時の影響範囲が明確です。連携層でマッピングを持つ設計にしておくと、CRM 側の変更を最小限にできます。
ナレッジが蓄積されないのですが、対策はありますか？
対応完了時に記事作成を必須にするのではなく、対応中に候補を提示し、使われた記事に「役に立った」を付ける運用が有効です。使われた記事を優先的に整備します。
顧客名や製品名はどう特定すればよいですか？
キー項目を探すのが基本です。ケースの顧客名から取引先を特定し、取引先を軸に SAP の受注・注文番号・請求書番号を参照する流れにします。画面上に「顧客→取引先ID→伝票番号」の順で紐づけを見せると、担当者が迷いません。