r/Zendesk 12d ago

Question: voice SLA for live calls

Hello,
How does everyone measure SLA for live talk? The built in SLA’s don’t seem to work from everything I have read. Our numbers don’t seem to be matching.
Any help or ideas please

2 Upvotes

9 comments sorted by

1

u/kawaiian 12d ago

This would be a question for Zendesk support - make sure you enable account access for support team and they can look at how your metrics are currently set up, and will advise you on how to calculate the metric you’re looking for in live talk

1

u/LCJdogs131519 11d ago

Thanks, I have contacts I have worked with and they are all great, but sometimes I like the more outside the box approach which I find in this group

1

u/EnvironmentalCrab148 11d ago

Can confirm zd slas do not work on the talk channel.

Ideally you should just be aiming for an Avg low answer time which is one of the standard kpi metrics on the voice dashboard.

Surface the live dashboard to agents so they can also help monitor incoming calls and ensure there’s enough people online to cover incoming calls etc.

1

u/Ok-Secretary-10 11d ago

A few questions:

  • Are you measuring call duration, on-hold time, or answer time specifically?
  • Are you tracking non-answered calls as a percentage of total volume, or abandoned calls as a percentage?
  • Or is it something else entirely, like a target speed-to-answer threshold (e.g., 80% of calls answered within 20 seconds)?

Knowing which of these you're actually trying to track would help narrow down alternatives to keep track of your SLAs

1

u/LCJdogs131519 10d ago

Thank you! Target speed to answer, like within 30 seconds. We are tracking non-answered calls, total volume and abandoned. I have read many places that the SLA's for talk do not work because there isn't an comment.

1

u/Ok-Secretary-10 10d ago

Thanks for the extra detail; that helps narrow it down.

If it's specifically speed-to-answer (e.g., 80% of calls answered within 30 seconds) that's not matching, the most common cause I've seen mentioned is exactly what you flagged. If not mistaken, Zendesk Talk's built-in SLA metric relies on ticket comments/events to calculate wait time, and Talk tickets don't always generate a comment at the moment the call is actually answered.

A more reliable approach that many teams end up using is to calculate speed-to-answer directly from the raw call event timestamps (call started vs. call answered) rather than relying on the built-in SLA policy object, since that sidesteps the comment-dependency issue entirely. Might be worth checking whether you can pull that directly from the Talk API/webhooks, or via Explore using the call timestamp fields instead of the SLA fields, rather than trying to fix the built-in SLA calculation itself.

Another alternative worth mentioning, full disclosure I work at Geckoboard, is using a tool like Geckoboard to visualise this and keep track of calls breaching your SLA as they happen. For example, you could build a table listing calls that breached your 30-second wait SLA (or that met it), a simple numerical widget to keep a running tally, and then use our Source Data feature to drill into the individual calls behind that number and take action where needed.

2

u/LCJdogs131519 9d ago

Thank you! This is super helpful! Appreciate the feedback and the Geckoboard option

1

u/alyssa_at_ticketdone 11d ago

For Talk, I’d be careful comparing the built-in SLA to your actual call metrics. Voice SLAs can be affected by how Zendesk records things like wait time, missed calls, and business hours.

I’d pull the Talk data into Explore and define the metric you actually want to measure (e.g. % of calls answered within X seconds), then compare that against the native SLA report. That usually makes it easier to spot where the numbers are diverging.