Dynamics 365 Customer Service Components is a set of powerful tools designed to help businesses manage customer interactions and deliver exceptional service. With features like case management, knowledge base, and customer insights, it enables organizations to provide personalized support across multiple channels, including email, phone, social media, and chat.
Dynamics 365 Customer Service Components can help businesses improve customer satisfaction, increase productivity, and reduce costs by automating routine tasks and providing agents with the information and tools they need to resolve issues quickly and effectively. In this post we are looking at these components in more detail.
The components in the Customer Service Lifecyle includes:
- Knowledge articles / or knowledge management
- Service level agreements
- Create rules
- Routing rules
Cases are unresolved items. These items don’t have to be complex problems. It can be something simple as a question in an email. Basically, anything the customer is inquiring about is a case.
Cases can be created manually. This usually happens through a phone call or automatically from email, social media or websites.
In summary cases are:
- Unresolved items
- Any customer inquiry (for instance email, phone, chat, social media or from website)
Next, we have queues. Queues are cases that are waiting for a response. Queues are containers for cases that have similar characteristics, For example, you can have a queue for similar topics or the level of difficulty, or you can even create custom rules for cases.
In summary queues are:
- Case waiting for a response
- Container with similar cases
- Custom rules
Next, we have entitlements. These are contracts that specify what the customer is entitled to, and what they can do. It can include items like who can open a case or channels in which a case can be received on. For example, maybe a customer A is entitled to email support, where customer B is entitled to phone support. Entitlements will also define which products are serviceable.
These contracts can be numeric. For example, customer A has six incident reports for this year, or time-based. A good example of time based is that you’ll receive support within three hours of you email arriving. I know some of you are thinking “Isn’t this an SLA?”. Entitlements are the base of an SLA or a service level agreement.
In summary entitlements are
- Who can open a case
- Channel where a case can be received
- Which products are serviceable
- Time based
Service Level Agreement
A service level agreement defines the level of service or support that you have promised the customer. If you do not meet the terms of the SLA, there are repercussions, usually financial that will need to be met. Most SLAs includes KPIs define what needs to be done in order to meet that SLA. Lets take a look at an SLA example.
Azure SLA Example
Here’s a part of an SLA for Azure Virtual Machines. We can see the promise, how to claim the credit and the exclusions. Please note, this is only a snippet of the Azure VM SLA, it is not the entire agreement. It is used as an example only.
In summary SLAs are:
- Level of service or support
- Consequences if not met
- Includes KPIs
Another component in the Dynamics 365 Customer Service lifecycle is knowledge management. You may also hear this referred to as knowledge base or knowledge articles. Knowledge management is keeping and maintaining a repository of knowledge base of support articles that can be used to help solve issues. This knowledge base can be internal or external. You can even allow customers access to your knowledge base for self-service. A popular external knowledge base for developers is Stack Overflow. In Dynamics 365, the knowledge management solution includes versioning of articles, article lifecycle, translation of articles. That is cool. Article expiration, and the stats allowing you to see what articles are viewed most and which ones are not viewed at all.
In summary knowledge management are:
- Repository of support knowledge articles
- Internal or external
- Self-service portal
- Versioning, lifecycle, translation, and statistics
And finally, we’re down to the customer service lifecycle rules, and there are two types.
Routing rules. These are the rules we create to direct or sort cases into queues. And then there are the automatic record creation rules. These are the rules we configure to create cases from a record. For example, if a customer sends an email to support, a case will automatically be created. The last thing I’m going to touch on here before our review is dashboards.
Dynamics 365 includes interactive dashboards. There is a tier one dashboard, which supports multiple streams. The streams could be from cases with similar activities. Tier two is more focused. It only has one stream based on active cases. And finally, there’s the entity-specific dashboard. These are dashboards that have streams that relate to a single entity. You would typically see this type of dashboard to help manage a large complex problem with many moving parts.
In summary rules are:
- Routing rules
- Direct cases to queues
- Automatic record creation rules
- Create a case from an email
Summary / Review
Now, that we’ve had an overview of the customer service life cycle, let’s put the whole thing together.
First, we have a silver level customer, and they’re entitles to five cases. This user can use the mobile app, email or website to log the issue. These are called engagement channels. Next, we have the rules. These rules will create the case or update. Our customer has a silver level SLA, therefore the response time is three hours, and the case will be routed to the tier one queue. Our agent checks the queue, they then check the knowledge base, resolves the case and now our customer has four cases left.