CQD TROUBLESHOOTING

How to identify the cause of poor Microsoft Teams calls using CQD

A practical framework for moving from “Teams calls are bad” to a measurable pattern you can investigate and act on.

Sites N SupportMicrosoft Teams • CQD • VoicePractical guide

Start by turning “bad calls” into a measurable question

A complaint such as “Teams is bad” does not tell you whether the repeated issue is network quality, a location, a device group, a client version, or something else. CQD is most useful when you start with a question that can be grouped and compared across many calls.

Examples of better questions
  • Which office has the highest poor-call rate?
  • Are Wi-Fi users performing differently from wired users?
  • Are specific devices or clients repeatedly associated with poor streams?
  • Did quality improve after a network or hardware change?

1. Confirm what CQD considers a poor stream

CQD uses media-quality telemetry to classify streams. Microsoft documents “Poor Due To” dimensions and network-oriented metrics such as round trip, packet loss, and jitter that can contribute to a poor classification. A poor classification is a signal for investigation — not proof by itself that a user perceived a bad experience.

Microsoft Learn: CQD stream classification →

2. Segment the problem before you chase it

Look for repeatable differences across dimensions that can explain why one population performs differently from another. Useful groupings can include network, building, location, device, client, and other CQD dimensions.

NetworkWi-Fi, wired, VPN, subnet, managed vs. unmanaged.
LocationBuilding, office, city, or defined network site.
DeviceHeadset, laptop microphone, endpoint, manufacturer.
ClientOperating system, Teams client, VDI and version patterns.
Microsoft Learn: CQD dimensions and measures →

3. Compare average performance with spikes and trends

Averages can hide short-lived problems. Use trends and, where available, maximum values or time-based views to determine whether a population is consistently poor or whether the problem appears in bursts. The objective is to separate a recurring pattern from a one-off event.

4. Ask what changed

Once a pattern is visible, connect it to operational changes: a new Wi-Fi rollout, VPN policy, headset model, office move, client version, carrier change, or network path. CQD is strongest when the data is connected to something the organization can actually change.

5. End with an action, not a chart

A useful CQD review should produce a prioritized next step: investigate a building, test a device group, review Wi-Fi capacity, validate a VPN pattern, compare a client version, or measure again after a change. Sites N Support uses CQD to move from complaint → pattern → decision.

Microsoft Learn: using CQD to manage Teams quality →
NEED HELP IN YOUR ENVIRONMENT?

Want help finding the pattern behind poor Teams calls?

Sites N Support can help move from a general Microsoft Teams question to the data, architecture, or licensing decision that matters in your organization.

Book a consultation