Setting up a Simple Case Management System on Dynamics 365
The article assumes that you are a Dynamics consultant and does not try to technically guide you, but guides you so that you can quickly implement without missing key components
There are 3 main areas to focus on when setting up Case Management on Dynamics 365.
1. Case Settings
- Case creation
- Parent- Child Cases
- Queues and Routing
2. Contract/ Service terms
3. Knowledge Management
Two notable components of this section are Queues and Teams:
- Teams (not linked to MS Teams) are groups with a common skill or belonging to specific departments, etc. responsible for certain tasks
- Queues are support workloads that can be segregated by criteria. E.g. Priority and normal queues, premium customer queues, ‘specific product’ queues, Basic support queue, etc.
Once a case is logged, queues help segregate them and assign it to certain teams. Agents can pick up cases from the queues to which they are assigned.
Source: While Dynamics supports the below sources for automatic case creation Email, Social activity, Task, Phone call, Appointment, Service activity, Custom activity, apart from Manual case creation and creation from email, a prerequisite for other sources would be that they need to be Integrated.
Subject: this can be a multi–level tree view but- this is different – it can only be added from Service Settings.
Conditions for case creation: When an email is received, some configurations/ scenarios to handle.
- Create records for emails from unknown senders.
- Create a case if a valid entitlement exists for the customer
- Create cases for activities associated with a resolved case
- Send automatic email response to a customer on record creation
They are used to track multiple issues for a customer or track the same issue that’s affecting multiple customers or where work needs to be done by various departments for closure. While each case has its own details, a child’s case cannot have another child. The closure on such cases needs to be configured.
- Close all child cases when the parent case is closed
- Don’t allow parent case closure until all child cases are closed
- Allow parent and child to be independently closed
Queues and Routing
At the very base, there are 2 kinds of queues – Public and Private. Private queues are specific user queues and the Public queues are those which are accessible across Organization teams.
Queues are used to have central storage of work and can be classified by:
- Different products or services
- Different subscription levels (regular, premium customers)
- Various activity categories
- Different geography
Routing: Cases and activities can be set up to be automatically routed to Queues or be manually added to them. Rules for automatic routing can be set up and cases regrouped under queues. Routing rules can be used to even ensure that spam and unsolicited emails to a mailbox don’t create cases. Agents or Teams can be given access or set up that everyone in the Organization can access them.
Contract/ Service Terms
A few important concerns which most Organizations have:
- Are cases of priority customers or on Premium support being handled as such
- Are agents able to identify and pick up critical cases from the general cases
- Are Service KPIs being adhered to and cases being resolved timely
To ensure that the above concerns are assuaged, this section is critical and the key to ensuring that customers get the right value for their investment and Organizations, actual customer delight.
Service Level Agreement (SLA)
SLAs are used to measure KPIs of the Service agreement with the customer. SLAs are associated with entitlements and the latter to cases. While Standard SLAs track minutes to failure, Enhanced SLAs set up, lets you Pause SLA time when the case is on “Hold” and Initiate Action (On Success, Reminder for upcoming breach, and Service Level breaches). Enhanced SLAs can be set up based on Geographies from where the case is raised, Org. working hours, and adding multiple conditions for a KPI to apply.
Entitlements are in layman terms, “contracts” governing support engagements. They are translated from the signed Work Orders and used to track the kind of support, customers are eligible for. Key configurations on entitlements:
- Support terms – number of cases or hours
- (if) support per Product or Service type purchased
- Eligibility per channel of engagement -phone, email, etc.
- Service Level applicable
- Customer Contacts eligible
- Contract Duration
A customer can have multiple entitlements and each entitlement can reference multiple cases. Entitlements can be made mandatory on Cases, to prevent any cases being handled out of the contract.
Dynamics Customer Service has a native Knowledge Base Creation, Management, and Publishing mechanism.
A review mechanism to approve and publish articles is available where a certain role can create, and another approve. Knowledge articles can be classified under categories and can be defined as Internal or External.
If using the Dynamics 365 or PowerApps Portal for customer service, KBs marked as Internal, will not be displayed there. Internal KBs can only be viewed within Dynamics.
Cases and KBs are closely linked, users can search through existing KBs while on case record and select a KB as the solution for case resolution.
The next steps after setting up Case management on Dynamics would be to:
- Expose the application to customers using the Portal
- Set up ‘chatbots’ on the portal for an omnichannel experience.