Catalogue › Customer Service › service-analytics

Service analytics

Department

Customer Service

Stages

Initiate, Implement, Operate

Modules

Customer Service

Status

reviewed

Copilot Cowork

Customer Service plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Claude Code

/plugin install customer-service@d365forge

Licence

CC BY 4.0, by Simon Foote, Robert Peledie

A service operation is run on its numbers: supervisors move people between queues, leaders justify headcount, and the business case for the project is judged on them. If the metrics are poorly chosen or inconsistently defined, the operation optimises for the wrong thing and nobody trusts the dashboards.

Projects usually go wrong in two ways. They leave analytics until after go-live, then discover the fields needed for first contact resolution or contact reason were never captured. Or they publish a long list of speed measures with no quality counterweight, and teams learn to close cases quickly and watch them reopen.

When to use

• Choosing a balanced set of service KPIs and writing their definitions.
• Deciding what built-in analytics cover and where Power BI is needed.
• Designing dashboards for agents, supervisors, service leaders and executives.
• Reconciling figures that differ between built-in reports, Power BI and spreadsheets.
• Linking service measures to the project's success measures.

Not this skill: data-and-ai:reporting-strategy for the organisation-wide reporting approach, data-and-ai:fabric-link for analytics data platform choices, change-adoption:adoption-metrics for measuring system adoption, customer-service:slas-and-entitlements for configuring the SLA timers that feed compliance figures.

Questions to ask first

1. What decisions will each metric inform, and who makes them? A metric with no decision owner is decoration.
2. Which channels and record types are in scope? Case metrics and conversation metrics come from different data and different built-in reports.
3. Does the case and conversation design capture what the metrics need? Contact reason, resolution category, origin and reopen tracking must be designed in, not reported around.
4. Is there an existing reporting platform and data team? This decides how far to rely on built-in analytics versus Power BI.
5. Who may see what level of detail? Team-level operational views are routine; individual-level data raises people and privacy questions.

Approach

Pick a small, balanced set of measures that pull against each other, so improving one at the expense of another becomes visible. A sensible core for most service desks covers five areas:

• Demand: new cases and conversations by channel and contact reason.

• Speed: first response and resolution time against SLA.

• Quality: first contact resolution, reopen rate and customer satisfaction.

• Flow: backlog size and age, transfers, and abandonment on real-time channels.

• Knowledge and AI: knowledge use on resolved cases and self-service with a confirmed outcome.

1. Write definitions before building. For each metric state the numerator, denominator, inclusions and exclusions (merged, cancelled and test cases), time basis and time zone. Built-in analytics, Power BI and supervisors' spreadsheets must share the same definitions or the figures will never reconcile.

2. Design the data into the lifecycle. Check that customer-service:case-lifecycle-design captures contact reason, resolution category, origin channel and a way to detect reopens, before build completes.

3. Use built-in analytics first. Customer Service provides historical and real-time analytics for cases, conversations and knowledge; check current Microsoft Learn documentation for the current reports, how they are enabled and how often data refreshes. They are a fast win for supervisors.

4. Extend with Power BI where needed. Cross-module views, telephony or ERP data, and long-history trends belong in a governed Power BI model over Dataverse, built with data-and-ai:power-bi-on-dataverse.

5. Build one view per audience. Agents need their queue and SLA timers, supervisors need real-time flow and backlog, service leaders need trends and outcomes, executives need a handful of outcome measures. Keep each view small.

6. Keep metrics about the operation. Report at queue, team and channel level. Do not design league tables or rankings of individual agents; any use of individual data is a matter for the organisation's HR policy, and privacy questions go to the organisation's DPO or legal adviser.

7. Reconcile, then review. During UAT compare built-in figures, Power BI and a manual count for a sample period. After go-live, review the metric set each quarter and retire measures nobody uses.

Outputs

• Metric catalogue with definitions and owners, referenced from the solution-blueprint.
• Dashboard set per audience.
• Data capture requirements fed back to the case and conversation design.
• Reconciliation tests in test-strategy-and-uat-scripts.
• Service measures linked to the success measures in the project-charter.
• Hypercare dashboard in the cutover-and-hypercare-checklist.

Scale notes

SMB

Built-in dashboards plus a few views usually suffice, defined by the consultant with the service manager. Do not skip written metric definitions or the case fields that feed them, because they cannot be added retrospectively to history.

Enterprise

Expect a governed semantic model owned by the data team, analytics data in a lakehouse via data-and-ai:fabric-link, regional comparisons that need common definitions, and benefits tracking against the business case. Any reporting that exposes individual agent data needs a privacy review and agreement with HR before release.

Hand-offs

• data-and-ai:power-bi-on-dataverse builds the Power BI models and reports.
• support-operations:continuous-improvement uses the metrics after go-live.
• change-adoption:adoption-metrics complements service measures with adoption measures.
• Reviewer sign-off: security-compliance:security-model-review for who can see which service data, and design-authority:standards-conformance for metric and model standards.

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

Never

• Publish a metric without a written definition shared by every report that shows it.
• Build league tables or rankings of individual agents.
• Track speed metrics without a balancing quality metric.
• Leave analytics design until after go-live, when the fields it needs were never captured.