ケースに関する顧客とのやりとりの実装【Community Cloud】

By | June 14, 2020
0 Comment

実装区分

ケース上での顧客のやり取りに関しては、大別して以下の三つの実装方針がある。

①メールtoCase
②Chatter
③ケースコメント

結論

Pros/Consの比較から明らかな通りChatterが推奨実装手段。

ケースコメントはSF内部で既に廃止が確定しているという情報があり、実際に（以下で紹介する）致命的な不具合が3年以上前から修正されず放置されている。

ケースコメント vs Chatter

※Chatterの欠点は「ケース起票時に自動Chatter投稿」の簡易的なフローを組むことで回避可能

メール通知の仕様 – Chatter

Settings>Feature Settings>Chatter>Email Settingsで組織レベルでのメール通知のON/OFFが可能

あとはユーザレベルで通知設定を行うことになる。

原則としてデフォルト設定では、「自分宛のメンション」と「自分の投稿に対するリプライ」にはメール通知があるが、それ以外はメール通知がないという認識でよい。

内部ユーザの場合は下記導線から設定する。

画面右上のPersonal Icon>Settings>Chatter>Email Notifications

コミュニティユーザの場合は下記導線から設定する。

画面右上のPersonal Icon>My Settings

Chatterメール通知の推奨設定

原則として、標準設定のままでよい。

Chatterグループのダイジェストメールの定期配信に関しては、Chatterグループの所有者（≒作成者）がメール配信設定を「制限（limited）」に変更することで停止することが可能。

メール通知の仕様 – ケースコメント

ケースコメントのメール通知に関する標準機能としては下記の二つが存在する。

  1. Enable Case Comment Notification to Contacts（ケースコメント作成時にケースの参照先の取引先責任者に通知。ただし、当該の取引先責任者がコミュニティユーザとして有効化されていない場合に限る）
  2. Notifiy Case Owner of New Case Comments（ケースコメント作成時にケース所有者に通知）

ケースの「内部コメント（Internal Comments）」項目に値を入れて保存すると、その値はすぐさま消えて、新しく「ケースコメント」レコードが作成される。その場合、ケースコメントの公開フラグはFALSEである。

Communityユーザが「ケースコメントパブリッシャー」コンポーネントからケースコメントを新規作成した場合は公開フラグがデフォルトでTRUEである。

コア側からケースコメントを新規作成する場合、同一画面からのファイル添付は不可能。

実装方針１：Mailに集約（メールtoケース）

  1. 顧客がケース作成
  2. Agentがメール送信（from SF）
  3. 顧客がメールに返信
  4. Agentがメール送信（from SF）
  5. 顧客がメールに返信
  6. <以下略>

pros

なし

cons

  • 顧客の返信時にケースのid情報を削除されるとケースに紐づかない
  • Communityサイト上でケースに紐づいたやり取りの履歴を閲覧することができない。

conclusion

  • メールtoケースによる実装は、顧客がいかなる意味でも自社のSalesforceユーザではない場合に限る。

実装方針２：Chatterに集約（Chatter標準仕様）

  1. 顧客がケース作成
  2. Agentがフィード投稿
  3. 顧客が新規フィード投稿orフィードに返信
  4. Agentが新規フィード投稿orフィードに返信
  5. 顧客が新規フィード投稿orフィードに返信
  6. <以下略>

cons

  • Agent側が毎回①メンションを付ける②顧客の投稿に対する返信にする、ということをしない限り顧客にメール通知が飛ばない
  • メンションの付け間違いが発生した場合、別顧客に誤ってメール通知が飛んでしまう。

実装方針３：Chatterに集約（Chatterロジック開発）

  1. 顧客がケース作成
  2. Agentがフィード投稿 【→顧客にメール通知 （ケースURLを記載）】
  3. 顧客がフィード投稿 【→顧客にメール通知 （ケースURLを記載）】
  4. Agentがフィード投稿 【→顧客にメール通知 （ケースURLを記載）】
  5. 顧客がフィード投稿 【→顧客にメール通知 （ケースURLを記載）】
  6. <以下略>

前提となる設定①（メール通知二重配信の防止）

  • 標準のメール通知をOFFにする（Settings>Feature Settings>Chatter>Email Settingsの順にクリックし、Allow Emailsチェックボックスを外す）

前提となる設定②（取引先責任者のメアド情報入力の必須化）

  • 「取引先責任者」のページレイアウトでメール項目を必須化
  • 「ユーザ」の作成時およびメール項目更新時に、「ユーザ」のメール項目の値を「取引先責任者」のメール項目に自動反映させるロジックの開発

要開発ロジックその①（FeedItemレコード）

  1. FeedItemのCreate時に発動
  2. ParentIdがケースであるか判定　→FALSEであれば終了
  3. ケースの参照先のContactのメールアドレスを取得
  4. ケースの参照先のContactの子User.Profileを取得
  5. User.Profileがカスタマーポータルであれば、カスタマーポータルのケースレコードに飛ばすメールを送付
  6. User.Profileがパートナーポータルであれば、パートナーポータルのケースレコードに飛ばすメールを送付
  7. その他であれば、管理者にエラーメールを送付

要開発ロジックその②（FeedCommentレコード）

  1. FeedCommentのCreate時に発動
  2. FeedCommentの親のFeedItemのParentIdがケースであるか判定　→FALSEであれば終了
  3. ケースの参照先のContactのメールアドレスを取得
  4. ケースの参照先のContactの子User.Profileを取得
  5. User.Profileがカスタマーポータルであれば、カスタマーポータルのケースレコードに飛ばすメールを送付
  6. User.Profileがパートナーポータルであれば、パートナーポータルのケースレコードに飛ばすメールを送付
  7. その他であれば、管理者にエラーメールを送付

considerations

  • メール通知を希望しない顧客がいた場合でも、上記ロジックでは無条件にメールが配信されてしまう。従って、取引先責任者に「メール通知禁止フラグ」などを設けて、ロジックの場合分けをする必要性も考慮する必要あり。

cons

  • ケースに対するChatter投稿を顧客への返信という意図以外で行った場合でも、無条件にケースに紐づいている顧客にメールが返信されてしまう。
  • 「メールへの返信」という選択肢が顧客に存在しないため、Salesforce標準のメール通知機能と比べると柔軟性に欠ける。
  • 開発工数が多く、顧客から繊細な制御を求められるごとにロジックが複雑化していく。

実装方針４：Chatterに集約（ChatterFeed）

  1. 顧客がケース作成
  2. Agentがフィード返信 【→顧客にメール通知】
  3. 顧客がフィードに返信orメールに返信 【→Agentにメール通知】
  4. Agentがフィードに返信 【→顧客にメール通知】
  5. 顧客がフィードに返信orメールに返信 【→Agentにメール通知】
  6. <以下略>

前提となる設定（新規Chatter投稿の導線の廃止）

  • SF内部ユーザの「ケース」レコードページおよびCommunityの「CaseDetails」ページの双方で「Chatter」コンポーネントを削除し、「ChatterFeed」コンポーネントに一元化

pros

  • 全て標準仕様に完結するため実装工数が非常に少ない
  • 顧客のメール通知後のアクションとして①Chatter投稿②メール返信の双方が許容されるため、柔軟性が高い

cons

  • なし

実装方針５：CaseCommentに集約（標準仕様）

  1. 顧客がケース作成
  2. Agentがケースコメント投稿 【→顧客にメール通知 （ケースURLを記載）】
  3. 顧客がケースコメント投稿
  4. Agentがケースコメント投稿 【→顧客にメール通知 （ケースURLを記載）】
  5. 顧客がケースコメント投稿
  6. <以下略>

CaseCommentに関する前提と分析

  • Salesforce標準仕様の場合、CaseCommentのメール通知はCaseCommentレコードの作成時に「ケースの所有者」に対してなされる。
  • ①上記の仕様②「内部コメント（Internal Comments）」項目への投稿が自動的に「ケースコメント（CaseComment）」に反映されるという仕様③ケース所有者の通常の使用用途がケースのサポート担当者の割り当てであること、という三つ位から自然に想像されることは、ケースコメントのメール通知機能は専ら内部ユーザ間での使用を想定しているであろうということである。

前提となる設定（CaseCommentメール通知の有効化）

  • Settings>Feature Settings>Service>Support Settingsの画面からNotify Case Owner of New Case Commentsフラグの有効化

前提となる設定（Chatter投稿導線の削除）

  • コア側およびコミュニティ側の双方のケースレコードページからChatter関連の一切のコンポーネントを削除する

pros

  • 全て標準仕様に完結するため実装工数が非常に少ない

cons

  • Community上で「ケースコメントパブリッシャー」コンポーネントからケースコメントを投稿しても、画面上に変化がないというUX上の致命的な問題
  • ケースコメントObjectの特殊性（ページレイアウトや項目を含む一切の標準仕様に対する変更不可）のため、Communty上の「ケースコメント関連リスト」の表示項目を変更できず、UIが悪い。
  • コア側画面からのケースコメント作成時のファイル添付不可。従って、Agentがケースコメントにファイルを添付する場合は、毎回コミュニティにログイン→ケースレコードページに遷移という手順を取るか、あるいは「添付ファイル（≒ファイル）」にファイルをアップロードする必要あり。
  • Agentのケースコメントレコード作成時に「公開」チェックを付け忘れると、顧客はケースコメントを確認することができない。このエラーはAgentによって”無自覚に”なされる可能性が高い。
  • ケースコメントの対する通知は「ケース所有者」に対してなされるため、ケースの作成を代理で行った場合には、ケース所有者の変更という運用工数が増え、この運用が抜け漏れた場合には顧客にメール通知が飛ばない。
  • 同様に、 ケースコメントの対する通知は「ケース所有者」に対してなされるが故に、顧客に対するメール通知を「ケース所有者」に依存させるのであれば、ケースの所有者をケースのサポート担当者に割り当てるという通常の業務フローが不可能となる。
  • 「内部コメント（Internal Comments）」項目に値を保存すると自動的に「ケースコメント（CaseComment）」レコードが作成されるというSalesforceの仕様のため、「Internal Comemnts」項目を既に利用している場合、異なる用途で当該機能が利用されることとなり、運用と見た目の双方が煩雑化する可能性がある。
  • また同様に、ケースコメントの作成時に自動的で公開チェックフラグを付けるロジックを実装した場合、ケースの「内部コメント（Internal Comments）」項目の運用は不可能になってしまう（内部向けのコメントが顧客に全公開されてしまうことになる）。
  • ケースコメント投稿時の添付ファイルは「ファイル」ではなく「添付ファイル」に保存されるため、場合によっては既存環境でのケース運用のポリシーに反する可能性あり
  • メール通知のテンプレートは変更できない。

実装方針６：CaseCommentに集約（開発）

  1. 顧客がケース作成
  2. Agentがケースコメント投稿 【→顧客にメール通知 （ケースURLを記載）】
  3. 顧客がケースコメント投稿
  4. Agentがケースコメント投稿 【→顧客にメール通知 （ケースURLを記載）】
  5. 顧客がケースコメント投稿
  6. <以下略>

前提となる設定（Internal Comments標準項目の廃止）

  • ケースの「内部コメント（Internal Comments）」項目に対するアクセス権をシステム管理者を含むすべてのプロファイルから剥奪し、ラベルを【使用禁止】に変更する。

必要となる開発

  • ケースコメント表示用コンポーネントのVisualforceまたはLWCによる開発
  • メール通知自動送信ロジックの開発
  • ケースコメント自動公開ロジックの開発

※参考： ケースコメント自動公開ロジックをApexTriggerで開発する場合

trigger PublicComment on CaseComment (before insert, before update) 
{
for (CaseComment cc: Trigger.New) {
cc.IsPublished = true;
}

}

cons

  • Community上で「ケースコメントパブリッシャー」コンポーネントからケースコメントを投稿しても、画面上に変化がないというUX上の致命的な問題
  • コア側画面からのケースコメント作成時のファイル添付不可。従って、Agentがケースコメントにファイルを添付する場合は、毎回コミュニティにログイン→ケースレコードページに遷移という手順を取るか、あるいは「添付ファイル（≒ファイル）」にファイルをアップロードする必要あり。
  • 今回の実装方針の場合でも、Agent側のケースコメントレコード作成画面には「公開」チェックフラグが残り続けるため、チェックフラグをその都度付けるという不要な工数は省略できない。
  • 同様に、自動化ロジックによってケースコメントが全て公開されると知らずにAgentが下書きを誤って送信してしまう可能性を含む、「公開・非公開」に関するあらゆる混乱の可能性

重要な参考情報

Salesforce公式のPartnerCommunityは実装方針6で作成されている。

ただし、これはSummer`19のリリースで廃止された「ケースコメント」コンポーネントの利用によって（上記分析によるconsが存在していないが故に）可能となっていると言える。