What it does

CQD is the tenant-wide view of Teams call and meeting quality — aggregate reports by building, subnet, network type, client and device, rather than one user's bad afternoon. It's only as useful as the building file you upload, which maps your subnets to named sites so you can see quality per office instead of per anonymous IP.

Key facts

• CQD is at https://cqd.teams.cloud.microsoft, or Teams admin center > Analytics & reports > Call Quality Dashboard. Call records typically appear within 30 minutes of the call ending.
• Full access (view, EUII, build reports, upload building data, activate CQD): Global Administrator, Teams Administrator, Teams Communications Administrator. Teams Communications Support Engineer and Global Reader can view EUII and build reports but not upload. Teams Communications Support Specialist and Reports Reader see reports without EUII.
• First access needs an account with the "activate CQD" right; after that, lower roles can get in.
• End-user identifiable information is kept for 28 days and then deleted. Users scoped to administrative units can't see EUII even if their role allows it.
• Delegated administration for Microsoft partners isn't supported — consultants need a role in the client tenant.
• Upload building and endpoint files from Teams admin center > Analytics & reports > Building and endpoint data > Upload. Reporting labels in the admin center were retired from 15 September 2025 in favour of this page.
• Files are .tsv or .csv with no header row. The building file has exactly 15 columns in order: NetworkIP, NetworkName, NetworkRange, BuildingName, OwnershipType, BuildingType, BuildingOfficeType, City, ZipCode, Country, State, Region, InsideCorp, ExpressRoute, VPN.
• NetworkRange accepts 8–28 bit masks, so supernetting is allowed. The expanded file is limited to 1,000,000 rows; anything bigger is rejected.
• The VPN column set to 1 fully expands the subnet — use it only for VPN pools where the vendor doesn't register its adapter properly, and sparingly.
• The endpoint file has 7 columns (EndpointName plus make, model, type and three labels), 64 characters each; EndpointName must be unique and is case-sensitive.
• Building files can take up to 4 hours to process. Microsoft publishes downloadable Power BI query templates for CQD.

When to use / skip

Every Teams Phone or Teams Rooms deployment should have CQD set up with a building file before go-live, not six months later when someone complains. It's how you prove the network is fit, find the one site with a bad Wi-Fi controller, and answer "is Teams quality worse than the old system?" with data rather than anecdotes.

For a small organisation with one office and everyone at home, a building file adds little — call analytics for individual cases and the default CQD reports are enough. Anywhere with multiple sites, though, CQD without building data is a list of subnets nobody recognises, and the Missing Subnet report is half the value.

Configuration decisions

• Who owns the building file. It needs to come from IPAM or the network team and be maintained as subnets change — decide that before you build it.
• Granularity: one row per /24 for floor-level detail, or supernets per building for a smaller, simpler file.
• How to name buildings and networks so reports read well. Include region and site codes, and label VPN pools with "VPN" in the name.
• Which subnets count as InsideCorp, and which (if any) go over ExpressRoute.
• Whether 192.168.0.0 ranges get mapped at all — they're ambiguous between home routers and small satellite offices.
• Whether to upload an endpoint file to tag devices by model or asset group, which helps when one laptop model is the problem.
• Whether to report in CQD directly or through the Power BI templates for the client's service desk or network team.

Gotchas

• Building files are effective-dated. You can't have two files covering the same period, so adding subnets means downloading the current file, end-dating it, appending rows and re-uploading with a new start date.
• New uploads are checked for overlaps against what's already there. Old, forgotten files cause wrong subnet-to-building mappings.
• Only calls after the file's start date get the building data. Don't expect history to be relabelled unless you upload with a backdated start.
• Setting VPN=1 on big ranges blows up the expanded row count and slows queries. Use it for the VPN pools that genuinely need it.
• A building file is support data under the Office 365 agreement and visible to Microsoft engineers for support. Don't put anything sensitive in the labels.
• EUII disappears after 28 days. If you're chasing a specific user's call from last month, CQD won't show who it was.
• Partner GDAP/DAP access doesn't work for CQD. Sort out a proper role in the customer tenant early.

Consultant notes

• Grab the template from the upload page, build the first file with the network team, and upload it as early as possible so data accumulates before go-live.
• Run the Missing Subnet report a week after upload. It always finds a handful of subnets nobody told you about.
• Build a small set of CQD views the client will actually look at — poor stream rate by building, Wi-Fi vs wired, TCP vs UDP — rather than handing over the full template.
• Put the building file maintenance task into the client's run book. A file that's a year out of date is worse than none.
• Pair CQD trends with call analytics for individual cases; CQD tells you where, call analytics tells you why for one call.

---

Recheck the CQD URL and admin center menu path at the next review; both have moved more than once