Dynamics 365 Contact Center: Troubleshoot Average Wait Time Diagnostics in Application Insights

Microsoft has moved to close that explainability gap in Dynamics 365 Contact Center. Tracked under AI at Work roadmap ID 576779 (and previously circulated to tenant administrators via Message Center post MC1296257, as archived by M365 Admin and Modern Workspace Pro), the feature Unified routing - Use average wait-time diagnostics for wait-time predictions is now Launched for Web in Worldwide (Standard Multi-Tenant) cloud instances. While early Message Center communications in April and May 2026 projected a late-May rollout, Microsoft’s 2026 Release Wave 1 plan and current roadmap entry record general availability as August 2026, enabled automatically for administrators, makers, marketers, and analysts.

Rather than altering the underlying algorithm that predicts queue delays, this update instruments the lifecycle of Average Wait Time (AWT) inside Azure Application Insights and pairs that telemetry with historical comparison capabilities. For IT pros and contact center architects who have ever had to open a support ticket with Microsoft just to find out why an overflow threshold didn't fire or why a customer wasn't shown a wait estimate, here is a complete breakdown of what is now logged, how the underlying math actually behaves, and the architectural gotchas you need to keep in mind.

What Just Launched: End-to-End AWT Telemetry in Application Insights​

In a modern omnichannel environment, "average wait time" is not merely a polite UI string; it is an operational trigger. Dynamics 365 Contact Center uses AWT both to set customer expectations on incoming sessions and to drive automated queue overflow logic. According to Microsoft’s queue overflow administration documentation on Microsoft Learn, administrators can configure voice queues to trigger overflow actions—such as transferring to another queue, offering a direct callback, or routing to voicemail—when the predicted wait time exceeds a defined threshold between 30 seconds and 60 minutes.

Until now, when that prediction looked wrong or failed to display, supervisors were essentially flying blind. The legacy built-in unified routing diagnostics interface in Dynamics 365 Customer Service has been deprecated in favor of exporting rich conversation diagnostics to Azure Application Insights. While Microsoft states in its unified routing FAQs that no extra Dynamics 365 licenses are required to use routing diagnostics, organizations do need an active Azure Monitor / Application Insights subscription configured to ingest and query the telemetry.

With roadmap item 576779 now live, Dynamics 365 Contact Center writes comprehensive AWT diagnostic events to Application Insights at two critical checkpoints in the interaction lifecycle:

1. At Conversation Start: When an incoming conversation begins and unified routing evaluates whether an average wait time estimate should be displayed to the customer.
2. Upon Availability API Queries: Whenever the platform’s representative availability APIs are called and return an average wait-time value (where applicable).

Inside the Diagnostic Payload​

According to Microsoft’s release notes and the official Understand conversation diagnostics data documentation on Microsoft Learn, every logged event carries standard correlation metadata—including channel type, organization ID, conversation ID, scenario, and subscenario—alongside specific AWT diagnostic properties.

In the Application Insights schema for conversation diagnostics, this appears under the non-channel-specific subscenario AverageWaitTimeEstimate. Within the event’s Omnichannel.description JSON object (and top-level telemetry fields), administrators can inspect:

Microsoft’s conversation diagnostics documentation notes that once unified routing processes a work item, its corresponding telemetry begins appearing in Azure Application Insights within 15 minutes.

Why does this specific schema matter so much on a Tuesday morning when the helpdesk is on fire? Because it immediately bifurcates troubleshooting. Previously, if a customer complained that they waited 25 minutes without warning, an admin couldn't tell if the queue calculation engine had failed to compute a number or if the front-end channel widget had suppressed it. Now, if you query Application Insights by ConversationId and see AWTValue: 45 alongside WasAWTInformedToCustomer: false and a populated Reason string, you know instantly that the math engine worked fine—and you know why the system chose not to show it.

Section Summary:

• Feature Status: Launched (GA August 2026) for Dynamics 365 Contact Center on the Web in Worldwide Multi-Tenant clouds; enabled automatically for admins, makers, marketers, and analysts.
• Two Logging Triggers: Events fire when a conversation starts (evaluating customer display) and when availability APIs return AWT data.
• Key Schema (AverageWaitTimeEstimate): Exposes QueueId, AWTValue (in seconds), WasAWTInformedToCustomer (true/false), and Reason inside Application Insights.

Under the Hood: Why "Missing" Wait Times Usually Aren't Bugs​

To make sense of what the new Reason field and AWTValue metrics are telling you, you have to understand the strict mathematical guardrails Microsoft uses to compute wait times in the first place. A shocking number of "broken wait time" escalations in Dynamics 365 are actually the system working exactly as designed.

According to Microsoft Learn’s documentation on showing customers their average wait time in a queue, the calculation engine is governed by six strict rules:

1. Exponential Moving Average (EMA): Dynamics 365 does not use a simple arithmetic mean over the last hour. It uses an exponential moving average algorithm where the current average carries higher weight, gradually shifting toward the wait times of the newest conversations. This prevents a single outlier call from wildly whipsawing the estimate.
2. Connected Conversations Only: The algorithm only factors in conversations that actually connected to a service representative. Abandoned conversations are excluded. Think about the operational implication here: if your contact center is severely understaffed and 80% of callers hang up after 15 minutes while the lucky 20% get answered in two minutes, the AWT calculation only sees the two-minute connections.
3. 10-Minute Background Cadence: The calculation runs as a background job every 10 minutes, rather than recalculating on every single state change in the database.
4. The 20-Conversation Minimum Cold Start: A queue must accumulate a minimum of 20 completed conversations before the system will display an average wait time to customers. Low-volume specialized queues often fail to meet this threshold.
5. The 7-Day Inactivity Reset: If a specific queue receives zero conversations for seven consecutive days, the calculated average is wiped clean. Once traffic resumes, the queue must process another 20 conversations before estimates will appear again.
6. The One-Minute Floor and Static Display: Customers waiting in a live chat or voice queue only receive a notification (Average wait time <n> mins) when the calculated AWT is greater than one minute. Thus, an AWTValue of 45 seconds in your Application Insights logs will legitimately result in WasAWTInformedToCustomer: false. Furthermore, once an estimate is shown to a customer, it is static—it does not dynamically tick downward for that specific user.

How to Verify Your Customer Wait Time Configuration​

If your logs show that estimates aren't being communicated on a live chat or voice channel, verify that the display toggle is actually turned on in the Copilot Service admin center:

1. Navigate to the Workstreams section and open the workstream you need to inspect.
2. On the channel Settings page, switch to the Behaviors tab.
3. Confirm that Customer wait time is selected (this single checkbox controls both position in queue and average wait time display).
4. Select Save and Close.

Admin Caveat on Skill-Based Routing: Microsoft explicitly warns that if you use skill-based routing configured with exact skill match, the queue position shown to a customer in the chat portal widget might not be accurate, and representative assignment can take longer than expected. While that caveat applies specifically to queue position rather than the new AWT diagnostic logs, it is a vital piece of context when comparing predicted wait experience against actual assignment delays.

Section Summary:

• Algorithm Rules: Uses an exponential moving average (EMA) updated every 10 minutes based strictly on connected (non-abandoned) calls.
• Suppression Thresholds: Wait times are never shown to customers unless the queue has logged at least 20 conversations (resetting after 7 days of silence) and the calculated estimate exceeds 60 seconds.
• Admin Toggle: Controlled per workstream under Channel Settings > Behaviors > Customer wait time.

The API Angle: Probing Wait Times Before and During Conversations​

The second pillar of roadmap item 576779 is logging diagnostic events when availability APIs return average wait-time values. Many enterprise deployments do not rely on Microsoft’s out-of-the-box chat widget alone; instead, they build custom web portals, mobile apps, or AI agent escalation flows that query Dynamics 365 Contact Center programmatically before deciding whether to expose a "Chat Now" button or escalate a bot session.

Microsoft provides two primary Dataverse Web API endpoints for this purpose (requiring the Omnichannel administrator role and a Microsoft Entra ID bearer token with user_impersonation permissions):

• POST /api/data/v9.2/CCaaS_GetRepresentativeAvailabilityBeforeConversation: Queries queue and representative availability before a customer conversation even starts.
• CCaaS_GetRepresentativeAvailabilityForConversation: Queries availability during an active conversation using a valid conversation ID (for example, when a Copilot Studio AI agent checks whether human representatives are available before escalating).

What the API Returns—and Its Architectural Blind Spots​

When an external application calls CCaaS_GetRepresentativeAvailabilityBeforeConversation, the JSON response returns several availability signals alongside two distinct wait-time fields:

• averageWaitTime: Average wait time in minutes for the target queue.
• AverageWaitTimeInSeconds: Average wait time in seconds for the target queue.

Curiously, in Microsoft’s own documented sample payload for this endpoint, the response returns "AverageWaitTimeInSeconds": 45 alongside "AverageWaitTime": null. Because 45 seconds is under a full minute, developers and administrators inspecting API responses or Application Insights telemetry should always check the seconds-granularity field rather than assuming a null minute value means no prediction exists.

More importantly, when comparing the new API diagnostic logs in Application Insights against actual routing behavior, architects must account for two documented limitations of the representative availability APIs:

1. No Overflow or Percentage Routing Awareness: The availability APIs do not factor in queue overflow handling or workstream-level percentage-based routing configurations.
2. First-Match Queue Evaluation: If a workstream has multiple route-to-queue rules that match the incoming context, the API simply returns metrics based on the first matching queue.
3. Staggered Refresh Intervals: While queue metrics like average wait time and queue position refresh in near real time, representative availability (isAgentAvailable and NumberOfExpertsAvailableInQueue) refreshes approximately every 5 minutes, and queue operating hours refresh every 10 minutes.

Having Application Insights log the exact AWT value returned by the availability API alongside the conversation's diagnostic trail means developers and routing admins no longer have to argue over what the API reported at the moment a custom portal decided to route a customer.

Section Summary:

• API Coverage: Diagnostics capture AWT returns from CCaaS_GetRepresentativeAvailabilityBeforeConversation and CCaaS_GetRepresentativeAvailabilityForConversation.
• Field Granularity: The API exposes both averageWaitTime (minutes) and AverageWaitTimeInSeconds (seconds).
• Routing Boundaries: The APIs evaluate only the first matching queue and ignore overflow rules and percentage-based routing splits.

Historical Analytics: Comparing Predictions Against Reality​

Telemetry logs are invaluable when investigating a specific customer escalation, but you cannot tune a 500-seat contact center by reading JSON payloads one conversation at a time. To address macro-level tuning, the August 2026 release also introduces historical analytics for average wait-time accuracy.

Supervisors can now directly compare two curves:

• Predicted Wait Times: The average wait-time values that were actually shown to customers.
• Actual Wait Times: The real wait times experienced by those conversations before connecting.

Why is this side-by-side comparison so critical for contact center operations?

First, remember that the EMA algorithm ignores abandoned calls and updates on a 10-minute cycle. During a sudden traffic spike—say, a regional service outage or a flash sale—actual wait times can surge dramatically before 20 connected calls complete and pull the exponential moving average upward. By comparing predicted versus actual wait times in historical reports, supervisors can spot the exact time blocks where the prediction lagged reality.

Second, it takes the guesswork out of tuning queue overflow thresholds. If a voice queue is set to overflow to a backup vendor or trigger a callback offer when predicted AWT hits 10 minutes, but historical analytics reveal that customers who were quoted a 6-minute wait actually waited 14 minutes, supervisors have hard data proving they need to lower the overflow trigger threshold or adjust staffing shifts.

A Quick Metric Sanity Check: When reviewing historical reports in Dynamics 365 Contact Center, supervisors should be careful not to conflate Average Wait Time (AWT) with Average Speed to Answer (ASA). In Microsoft’s historical analytics definitions, AWT measures the average time customers waited before connecting to a representative across sessions within a conversation, whereas ASA specifically measures the time spent in a queue until a representative accepts the offer. Keeping those definitions distinct ensures you are comparing apples to apples when auditing prediction accuracy.

Section Summary:

• Prediction vs. Reality: Supervisors can compare the AWT quoted to customers against the actual wait time experienced.
• Operational Payoff: Directly informs staffing adjustments and the calibration of voice queue overflow thresholds (which can be set between 30 seconds and 60 minutes).

Practical Troubleshooting Checklist for Dynamics 365 Admins​

If you are managing a Dynamics 365 Contact Center environment and want to put these new diagnostics to work immediately, walk through this verification workflow:

1. Confirm Application Insights Data Export is Active: Because the legacy in-app unified routing diagnostics page is deprecated, ensure your Dynamics 365 Contact Center environment is actively exporting conversation diagnostics to an Azure Application Insights instance.
2. Locate the AverageWaitTimeEstimate Subscenario: In Application Insights, query your conversation diagnostics logs (which populate within 15 minutes of routing) for the AverageWaitTimeEstimate subscenario, or filter by a specific ConversationId or QueueId.
3. Check WasAWTInformedToCustomer and Reason:
   • If WasAWTInformedToCustomer is false, inspect AWTValue and Reason.
   • Check whether AWTValue was 60 seconds or less (which suppresses customer notifications by design).
   • Check whether the target queue had fewer than 20 connected conversations over the past 7 days.
   • Confirm that Customer wait time is enabled under Behaviors in the workstream's channel settings.
4. Audit Custom Availability API Integrations: If you use CCaaS_GetRepresentativeAvailabilityBeforeConversation to gate chat widgets or voice trees, cross-reference the API AWT diagnostic events with your workstream’s overflow and multi-queue routing rules to ensure the API's first-match queue behavior isn't skewing expectations.
5. Review Historical Discrepancies Before Changing Overflow Rules: Compare quoted AWT against actual conversation wait times across peak hours before tightening or loosening voice queue overflow timers.

The Bottom Line​

Microsoft’s addition of average wait-time diagnostics in Dynamics 365 Contact Center isn't a flashy generative AI parlor trick—it is pure, unadulterated operational plumbing. And frankly, it is the exact kind of plumbing enterprise admins need. When routing systems operate as black boxes, supervisors lose trust in automation and disable features like wait-time notifications or automated overflow altogether. By logging every AWT evaluation in Application Insights with a clear boolean flag and reason code, and pairing that with historical accuracy comparisons, Microsoft has finally given contact center teams the receipts they need to prove what the system calculated, what the customer saw, and how to tune the queue for tomorrow's rush.