Microsoft Dynamics 365 Customer Service module is one of the crucial modules in Dynamics 365 Customer Engagement. It is a module for customer service automation that streamlines case and knowledge management, enables personalized customer service with a 360-degree customer view, and provides visibility into customer service department performance with dashboards and reports. It provides front-line support employees with the tools they need to resolve cases quickly and to the highest degree of satisfaction. It helps build customer loyalty and empower agents with a unified CRM to deliver seamless, personalized experiences.
The Customer Service Module deals with below entities:
- Case
- Routing Rules
- Queues
- SLAs
- knowledge Base
- Entitlements
- Cases:
A Case in Dynamics 365 CE represents a record either of a customer complaint or query regarding a product or services entitled. Customers can call to Business Customer Service Representative (CSR) and CSR creates a Case in the system to capture the detail information.
Cases gather into one place key information regarding a customer query /issue, the related customer and key contacts, the reason for the case creation, relevant products or services, and a timeline of actions taken.
By creating cases in Dynamics 365, users can better track the status of a case, understand next steps, and escalate or reassign cases with ease. Which in turn helps make informed decisions and provide greater customer service.
Progressing and tracking cases:
Log and track phone calls, emails, and activities on the case record timeline, to shape a narrative from case creation to resolution; at any time, users can read the timeline and be up to date on how the case is progressing.
The stages a case must go through can and should be tailored to each individual business and its needs, and each will have a set of tasks that need to be completed before moving onto the next stage. Even use branching logic to adapt steps based on the data entered; providing agents the flexibility to deal with service incidents on a case-by-case basis.
Also, have control over the priority of a case, for example set a case as high priority to ensure it is dealt with first.
Resolving cases:
When a case is completed, mark it as resolved, as well as record detail such as resolution type, time taken to resolve, how much of that time is billable, and any further comments.
After giving all Information the Case is Resolved and will be Read-only. In some cases, the Resolved Case can be Re-Opened/Re-Activated.
2. Queues:
A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. Dynamics 365 includes queuing and workflow tools to efficiently manage incoming requests.
From a customer service point of view queues can be a very important concept to allow teams of users to manage incoming requests for service, as they can be routed to suitable queues to ensure the right agents work on the correct pieces of work.
Customer support centres often use queues to manage the routing of cases that come in, so that they are handled in an organized and timely manner. Microsoft Dynamics 365 uses queues to manage work items like cases, activities, or other record types.
Several types of queues are available in Dynamics 365:
- Public: These queues are visible to the whole organization.
- Private: The queues are visible only to users who have been designated as queue members.
- Personal: These queues are associated with a specific user or team and are visible only to that user or team.
Public and private queues are created to support an organization’s needs. By default, personal queues are automatically created when a new user or team is defined. They route important activities and records that are assigned to a specific user or team. Additional queues can also be used to support service management in a team-based collaborative environment.
System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue. With a private queue you must be a member of the queue to see the queue items.
Maintain Queues:
Whenever a user or a team is created a default queue is automatically created, this is their “local user queue”. This shouldn’t be maintained! But system queues can be maintained in the queues option which can be found in the service management area of the customer service hub.
Additionally, queues can be created from the Service Management area of the advanced settings. Or in business management option within advanced settings.
3. Routing Rule Sets:
In Dynamic 365 we use Case entity to resolve customer problems. For each new customer or user, a case is created with unique “ID” and all actions taken on it like “phone calls, emails etc” are tracked and save. Routing rules are used to automatically “Route cases” to right people at right time without any manual intervention. Microsoft Dynamics 365 lets you create predefined routing rule sets that route cases to different queues, based on logic that’s defined in the rule set.
Routing rules give guide to “Dynamics 365” what to do with a case. We can use routing rule set to send escalated cases to the queues.
To define routing rule sets, go to Settings > Service Management, and select Routing Rule Sets.
Under the Business click on “Service Management”:
Select “Routing Rule Set”:
Click on New to Create New Routing Rule Set:
Under the general setting give ‘Name’ and ‘Description’ and hit on ‘Save’ button. Scroll down and hit the “+ button” to add rule items:
There are multiple rule items in one Routing set.
Set the Rule item name and set Routing Set Conditions:
Then set Queues action.
How To Apply Routing Rule Sets:
After creating and activating the rule set it will be automatically applied on those cases which are created automatically. Apply on manually created cases by click on apply “Routing Rules”.
4. SLA:
A Service Level Agreement (SLA) is simply a way of defining and tracking what should happen when a case is created (Or changed). It reflects the agreement between the supplier and client and establishes expectations of service delivery times. For example: For a high priority case resolution must be completed within 8 working hours or first response for a low priority case must be completed within two days of receipt. SLAs act not only as the agreement between supplier and customer but also as a KPI for the supplier to monitor performance levels.
The completion of an SLA and therefore performance against KPIs is achieved by a definition of success and failure conditions, plus (optionally) if a warning should be triggered as a failure state approaches. The actions that should be taken at each stage can be defined, for example sending an email to a line manager if a failure state is approached (With the latest version of SLAs the actions to be completed are actually controls using a Power Automate Flow).
To send Automated email triggers to the users who are higher in the hierarchy, when the cases are not acknowledged or resolved within the SLA time frame.
The following image shows a typical SLA for different types of customers, based on the level of service that has been promised to them.
In this example, three conditions are defined for the SLA:
- Customer Type = Premium/Corporate and Case Priority = High:
- First response within one business hour
- Case resolution within one business day
- Customer Type = Premium/Corporate and Case Priority = Not High:
- First response within four business hours
- Case resolution within two business days
- Customer Type = Standard and Case Priority = Any:
- First response within one business day
- Case resolution within five business days
Based on the type of customer who submits a case and the priority of the case, the SLA takes one of these actions:
- Send a warning email to the owner of the case if he or she is at risk of not meeting the First Response By KPI.
- Send an email to the customer service representative and the customer service manager if they fail to meet the First Response By KPI.
- Update the case record by setting the First Response Sent field for the SLA to No.
- Send a warning email to the owner of the case if he or she is at risk of not meeting the Resolve By KPI.
- Send an email to the customer service representative and the customer service manager if they fail to meet the Resolve By KPI.
- Update the case record by setting the Resolution field for the SLA to No.
Define service level agreement (SLA) details:
Service level agreement (SLA) details define the specific key performance indicators (KPIs) that you want to measure. They also define when a specific item should be applied. As we mentioned in the overview unit, a typical SLA will have multiple SLA detail items defined for it.
For each SLA detail item that you add to an SLA, you must supply the following information:
- Name: Enter the name of the SLA item. This field is required,
- SLA KPI: Select the KPI that you’re measuring. By default, two KPIs are released with the Case entity: First Response By KPI and Resolve By KPI. You can define additional KPIs for the Case entity as needed.
- Applicable When: Defines the conditions that need to exist on the either record the SLA is running against or a related record for the specific SLA item to be applied to the record.
- Success Criteria: Define what a successful resolution of the defined KPI looks like. For example, a resolution might be successful if a specific field on the current or related record is updated.
SLA warnings and failures:
After we have defined what successful fulfilment of the SLA detail item looks like, we must define how long the success criteria can go unmet before a warning of possible failure is set. We must also define how long the success criteria can go unmet before the item is considered to have failed. To define these behaviours, we set up the SLA item failure and SLA item warnings. Each has a time associated with it, and the times act independently of each other.
SLA actions:
SLA actions are used to do a specific task, depending on whether criteria are met. Before actions can be defined, the detail item must be saved. Although actions are backed by the workflow engine, you don’t have all the same options for actions that you have for traditional workflows. For example, you can’t start workflows or custom actions.
The options that are available are Send Email, Create Record, Update, Record, and Change status.
Three types of actions can be defined:
- Success actions: Define the actions that should be run if the success criteria are met.
- Failure actions: Define the actions that should be run if the success criteria aren’t met within the specified failure time.
- Warning actions: Defines what action(s) should be executed if the success criteria is in jeopardy of not being met within the warning time specified.
5. Knowledge Base:
The Knowledge Base is an inbuilt knowledge management solution where you can store information about common issues or products. This feature can be used by customer service employees who require guidance to quickly resolve cases, but it can also be used for customer purposes in a Power Apps Portal.
The Knowledge Base helps us resolve customer service issues more quickly and improve the trust and confidence our customers have in us. When we are working on a case in Microsoft Dynamics 365 Customer Service, we can use the Customer Service Knowledge Base to help us solve several common challenges that our customers face every day. While we are working on a customer case, based on the case title we put into our system, the Knowledge Base will pull up articles with similar keywords.
When it automatically searches through and filters productive matches, we will not only empower our customer service reps to succeed but our customer. It makes the process easy to send to the customer and provides transparency to them in the meantime. As a customer service rep, we can link an article to the case under “Case Relationships.” This helps to document our team’s internal knowledge and resolve each case faster. Or the rep can take things a step further and send the article to the customer. Typically, these documents are already customer-facing, meaning self-service is enabled and the customers may discover answers on their own before they ever approach us.
As a business, to use our Knowledge Base articles, navigate to “Knowledge” on the left-hand side of your screen, and click on “Knowledge Articles.”
6. Entitlements:
In Dynamics 365 Customer Service, users can associate a customer to an entitlement to define the type / level of support that the customer is ‘entitled’ to. Support terms might be based on the product or service they have purchased, or whether they have purchased a support subscription package or a warranty.
Setting up entitlements
By default, Dynamics 365 defines support terms in the form of setting a few cases allowed, or the number of hours allocated to resolving cases for a customer. Granting an entitlement to a customer requires creating an entitlement record and assigning the customer to the record.
The entitlement can then be applied whenever a case is created, or alternatively set it as the default entitlement whenever a new case is opened for this customer. This allows multiple entitlements to be granted to a customer.
