Reconciling Contradictory Omnichannel Numbers Before an Audit

When Dynamics 365 omnichannel dashboards disagree with store and web data and executives no longer believe any of them, the cause is rarely a single bug. Channel numbers disagree because each source defines the event differently, counts in different timezones and business calendars, mixes records created by automation with records created by agents, lets SLA pauses distort elapsed time, and counts one customer who contacts you on two channels twice. Before an audit, freeze and preserve the underlying records, write each metric definition down, rebuild one agreed figure end to end from Dataverse and reconcile the difference line by line. Then make the numbers defensible with locked definitions, system-generated records and an auditable change history rather than hand-edited reports.

Why do omnichannel numbers disagree with store and web data?

Because every system is answering a slightly different question, and nobody wrote the question down. A web analytics tool counts sessions or form submissions. A store system counts visits, returns or appointments in local time. Dynamics 365 Customer Service counts conversations, cases or email activities, stored in UTC. Put those side by side on one slide and they will not agree, even when every system is working correctly.

The gaps almost always come from five places:

• Different event definitions. "Contacts" may mean conversations started, conversations accepted by an agent, cases created or cases resolved. A chat abandoned in the queue is a contact in one report and nothing in another, and a web form that fails validation is a submission in web analytics but never becomes a record.
• Timezones and business calendars. Dataverse stores date and time values in UTC, while store systems and many exports use local time. A contact at 23:30 in one country lands on a different day in another, and a report grouped by calendar day will never match one grouped by business day or fiscal week.
• Automation-created records counted as agent work. Automatic record creation rules can turn auto-replies, bounces and internal notifications into cases, flows can create follow-up cases, and bot-handled conversations can close without an agent. All of them inflate volumes and resolution rates unless they are identified and excluded on purpose.
• SLA pauses distorting elapsed time. Handling time and time to resolution measured against SLA timers include or exclude paused periods depending on configuration, so the same case has two durations depending on which field a report reads.
• Duplicates across channels. A customer who emails, then chats, then calls about one problem can become three cases, or three contacts, and each channel report counts its share as a separate demand.

Why does first contact resolution look too good to be true?

A first contact resolution figure that looks too good, such as 90 percent, is usually a counting artefact rather than a service achievement. The most common cause is that a customer who comes back about the same issue gets a new case instead of the original one being reactivated, so the first case still counts as resolved on first contact and the second one often does too. The repeat contact is invisible.

Other causes stack on top. Conversations that time out or are abandoned may close with a resolved-looking status. Bot-contained conversations can be counted as resolved when the customer simply gave up. Cases created from auto-replies are closed immediately as noise and counted as quick resolutions. And a measure calculated per conversation rather than per customer issue cannot see that the same person returned on a different channel the next day. Built-in analytics in Dynamics 365 Customer Service define their metrics in their own way, and those definitions change between releases, so read the current Microsoft documentation for the exact definition before quoting a built-in figure to an auditor.

What should you preserve before anyone touches the dashboards?

The instinct when numbers are challenged is to fix the report or tidy the data. Both destroy the evidence an audit will ask for. Freeze first.

1. Declare a cut-off date and export the records behind the disputed figures as they stand: cases, conversations, email activities, case resolutions, SLA KPI instances and the related contacts, with record IDs and created and modified timestamps.
2. Export the store and web figures for the same period from their source systems, with the timezone each one uses written beside it.
3. Capture the configuration that shaped the numbers: automatic record creation rules, routing rules, SLA definitions and business hours calendars, the flows that create or close cases, and the report and Power BI definitions themselves.
4. Confirm auditing is on for the status and ownership columns that matter, and export the change history you already have. Our guide to Dynamics 365 audit trails for compliance covers what auditing records and how to retain it.
5. Store everything read-only, and agree that corrections go into a recorded adjustment, never back into the snapshot.

The snapshot, file hash and cut-off mechanics are the same as for any reporting under audit pressure, and our post on standing up reporting an auditor will accept sets them out in full rather than repeating them here.

How do you write a service metric definition that an auditor will accept?

One page per metric, signed by the person accountable for it. Service metrics need more precision than most, because the same words mean different things to the contact centre, the stores and the web team. Each definition should state:

• The business question the metric answers, in one sentence.
• The event that counts, named against a Dataverse table and status, for example a case moving to resolved, not "a resolved contact".
• The start and stop timestamps for any duration, and whether paused SLA time and out-of-hours time are included.
• The timezone and calendar the metric is reported in, and which business hours calendar applies.
• What is excluded: automation-created records, bot-only conversations, spam, internal tests, cancelled cases.
• The deduplication rule: what makes two records the same demand, such as the same customer and topic within an agreed window.
• How store and web figures are mapped to it, or a plain statement that they measure something different and should not be compared.
• Owner, approval date and version.

Writing these usually reveals that two dashboards were both right about different questions. That is a finding worth recording in its own right.

How do you rebuild one agreed figure from Dataverse and reconcile it line by line?

Pick the figure the executives or auditors care about most, often resolved cases per channel per month, and rebuild it from the preserved Dataverse records using only the signed definition. Then compare it with the dashboard figure record by record, not total by total.

1. Query the snapshot for the rows the definition includes, carrying the record ID, channel, origin, owner type and every timestamp used.
2. Convert timestamps to the agreed timezone and assign each row to the agreed period.
3. Flag rows created by automation using the created-by user, the origin and any source column, and exclude them as the definition says.
4. Apply the deduplication rule and keep the excluded duplicates in a separate list rather than deleting them.
5. Take the dashboard figure for the same period and list the record IDs behind it.
6. Match the two lists and classify every unmatched record: timezone boundary, automation, duplicate, status changed after the cut-off, definition difference or genuine error.
7. Total each class. The rebuilt figure plus or minus each class should arrive exactly at the dashboard figure, with nothing left unexplained.

The general method of walking a number from source record to report cell is covered in our guide to dashboard numbers that do not match finance. If the dashboard itself fails or truncates on large volumes, read our page on Dynamics 365 reporting aggregate limits before trusting any total it shows.

How do SLA pauses and business calendars distort time-based service metrics?

Time to first response and time to resolution are only as good as the clock behind them. SLA KPI timers can pause on configured statuses, stop outside business hours and be changed by flows or plugins that update the case, so an elapsed-time figure read from SLA fields can differ from wall-clock time between creation and resolution. Neither is wrong, but the definition must say which one the metric uses, and reports must not mix them.

If the pauses themselves look random, that is a configuration fault to fix before any reconciliation, and our guide to fixing random SLA timer pauses in Dynamics 365 Customer Service walks through the status rules, calendars, flows and plugins that cause them. Reconcile time-based figures only after the SLA behaviour is understood, or you will be explaining the same deltas twice.

How do you measure first contact resolution credibly?

Define it per customer issue, not per conversation, and make the repeat contact visible. A credible measure has three parts.

• A reopen window. An issue counts as resolved on first contact only if the same customer does not come back about the same issue within an agreed window, set by the service lead and written into the definition. Reactivating the original case, rather than creating a new one, should be the normal agent behaviour, enforced by process and checked in the data.
• A repeat-contact indicator. For every new case or conversation, flag whether the same customer had a resolved case on a related topic within the window, on any channel. That needs one customer record across channels, which is why identity resolution comes first; our unified omnichannel architecture guide explains how to make one customer one record.
• A sampled audit. Each period, a reviewer reads a random sample of cases counted as resolved on first contact and records whether that was true. The sample result is reported beside the calculated figure, so an inflated rate is caught by people rather than defended by a formula.

Report bot containment separately from agent first contact resolution, and show the exclusions next to the rate. A lower figure with a stated method is far more useful to an auditor than a high one nobody can explain.

Which controls keep service numbers defensible after the audit?

Reconciliation fixes the past. Controls stop the numbers drifting apart again.

• Locked definitions under change control, with the version number shown on every report page.
• System-generated records and timestamps only. No metric should depend on a date or status an agent types in by hand.
• A source or origin value on every case and conversation, so automation, bots, integrations and agents are always distinguishable.
• Auditing on the status, ownership and resolution columns the metrics read, retained for as long as the figures may be questioned.
• No hand-edited exports. Adjustments are recorded rows with a reason, an approver and a date.
• A monthly reconciliation of the headline figure against the source records, and the sampled first contact resolution audit, both kept as evidence.
• Duplicate detection on contacts and a regular merge routine, as described in our Dynamics 365 duplicate data cleanup guide.

When is the real problem the service setup rather than the reporting?

When reconciliation keeps finding the same classes of error. If cases are still being created from auto-replies, if customers are routinely split across several contact records, or if agents cannot reactivate a case easily and create new ones instead, the fix belongs in the Customer Service configuration, not in the dashboard. That is implementation work: automatic record creation rules, routing, identity resolution, SLA design and case process, delivered through our Dynamics 365 Customer Service implementation service.

Where the service operation does not fit Microsoft per-user licensing, the same controls apply to a custom-built service platform on React, Node.js, PostgreSQL or .NET. Solzet reviews and reconciles service reporting on Dynamics 365 and Power BI, with senior consultants and full-stack developers bringing 8+ years of Dynamics 365, Power Platform and custom CRM work.