Zendesk Voice to Record Through Hold

Hi Dan not sure if you can share the name of the 3rd party app you're using to record screen capture? My team is looking for the same thing too

Hi Dan,

Thank you for your suggestion. The ability to record audio while on hold is not a feature in our roadmap, at least for the next 9 months. Perhaps a simpler way to solve your problem would be to use a different 3rd party application to record the screen? 

Regards,

Widson Reis 
Product Manager

@Widson Reis, is there any indication calls are placed on hold. Time markers or hit markers indicating HOLD_START and HOLD_STOP. Something we can use to stop/restart screen capture. API data, report data, anything?

Changing screen capture tech would lead to the same problem. Audio recording is occurring on 1 thread, screen recording on another, independent of each other. If the call starts at 10:00am and the call ends at 10:30am and the call has two 5 minute blocks of hold. Screen Recording would be 30minutes duration, Audio recording would be 20minute duration. The audio and screens would be misaligned. This is easily correctable during playback if we know when hold starts and stops. 

Any info you could provide would be greatly appreciated. Thanks. 

Hi Dan, 

I'm sorry for the delay in getting back to you, I was checking if the Talk API would provide any markers such as you suggested. It turns out that it doesn't. 

When I asked if you could use a different 3rd party app I meant one that could capture both video and audio; I guess this is not an option either?

Thanks,

Widson
Zendesk Product Manager

Hello Dan,

Thanks for opening up this issue that affects and concerns many Zendesk customers.

I'd appreciate if you could give us visibility on what tool can solve this technical limitation of Zendesk.

Hi Domingo. We have no working solution at this time. 

We have a connector that reads ZD API's to capture metadata about tickets, to download audio recordings from ZD and then delete the audio recordings from the ZD ticket to provide PCI Compliance. 

We have a separate tool that records screen video on the agents desktop. These videos are sent to our cloud and sit next to the ZD audio recordings we downloaded in the step above from ZD API. We then have business logic to sync, align and merge the audio and video together into a single MP4 audio+video usable multi media event.

The problem we are having is 10 minutes of realtime agent activity produces 10 minutes of video but only [X] minutes of audio because the audio recording does not contain the hold periods. If you combine a 10min video with a 6min audio file the screens dont match the audio.

We have had similar issues with other ACD audio recording engines and we solved for it by either enabling record thru hold if the feature exists, or by reading metadata from the ACD about the hold periods and inserting silence back into the audio recording to remake the audio length to match real time. Now, audio and video aligns again.

The problem we are having with ZDVoice is that they do not record through hold, do not offer an option to do so, and do not offer an API that contains metadata about the holds.

Our hands are tied.

Hi Dan, thanks for explanation so detalled. Yestderday, after reading severals articles about this issue, we came to the same conclusion.

We also have a connector that reads ZD API's too, so we'll think about doing it in a similar way, through a tool  that records screen video. Fortunately we only need to record voice in a small part of our customer service.

All the best, and thanks again.

+1 on this. 

We also need to know how much time our customers are spending in hold during calls for each ticket.

This will definitely help to improve customer experience.

Hi @atanas 

The information of how much time users are on hold is available on Explore. Additionally, we are planning to implement a new feature where we display on the call console the duration of time the end users have been on hold before being transferred, which is also a common request.

Hi @widson . Please re-read the above thread. The metadata related to hold periods must be a START and STOP marker for each hold period. This has nothing to do with TOTAL HOLD TIME and more to do with WHEN holds START and STOP. We need to insert silence back into the audio file that does not contain RECORD THROUGH HOLD to regain real time audio. If we need TOTAL HOLD TIME we can easily compute this from all the STARTS and STOPS. The metadata should be available via a new API endpoint or via a new data collection on an existing API (probably ticket data). I would hope after 4 years of waiting for a feature you have thought through the feature thoroughly to accommodate all that have commented above. 

Hi @Joe Agent (former Dan McGrail),

I understand the nature of the issue and the request. My response was directed to another user who had a different question about hold times.