発生 #3 - 新規ケースの開設
サポートポータルの構築中に、お客様が新しいケースを作成するときに記入するフォームに関連する状況に遭遇しました。Microsoft Dynamics 365 Customer Serviceのこのページのデフォルトのデザインには、一般的なテキストボックスが含まれており、お客様がケースの特殊性について詳細を提供するようになっています。
この形式は、ビジネスによっては十分に役立つかもしれませんが、私たちが求めていた自動化のレベルには達していませんでした。基本的には、ポータルで作成されたすべての新しいケースを、それぞれのケースに対応するのに最適な個人からなるチームを含む適切なキューに速やかにルーティングする方法を探していたのです。効率的であることはもちろん、すべての案件を個別に分析し、適切な専門家へ誘導するよりも時間がかからないのです。
ソリューション - D365カスタマーサービスフォームの再設計
サポートポータルで受け取ったケースの解決を最適化するために、私たちのチームは「新しいケースを開く」ページを再設計する必要がありました。先ほど述べた一般的なクエリーボックスの代わりに、お客様がケースに関する情報を入力するにつれて拡張されるフォームを作成しました。.
ログインしたとき、ユーザーが最初に見ることができるものです：
フォームが完成すると、情報が1つの大きなテキストボックスではなく、異なるフィールドに分割されていることがわかります。システムはこれらの異なるフィールドを読み取り、あらかじめ定義されたプロセスワークフローによって、ケースを適切なキューに正しく誘導することができるようになりました。
ケースが指示されるたびに、受信チームは、サポートポータルで新しいケースを受信したことを知らせる自動メールで警告を受けます。その後、そのチームはCRMにアクセスしてケースを確認し、Dynamics 365カスタマー・サービス・ポータルに問い合わせに対する簡単なコメントであるポータル・コメントを残すか、同じくCRMを通じてカレンダーの予定を送信し、必要であれば電話を手配しなければなりません。また、キューにアサインされたチームメンバーも、サポートケースの更新（ポータルコメントに対するユーザーからの返信など）があるたびに、同じようにメールで通知されます。
Microsoft Dynamics 365 CRMだけでケースを解決することは、私たちのチームにとって慣れないことですが（後述）、すべてのコミュニケーションとプロセスが追跡されるようになったので、非常に有益です。その結果、信頼できるデータを作成し、それを分析することで、顧客満足度を高め、製品ラインを改善し続けるためのイニシアチブを導き出すことができるようになりました。
Connecting Software SaaSポータル
新しいDynamics 365カスタマーサービス・ポータルでは、これは冗長となりました。サポートポータルの主な目的の1つはサポートリクエストを一元化することであるため、SaaSポータルから発生したリクエストが別のチャネルを経由するのは意味がありませんでした。そのため、開発チームはこの「お問い合わせ」フィールドを設定し、お客様を直接当社の サポートポータル.
しかし、ボーナスがあります！お客様がこのページに到達すると、私たちが作成したフォームのいくつかのフィールドは、お客様がどこから来たのかに応じて自動的に入力されます。こうすることで、Dynamics 365カスタマーサービスポータルを開発した目的である、効率性を高めることができるのです。
発生 #4 - 合計添付ファイルサイズ
サポートケースを作成する際、添付ファイルは非常に便利で、ユーザーとサポートを行う専門家の間の情報交換を容易にします。しかし、サポートケースの複雑さによって、添付ファイルの総サイズは異なり、通常、制限があります。
Dynamics 365 Customer Service Portalでは、お客様がケースと一緒に送信できる添付ファイルの合計サイズに5MBの制限があります。簡単なスクリーンショットを添付する場合は十分な容量ですが、画面録画や大量の画像を必要とするケースなどでは、この容量が問題になります。
public void Execute(IServiceProvider serviceProvider)
{
var tracingService = (ITracingService) serviceProvider.GetService(typeof(ITracingService))；
var context = (IPluginExecutionContext) serviceProvider.GetService(typeof(IPluginExecutionContext))；
var serviceFactory = (IOrganizationServiceFactory) serviceProvider.GetService(typeof(IOrganizationServiceFactory))；
var service = serviceFactory.CreateOrganizationService(context.UserId)；
if (!context.InputParameters.Contains("Target") || !(context.InputParameters["Target"] is Entity))
{
を返します；
}
var entity = (Entity) context.InputParameters["Target"]；
var isLoginEnabled = HasLoginEnabled(entity)；
if (isLoginEnabled == false)
{
を返します；
}
try
{
var emailAddress = (string) entity["emailaddress1"]；
var contactsWithSameEmailAddress = GetContactsByEmailAddress(service, entity.Id, emailAddress)；
if (contactsWithSameEmailAddress.Entities.Count > 0)
{
var hasLoginEnabled = HasLoginEnabled(contactsWithSameEmailAddress.Entities[0])；
if (hasLoginEnabled)
{
throw new InvalidPluginExecutionException(OperationStatus.Failed、
"ユーザは既に存在します。別のメールアドレスで登録するか、既存のアカウントでログインしてください；）
}
var mergeRequest = new MergeRequest
{
SubordinateId = entity.Id、
Target = new EntityReference("contact", contactsWithSameEmailAddress.Entities[0].Id)、
UpdateContent = GetUpdateContent(entity)
};
var _ = (MergeResponse) service.Execute(mergeRequest)；
entity[CustomAttributeName] = true；
service.Update(entity)；
}
else
{
var domain = emailAddress.Split('@')[1]；
if (_publicDomains.Contains(domain))
{
SendEmailAndDeactivateContact(service, tracingService, entity)；
}
else
{
var contactsWithSameDomain = GetContactsByDomain(service, entity.Id, domain)；
if (contactsWithSameDomain.Entities.Count > 0)
{
entity["parentcustomerid"] = contactsWithSameDomain.Entities[0]["parentcustomerid"]；
service.Update(entity)；
}
else
{
SendEmailAndDeactivateContact(service, tracingService, entity)；
}
}
}
}
catch (FaultException ex)
{
throw new InvalidPluginExecutionException("ContactPostOperationPlugin でエラーが発生しました。", ex)；
}
}
クローズコード解決策 - 回避策
その他の発生状況
この4つ以外にも、私たちがプロジェクトの初期展開を変更する意思と能力があることを証明する状況がありました。その一例として、私たちは
- Microsoft Dynamics 365 Viewsを採用し、ポータルのコメント記述の検索性を高めた
- HTMLコードを削除し、リッチテキストを含めることで、お客様やサポートチームのポータルコメントの読みやすさを向上させました。
- 外部Knowledge BaseのURLをコンパイルするためのカラムを追加しました。
- 回答が得られない案件を自動的に解決するプロセスを設定する
- Microsoft Dynamics 365のHTMLレンダリング方法について学習し、お客様への情報メールを希望通りに表示できるようにしました(ヒント:HTMLは標準的な形式ではなく、1行のコードであること）。
さらに、マイクロソフトはPower Pagesプラットフォームをよりセキュアにするための一環として、以下の機能を導入した。 データバースアプリケーションユーザーコンセプト.要するに、Webアプリケーション内で実行されるすべてのアクションには、その背後にあるユーザーのタイプがあり、ユーザーのタイプごとに異なる権限があります。
このSYSTEMユーザーは、本記事の第1回で紹介した、弊社が構築したD365ソリューションで使用されていたものです。今回の導入で、このSYSTEMユーザーがApplication Userに変更され、以前のSYSTEMユーザーと同じような権限は持たなくなりました。そのため、構築したソリューションが制限されるようになり、正常に動作しなくなりました。
Microsoftが実装した新しいアプリケーションユーザーに、以前のSYSTEMユーザーが持っていたシステム管理者権限を割り当てることだけが必要だったのです。このプロセスが行われた後、私たちのプラグインは100%の効能を再開しました！
Dynamics 365 CRMトレーニング
さて、サポートポータルを構築する際に直面した技術的なハードルについて説明しましたが、ここではDynamics 365カスタマーサービスポータルを実装する際の管理的な側面、すなわちチームが受けなければならなかったDynamics 365 CRMトレーニングについて簡単に触れたいと思います。プロジェクト・マネージャーなら誰もが言うように、新しい働き方に適応するためのチームのコミットメントは、改善を展開する際の最大の課題の1つとなります。
私たちのチームは、以前は電子メールでカスタマーサポートを行っていたことはご存じでしょう。現在では、ポータルサイトのコメントやミーティングの招待状は、CRMを通じて送信することになっています。このような新しいプロセスへのスムーズな移行を実現するためには、チームにその理由を伝え、時間の節約、継続的な改善のためのレポート作成、カスタマーサポート体験の合理化などの観点から、そのメリットを理解してもらうことが重要でした。また、お客様にとっても、これまで慣れ親しんだメンバーにメールを送るのではなく、サポートポータルを使って問い合わせをすることに慣れる必要があったのではないかと思います。
最後に、ナレッジベースのメンテナンスも変化のきっかけとなりました。Microsoft Dynamics 365カスタマーサービスポータルでは、お客様からの問い合わせをより明確に把握できるようになったため、サポートを提供するだけでなく、この情報をすべてのサポートポータルユーザーがすぐに利用できるように、ナレッジベースに繰り返し事例を追加し続けなければなりません。
テイクアウェイ
これらの出来事は、サポートポータルをお客様のために最高の形にすることができたからだと、私たちはポジティブに捉えています。長いプロジェクトで、チームメンバーの努力と献身が必要でしたが、その成果は間違いなく出ています。お客様にはより便利に、私たちには強力な情報源を提供できるようになったことで、私たちは目標を達成し続けるための力を得ることができたのです。
私たちの制作体験談をご紹介しましたが、いかがでしたでしょうか？ サポートポータル.での 第1部 この記事の中で、私たちが作ったプラグインの一部を紹介しています。 マイクロソフト Dynamics 365 カスタマーサービス.これは私たちにとって非常に有益なものでした。どうぞお気軽にご覧ください！
著者について
記入例 ディオゴ・グーヴェイア
"イギリスでの留学を終えた後、Connecting Softwareのマーケティングチームに加わり、ソフトウェア・インテグレーションやその他様々なITトピックに関するコンテンツを作成しています。何かお気づきの点やご提案がありましたら、ご連絡ください。"