In this post I will continue my series on information needed to help
prepare for the MB2-714 exam, this time I will look at Service Analysis.
In this post I will look at;
Dashboards present a personalized page(snapshot) of information including iframes, web resources, lists and charts relating to customer service information. (Or any data from CRM.) As well as presenting information you can use dashboards to interact with the underlying records.
Users can create personal dashboards based on predefined template layouts, these can then be shared with other CRM users. Also within the system a number of pre-configured system dashboards exist. Some will come pre-built (out of the box) plus others can be added by developers.
One of the out of the box dashboards is called “Customer Service Manager Dashboard”. This is designed to give a service manager an overview of the status of “service” across the organisation. It includes;
Other key dashboards to be aware of include;
Customer Service operations dashboard – designed to help operation managers see an overview of overall process of customer service
Customer Service Performance Dashboard – shows individual agents how they are doing and their performance against defined goals.
Customer Service Representative Dashboard – this is actually very similar to the customer service performance dashboard but contains lists of data.
Customer Service Social Dashboard
It is worth noting that two versions of the Customer Service Performance Dashboard and Customer Service Social Dashboard exist. (An original version and a new version.)
PowerBI Service Dashboard
PowerBI dashboards can be used to give a 360 view of business with real-time dashboard data, PowerBI can connect to important elements of organisational data including sales, customer service and marketing. PowerBI can also connect to multiple data sources such as Excel, PowerBI desktop files, CSV files, OneDrive files and many more. Within PowerBI users can build their own reports (straight from the dashboard) or use pre-configured dashboards. These capabilities combine to provide reporting abilities far beyond the standard dashboards within Microsoft Dynamics CRM.
User interact with PowerBI dashboards via www.powerbi.com or from the PowerBi app in Ofice 365 portal. PowerBI users have the ability to synchronize Microsoft Dynamics CRM data with the PowerBI dashboards.
Microsoft provide “default” PowerBI dashboards for sales and service functions.
PowerBIs capabilities include being able to plot data bases on geographic location.
Service Reports
There are a number of pre-configured service reports or users can create their own reports. Not forgetting the existence of advanced find. (Which can sometimes be used to create reports quickly for a lesser “cost”.)
Pre-configured reports include case summary table, neglected cases, Service Volume Activity Report, Top Knowledge base article report etc. During your preparation for the MB2-714 exam it is worth running these reports to become familiar with their content.
It is also possible to leverage Excel exports and Excel Templates to report on service performance. (Making use of Excel features such as pivot tables.)
Some Example reports (I suggest you look at the detail of all the system reports in your organisation!) …..
System Charts and Cases
There are four conceptual steps to creating charts;
Column Chart or Bar Charts – Good for showing data changes over period of time or comparing data. (e.g. Actual v estimated revenue.)
Area Charts – Highlight the amount of change over a period of time.
Line Charts – Continuous data streams over periods of time showing changes / trends in the data.
Pie – Proportional representation of data. (% of cases of what priority etc.)
Funnel Charts – Used to show proportional “progression” towards a goal. Such as with a sales pipeline chart.
Multi-Series charts – allows representation of multiple series of data on one chart.
Comparison / Stacked Charts – Used when data sets need to be broken down. For example: Cases by priority over time.
Tag Charts – These are used for the interaction centric dashboard. Used for displaying unstructured information. Like when someone applied tags to a blog!
Note: Other Charts, donut charts, Radar charts and even bubble charts are all possible. These however cannot be created directly from the web interface. These require changes to the chart XML. And as such will not be included in the scope of the MB2-714 exam.
Before creating charts, you may find an existing chart that can do the job, system charts on cases include;
Customer service metrics might include;
Goals can be created and maintained from either the Sales or Service areas of CRM.
Goal Metric – Allows a user to define how a goal is measured. For example: counting the number of cases, revenue sold etc. The CRM solution comes with a number of out of the box goal metrics such as “No. of Cases” but you can also define others. Rollup fields form part of the goal metric, these contain the calculated fields that are used to derive the actual and in-progress values. When defining the in-progress and actual fields, the user not only says how the field will be calculated but also decides on which date the field will apply. For example: in-progress cases might get counted based on their created date but actual resolved cases will get counted based on the resolution date.
Goal Target – What you’re shooting for. For example: To resolve two hundred cases per month or sell £100k of a given product per quarter. A goal target has a concept of actual and in-progress. The actual target might be to resolve 100 cases between Jan and March, the in-progress figure would reflect the number of currently open cases. All goals must have a target value.
Goal Owner – Every goal is tied to a user or team that owns the goal.
Parent Goals – A parent goal is used to group goals. A manager might (for example) have twenty direct reports. Each of these people would have a goal that they own. But all are grouped under the parent goal to see how the group collectively performs. Meaning the parent role becomes an aggregated version of the child goals.
Goal Period -All goals are time bound, whenever a goal is created you need to identify the time period it will “run” for. E.g. Week, month, year or a fiscal period. Fiscal periods, each goal can be linked to a fiscal period. If a fiscal period is selected you must select the year, linking the goal to a specific period in time. Fiscal periods might refer to a year that starts on a different basis, for example for many companies their fiscal year runs April to March. So period 1 is April. (Rather than January!) Alternatively, a custom period can be entered, for this the user must enter a specific start and end date.
Each Goal will have goal criteria, defined on the goal form;
Roll Up Only from Child Goals – This option may often be used on a parent goal when you want the goal to simply be an aggregate from all of the child goals. For example: Each sales person might have an individual goal. The parent goal may then simply be a sum of all the sales people that work in a given territory / team.
Record set for Rollup – Typically each goal will represent cases, sales, etc. that apply to an individual (or team) that owns the records. However, this option can be used to create an organisation wide goal.
Rollup Queries – In some cases you’ll need to fine tune the data sets. For example: To only count cases for a specific territory. In this circumstance rollup queries are used to articulate the records to be counted. You can define and add rollup queries for in-progress and actual queries. A rollup query is essentially an advanced find used to further filter the data. It is important to notice that the entity type MUST be the same as the entity selected for the goal.
Calculating / Recalculating Goals
Goals will be automatically recalculated periodically throughout the day but users with correct permissions can also select the “Recalculate” button to force a calculation on demand. Sometimes useful when a new goal is first created as actual values will not be updated when the goal is first saved. (Unless you do a recalculate.)
Once the calculation has run automatically or by selecting the Recalculate button the actuals (and in-progress values) can be seen on the goal form.
Goal Charts
When viewing charts you have a number of charts to represent goals.
Including;
Notice that on a goal progress chart there are four pieces of information represented;
Wow, I hope you got all of that! Goals in particular have quite a few concepts to remember for the MB2-714 exam. It is worth making sure you have some hands-on experience with these.
I hope you’ve found this post useful for your preparation.
In this post I will look at;
- Using default Service Dashboards
- The PowerBI Service dashboard’s capabilities
- Working with service reports and charts
- Goals and how they apply to service
Dashboards present a personalized page(snapshot) of information including iframes, web resources, lists and charts relating to customer service information. (Or any data from CRM.) As well as presenting information you can use dashboards to interact with the underlying records.
Users can create personal dashboards based on predefined template layouts, these can then be shared with other CRM users. Also within the system a number of pre-configured system dashboards exist. Some will come pre-built (out of the box) plus others can be added by developers.
One of the out of the box dashboards is called “Customer Service Manager Dashboard”. This is designed to give a service manager an overview of the status of “service” across the organisation. It includes;
- Chart of open activities by agent
- Status of cases by SLA date
- Cases by queue
- Cases by priority
- Remaining entitlements by customer
- Plus a view of the wall, which highlights recent events. And gives users the ability to interact with the posts by replying or liking posts.
Other key dashboards to be aware of include;
Customer Service operations dashboard – designed to help operation managers see an overview of overall process of customer service
Customer Service Performance Dashboard – shows individual agents how they are doing and their performance against defined goals.
Customer Service Representative Dashboard – this is actually very similar to the customer service performance dashboard but contains lists of data.
Customer Service Social Dashboard
It is worth noting that two versions of the Customer Service Performance Dashboard and Customer Service Social Dashboard exist. (An original version and a new version.)
PowerBI Service Dashboard
PowerBI dashboards can be used to give a 360 view of business with real-time dashboard data, PowerBI can connect to important elements of organisational data including sales, customer service and marketing. PowerBI can also connect to multiple data sources such as Excel, PowerBI desktop files, CSV files, OneDrive files and many more. Within PowerBI users can build their own reports (straight from the dashboard) or use pre-configured dashboards. These capabilities combine to provide reporting abilities far beyond the standard dashboards within Microsoft Dynamics CRM.
User interact with PowerBI dashboards via www.powerbi.com or from the PowerBi app in Ofice 365 portal. PowerBI users have the ability to synchronize Microsoft Dynamics CRM data with the PowerBI dashboards.
Microsoft provide “default” PowerBI dashboards for sales and service functions.
PowerBIs capabilities include being able to plot data bases on geographic location.
Service Reports
There are a number of pre-configured service reports or users can create their own reports. Not forgetting the existence of advanced find. (Which can sometimes be used to create reports quickly for a lesser “cost”.)
Pre-configured reports include case summary table, neglected cases, Service Volume Activity Report, Top Knowledge base article report etc. During your preparation for the MB2-714 exam it is worth running these reports to become familiar with their content.
It is also possible to leverage Excel exports and Excel Templates to report on service performance. (Making use of Excel features such as pivot tables.)
Some Example reports (I suggest you look at the detail of all the system reports in your organisation!) …..
System Charts and Cases
There are four conceptual steps to creating charts;
-
Define the purpose of the chartAsk yourself what is the purpose of the chart, an essential preparation step in understanding what data is needed and how the chart is going o need to be formatted. (This could be harder than it sounds.)
-
Prepare the data to be analysedThe data in the environment needs to support the analysis the users require. Sometimes you might need to capture some additional data or perform customizations to format the data in the required manner. E.g. Views miht need to be changed to include suitable fields.
-
Prepare the chartYou will need to ensure the selected chart is going to display the required data in a suitable manner. For example: You might need to limit the data displayed using the “top/bottom” options. Or in some situations use the more advanced approach of exporting the chart XML, customizing it and re-importing.
-
Format the chartAfter selected the correct chart it may need to be formatted or chart type changed. E.g. swapping from a bar chart to a pie chart. Or again “playing” with XML to control colours / labels etc.
Column Chart or Bar Charts – Good for showing data changes over period of time or comparing data. (e.g. Actual v estimated revenue.)
Area Charts – Highlight the amount of change over a period of time.
Line Charts – Continuous data streams over periods of time showing changes / trends in the data.
Pie – Proportional representation of data. (% of cases of what priority etc.)
Funnel Charts – Used to show proportional “progression” towards a goal. Such as with a sales pipeline chart.
Multi-Series charts – allows representation of multiple series of data on one chart.
Comparison / Stacked Charts – Used when data sets need to be broken down. For example: Cases by priority over time.
Tag Charts – These are used for the interaction centric dashboard. Used for displaying unstructured information. Like when someone applied tags to a blog!
Note: Other Charts, donut charts, Radar charts and even bubble charts are all possible. These however cannot be created directly from the web interface. These require changes to the chart XML. And as such will not be included in the scope of the MB2-714 exam.
Before creating charts, you may find an existing chart that can do the job, system charts on cases include;
- Active cases by agent
- Case Mix
- Case Resolution Trend
- Cases by Priority
- Cases by Product
- Cases Resolved by KB Articles
- Resolved Case Satisfaction
- Service Leader board
Customer service metrics might include;
- Average time to resolve a case
- Number of cases closed in the same day
- Number of cases worked on by an operator
- Number of requests by type
- Customer satisfaction level
- Service level agreement
- Percentage of service renewals
- Time to resolve complaints
- etc., etc., etc.
Goals can be created and maintained from either the Sales or Service areas of CRM.
Goal Metric – Allows a user to define how a goal is measured. For example: counting the number of cases, revenue sold etc. The CRM solution comes with a number of out of the box goal metrics such as “No. of Cases” but you can also define others. Rollup fields form part of the goal metric, these contain the calculated fields that are used to derive the actual and in-progress values. When defining the in-progress and actual fields, the user not only says how the field will be calculated but also decides on which date the field will apply. For example: in-progress cases might get counted based on their created date but actual resolved cases will get counted based on the resolution date.
Goal Target – What you’re shooting for. For example: To resolve two hundred cases per month or sell £100k of a given product per quarter. A goal target has a concept of actual and in-progress. The actual target might be to resolve 100 cases between Jan and March, the in-progress figure would reflect the number of currently open cases. All goals must have a target value.
Goal Owner – Every goal is tied to a user or team that owns the goal.
Parent Goals – A parent goal is used to group goals. A manager might (for example) have twenty direct reports. Each of these people would have a goal that they own. But all are grouped under the parent goal to see how the group collectively performs. Meaning the parent role becomes an aggregated version of the child goals.
Goal Period -All goals are time bound, whenever a goal is created you need to identify the time period it will “run” for. E.g. Week, month, year or a fiscal period. Fiscal periods, each goal can be linked to a fiscal period. If a fiscal period is selected you must select the year, linking the goal to a specific period in time. Fiscal periods might refer to a year that starts on a different basis, for example for many companies their fiscal year runs April to March. So period 1 is April. (Rather than January!) Alternatively, a custom period can be entered, for this the user must enter a specific start and end date.
Each Goal will have goal criteria, defined on the goal form;
Roll Up Only from Child Goals – This option may often be used on a parent goal when you want the goal to simply be an aggregate from all of the child goals. For example: Each sales person might have an individual goal. The parent goal may then simply be a sum of all the sales people that work in a given territory / team.
Record set for Rollup – Typically each goal will represent cases, sales, etc. that apply to an individual (or team) that owns the records. However, this option can be used to create an organisation wide goal.
Rollup Queries – In some cases you’ll need to fine tune the data sets. For example: To only count cases for a specific territory. In this circumstance rollup queries are used to articulate the records to be counted. You can define and add rollup queries for in-progress and actual queries. A rollup query is essentially an advanced find used to further filter the data. It is important to notice that the entity type MUST be the same as the entity selected for the goal.
Calculating / Recalculating Goals
Goals will be automatically recalculated periodically throughout the day but users with correct permissions can also select the “Recalculate” button to force a calculation on demand. Sometimes useful when a new goal is first created as actual values will not be updated when the goal is first saved. (Unless you do a recalculate.)
Once the calculation has run automatically or by selecting the Recalculate button the actuals (and in-progress values) can be seen on the goal form.
Goal Charts
When viewing charts you have a number of charts to represent goals.
Including;
- Percentage Achieved
- Goal Progress (Counts)
- Goal Progress (Money)
- Today’s Target Vs. Actuals (Count)
- Today’s Target Vs. Actuals (Money)
Notice that on a goal progress chart there are four pieces of information represented;
- The ultimate target
- Today’s target
- The in-progress total
- The actual amount achieved
Wow, I hope you got all of that! Goals in particular have quite a few concepts to remember for the MB2-714 exam. It is worth making sure you have some hands-on experience with these.
I hope you’ve found this post useful for your preparation.
No comments:
Post a Comment
if you have any doubts, please tell me