Nathan Cassella

Hi Elaine

I'm not quite sure I understand what you're saying here.

The IVR option directs the caller to a specific group, if that specific group is the triage group then the wait time should actively reflect how long they wait. If the triage group transfers the call to another group, Then by the logic you're saying here if I filter for that group I should see the wait time the caller experiences waiting to speak to that other group.

If there are other options as far as combining various metrics can I get some possible direction into what those metrics would be?

Essentially what I'm taking away from your comment here is that I can't rely on the information from the wait times if I have multiple groups answering the phone and transferring to other groups which really doesn't make sense if you offer a system for filtering.

Could you clarify the weight time metric on the default talk dashboard? Does that metric only look at the wait time to speak to a specific group (if you apply the filter), or does it calculate the entire wait time, say if you were to place a call back into the queue to transfer to another group?

This is my setup. -  I have a service desk that answers all inbound calls. That team performs triage and transfers the call to the appropriate call group, essentially putting the call back into the queue.

If I want to judge the performance of the triage team on how fast they respond to calls (after the IVR) and how long callers are waiting to talk to them (after the IVR), is the queue wait time average showing me this metric correctly?

What's the status on this, this is a feature that's more important than agent workspace

Here's another feature that only half works in Zendesk.

This entire company relies on the community to create the workarounds for simple features that should exist from the initial release.

Is there an update on this?

Getting the requestor to input information into the system before getting to an agent would be a godsend and save my team a whole lot of time.

The last update was in September.

This needs to be fixed.

I have a triage group that assigns tickets to the general queue in a FIFO, which can be overridden by priority.

My agents need to see the SLAs on these tickets, and I need to report on them.

This is a relatively easy change; have the first-time response to measure when an agent added a public comment onto the ticket for the first time, regardless of how it was created.

We've been experiencing the same issue that many users have brought up over the last month. All last year when I was my team was working on cleaning up our Guide; we didn't see a captcha once, now today alone, I've seen it five times in the last 30 minutes.

This is making both our internal and external customers frustrated and throwing a wrench into my push to have our customers use self-service.

When can we expect a resolution to this, or is this something else that's going to remain unresolved for years?

Is there any movement on increasing attachment size?

Our customers in specific segments need process documentation specific to them, and like @... those documents can get rather large.

It would be great if this storage could be increased to 1gb at a minimum

I'm a little confused by this. It seems you are tailoring this routing for specific tags related to specific customers, which isn't practical for many other customers.

What I need to understand is how to use this in a proper round-robin fashion.

If I set a trigger with my tag (let's call it "new ticket"), that trigger will only assign to one group; what about when that group meets its capacity? what about when I have agents in other groups available to take open tickets? How does this routing method work if you need to auto-assign between groups?

Barry Neary chat traffic and having messaging enabled are two different things.

Our chosen bot (ADA) requires code to be embedded into our guide header; to avoid conflicts, all other bots need to be disabled. Using this product was a substantial investment, recommended by one of your partner organizations, as Zendesk's chat features (including messaging) are too rudimentary to support our business needs.

I would like you to confirm that omnichannel routing can be used with third-party chat software that Zendesk advertises in their marketplace without needing to have messaging enabled.

If you can not confirm this, please have one of your engineers test it to verify.

If this will not work, your team needs to take this back to development and design a solution that works for all customers instead of requiring them to use a product/features (like messaging) that doesn't meet their business needs.