Salesforce 認定 Service Cloud コンサルタント 1-10

A. Einstein チャットボットを使用してインテントをカスタマイズします。
B. Lightning コンソールのチャットページをカスタマイズします。
C. プレチャットフォームをカスタマイズします。

回答
C. プレチャットフォームをカスタマイズします。

プレチャットフォームをカスタマイズすることで、チャット開始前に顧客から必要な情報を収集できます。
これにより、エージェントは顧客の状況や問い合わせ内容を事前に把握でき、より迅速かつ適切な対応が可能になります。
チャット開始前に必要情報を収集できる点と、エージェントが十分なコンテキストを持って対応できる点が重要です。
なお、Einsteinチャットボット(現:Einstein Bots)は自動応答には有効ですが、事前情報収集の主目的には適していません。
またLightningコンソールのカスタマイズはUI改善であり、情報収集の強化には直結しません。

強化チャットのためにプリチャットをカスタマイズ

A. ケース所有者を変更し、新しい所有権の電子メールをバイパスするための画面フローを作成します。
B. サポート設定の「ケースの所有権が変更されたときにケース所有者に通知する」チェックボックスをオフにします。
C. 所有者を変更するときに、「通知メールを送信する」チェックボックスをオフにするようにユーザーに指示します。

回答
B. サポート設定の「ケースの所有権が変更されたときにケース所有者に通知する」チェックボックスをオフにします。

ケース所有者変更時の大量メールは、組織全体の通知設定によって制御するのが適切です。
サポート設定で該当の通知を無効化することで、すべてのケース所有者変更時のメール送信を停止できます。
重要なのは、組織レベルで通知設定を制御できる点と、自動通知を一括で無効化し運用負荷を下げられる点です。
ユーザー個別の操作(C)は徹底が難しく、Aのようなフロー作成は過剰対応です。
標準機能であるサポート設定を利用するのが最も効率的かつ推奨される方法です。

サポート設定のカスタマイズ

A. ケーススウォーミングを実装します。
B. Einsteinボットを実装します。
C. スキルベースのルーティングを実装します。

回答
B. Einsteinボットを実装します。

単純で繰り返し発生する問い合わせ(パスワードリセットや注文確認など)には、自動応答によるセルフサービス化が最適です。Einsteinボット(現:Einstein Bots)は複数チャネルに対応し、よくある問い合わせに自動で対応できます。
重要なのは、単純な問い合わせを自動化できる点と、複数チャネルで一貫したセルフサービスを提供できる点です。
ケーススウォーミングは複雑案件向け、スキルベースルーティングは適切な担当者への振り分けであり、今回の「単純ケース削減」という目的には適していません。

標準的なボットをチャンネルに接続する

A. ケースをキューに割り当て、エスカレーションルールを使用して、エージェントに割り当てられていないケースを1時間以内にエスカレーションします。
B. 1時間以内にケースがどのエージェントにも割り当てられていない場合は、Flow Builderを使用してキューのすべてのメンバーにタスクを割り当てます。
C. ケース自動応答ルールを使用して、ケース作成後1時間以内にサポートマネージャーに電子メールを送信します。

回答
A. ケースをキューに割り当て、エスカレーションルールを使用して、エージェントに割り当てられていないケースを1時間以内にエスカレーションします。

SLA遵守には、ケースの迅速な割り当てと未対応ケースの早期検知が重要です。
ケースをキューに入れることで適切な担当者へ割り当てやすくし、エスカレーションルールにより未割り当てケースを自動的に監視・通知できます。
重要なのは、未割り当てケースを自動的に検知できる点と、SLA違反前にエスカレーションして対応を促せる点です。
Flowによるタスク割当や自動応答ルールは補助的手段であり、標準のエスカレーションルールが最も効率的かつベストプラクティスです。

エスカレーションルールの計画

A. 重複管理を構成してアクティブ化します。
B. 「すべてのデータの表示」を許可し、検索するように指示します。
C. ContactのApexトリガを実装します。

回答
A. 重複管理を構成してアクティブ化します。

Salesforceには標準機能として重複管理(Duplicate Management)があり、重複ルールと一致ルールを設定することで、データ入力時に重複を検出・防止できます。
これにより、ユーザーに警告を表示したり、重複レコードの作成自体をブロックすることが可能です。
重要なのは、標準機能で重複検知と防止を実現できる点と、入力時点でデータ品質を維持できる点です。
「すべてのデータの表示」は権限の問題であり根本解決にならず、Apexトリガは過剰実装となるため推奨されません。

重複記録の管理

A. 顧客とのメッセージングセッションを終了します。
B. メッセージングセッションを顧客として非アクティブとしてマークします。
C. 顧客とのメッセージングセッションを開いたままにします。

回答
A. 顧客とのメッセージングセッションを終了します。

顧客が一定時間応答しない場合、エージェントはセッションを終了するのが適切な対応です。
これにより、エージェントの作業負荷を適切に管理し、他の対応中の顧客にリソースを割り当てることができます。
重要なのは、非アクティブなセッションを適切に終了できる点と、エージェントのリソースを有効活用できる点です。
セッションを開いたままにするとリソースが占有され、非アクティブとしてマークするだけでは運用管理として不十分です。
標準的な運用としてセッション終了が推奨されます。

メッセージングセッションを終了します

A. 資格とマイルストーンを定義します。
B. オムニチャネルルーティングを有効にして構成します。
C. 時間ベースのアクションを使用してLightningフローを実装します。

回答
A. 資格とマイルストーンを定義します。

ケースが特定の時間内に段階的な処理を行う必要がある場合、Salesforceのエンタイトルメント管理(資格とマイルストーン)を使用するのが最適です。
これにより、サービスレベル(SLA)を定義し、各ステップの期限や進捗を追跡できます。
重要なのは、時間ベースでマイルストーンを管理できる点と、SLAに基づいてケース進行を自動的に監視できる点です。
オムニチャネルは割り当て管理、Flowは個別実装となり、SLA全体の管理には不十分です。
標準機能であるエンタイトルメントの活用がベストプラクティスです。

権利とマイルストーンの設定と管理

A. Service Cloud コールセンター
B. ライトニング ダイヤラー
C. Service Cloud ソフトフォンのレイアウト

回答
A. Service Cloud コールセンター

Salesforceと電話システム(CTI)を統合する場合、Service Cloudコールセンター(現:Open CTI/Service Cloud Voiceなどの基盤機能)が標準的なソリューションです。
これにより、エージェントはSalesforce内で通話の発着信や顧客情報の参照を一元的に行えます。
重要なのは、CTI連携のための標準的な統合基盤である点と、Salesforce画面内で通話操作と顧客対応を統合できる点です。
ライトニングダイヤラーは発信機能に限定され、ソフトフォンレイアウトはUI設定であり、統合そのものの機能ではありません。

Salesforce コールセンター

A. ソーシャルメディア
B. メッセージングアプリ
C. Salesforceナレッジ

回答
B. メッセージングアプリ

よりパーソナライズされ柔軟な顧客対応を実現するには、非同期コミュニケーションが可能なメッセージングアプリの活用が有効です。
WhatsAppやSMSなどのメッセージングは、顧客の都合に合わせたやり取りができ、継続的で自然なコミュニケーション体験を提供します。
重要なのは、非同期で柔軟なコミュニケーションが可能な点と、顧客の好みに合わせたパーソナライズ対応ができる点です。
ソーシャルメディアは主に公開型対応、ナレッジは自己解決支援であり、本要件の「柔軟で対話的な体験」にはメッセージングが最適です。

サービスクラウドメッセージングとは何ですか?

A. 独立再帰
B. 再発なし
C. 連続再帰

回答
A. 独立再帰

本シナリオでは、2つ目のマイルストーンが最初の完了時間ではなく「開始時間から一定時間後」に基づいています。
この場合は独立再帰(Independent Recurrence)を使用します。
各マイルストーンは前の完了に依存せず、あらかじめ定義されたスケジュールに従って開始されます。
重要なのは、各マイルストーンが前の完了に依存しない点と、開始基準で時間管理される点です。
連続再帰は前の完了に依存するため不適切であり、再発なしは単発のケースにのみ適用されます。

マイルストーン再発タイプ