To understand how these numbers are built, we have to look "under the hood" at how Zendesk Talk uses WebRTC (Web Real-Time Communication).
Zendesk doesn't just guess if a call was bad; it listens to the data stream of every call "leg" (the connection to the agent and the connection to the customer) and logs specific network events.
Here is the technical breakdown of how those metrics are calculated:
1. The Thresholds: What triggers a "Bad Quality" flag?
Zendesk uses industry-standard thresholds to label a call leg as "Bad Quality." If any one of these three metrics crosses the limit at any point during the call, the entire leg is flagged:
Jitter (> 30ms): Jitter is the variation in the time it takes for data packets to arrive. If the "gap" between packets fluctuates by more than 30 milliseconds, the audio becomes choppy, and Zendesk flags it.
Packet Loss (> 1%): Voice data is sent in tiny packets. If more than 1% of those packets are dropped (usually due to a weak Wi-Fi signal or congested network), the call is flagged. Even 1% loss can cause words to be "clipped."
Latency (> 150ms): This is the "round-trip time" it takes for audio to travel. When latency exceeds 150ms, you get that awkward "walkie-talkie" effect where both people speak at the same time because of the delay.
2. How the Metrics are Calculated
In the Voice - Calls dataset, Zendesk uses a binary classification for quality.
Good Quality Calls: A call where every leg (Agent, End-user, and any Transfers) remained below the thresholds mentioned above.
Bad Quality Calls: A call where at least one leg crossed a threshold.
Quality Rate: This is a standard calculated metric.
$$\text{Quality Rate} = \frac{\text{Good Quality Calls}}{\text{Total Calls}}$$
3. The "Leg" Logic: Agent vs. End-user
This is the most important technical distinction for a Solution Consultant. Zendesk Analytics tracks quality for the Agent Leg and the End-user Leg separately:
| Metric | Where the data comes from |
|---|---|
| Agent Leg Quality | Collected directly from the Agent's Browser/Workspace. It measures the connection between the agent's computer and the Zendesk/Twilio servers. |
| End-user Leg Quality | Collected from the PSTN (Public Switched Telephone Network) or the carrier. If a customer is calling from a basement with one bar of signal, it will show as a "Bad Quality End-user Leg." |
Why this matters: If your Quality Rate is low, but the Bad Quality Agent Legs metric is also low, the problem isn't your office network—it's your customers' phone service providers. If Bad Quality Agent Legs is high, your IT team needs to check your office's firewall or the agent's ISP.
4. How "Agent Leg Quality Issues" is built
This report is an Attribute-based count. During the call, the browser sends "RTC Statistics" to Zendesk. If a threshold is hit, a specific "Event" is tagged to that Call ID:
audio_input_level_low(Microphone issues)high_jitterhigh_packet_losshigh_pdd(Post Dial Delay)
Explore simply counts these tags. When you see a bar chart of "Issues," you are looking at a count of how many times those specific RTC events were fired.
Pro Tip for Custom Reporting
If you want to get granular, you can create a Standard Calculated Attribute to group your agents by their quality. For example, you can create a "Network Health" bucket that labels agents as "At Risk" if their individual Bad Quality Agent Leg rate is over 10%.
Comments
Article is closed for comments.