What is the First Reply Time and Next Reply Time SLAs beta about?

Hi @prakruti - I went to sign up for the EAP but realized that the minimum you can put for it is still 1 minute. For a more real-time channel like messaging, it would be great if we could do the SLA in seconds. Ideally we'd like to do something like 30s.

@lauren41 In this initial release the shortest time is 1 minute, but in Q4 we'll introduce support for specifying it in seconds instead. So yes, you'll be able to set 30s!

@Scott Allison awesome, thank you!

Hello
I have two feedback on what we are seing on the field:

- the SLA on FRT seems not updated if the field of the tickets are not filled. Therefore the first response is not properly captured.
-On the NRT, it will measure each response ; within a live conversation, but it seems that it does not capture the NRT between a ticket that it is becoming active and the answer of the agent. Our aim is to capture this precise moment, but seems not possible to isolate it. Do you have some suggestions?

@bénédicte Thanks for taking part in the EAP, and for your questions.

- the SLA on FRT seems not updated if the field of the tickets are not filled. Therefore the first response is not properly captured.

I'm not sure what you mean, but for the SLA to run you do need to make sure a ticket has a priority assigned. You can do that with a trigger.

On the NRT, it will measure each response ; within a live conversation, but it seems that it does not capture the NRT between a ticket that it is becoming active and the answer of the agent. Our aim is to capture this precise moment, but seems not possible to isolate it. Do you have some suggestions?

Sorry, I don't quite follow your question. Next Reply Time is activated when the end user sends a message, and it is fulfilled when the agent replies. 

Hi Scott

Regarding the FRT: the FRT is not updated when an agent replies to the customer directly. The agent needs to fill the ticket field (channel, contact reason, reference ect..) to have the SLA on FRT updated on the ticket.
Therefore, the FRT with SLA is less accurate than the one I can find the the standard support dataset (that will base the FRT on the first public reply of the agent)

Regarding the NRT on messaging, my concern is that the NRT is measured each time there is a reply from the agent to the client. This means that it will measure all the time between the exchanges within an active conversation (like a live chat). Therefore, I will have difficulties to measure the NRT between an answer provided by a client and the response from the agent when a conversation is cold.
What I would like to measure with the NRT is the time between answer on an inactive messaging ticket.
To be more specific, imagine an agent that reply to a client that is no longer online and the ticket is put on pending (because we are waiting for more info from the client). The client answers after 4 hours and than after X time the agent treat this inactive response.
My aim is to measure this X with the NRT. At the moment, I am using the resquester waiting time, but from operation perspective, the agent has not the possibility to see the proper SLA on it and therefore manage his views accordingly.
Hope it is clearer now 

@bénédicte

Thank you for providing more details. Can you share a screenshot of your setup for First Reply Time?  You can also reply to the email I have sent. 

For the Next Reply Time, you can setup business hours as part of SLA setup. SLAs will be paused during outside of business hours. 

- Prakruti

Hi Prakruti

Here is how I set the SLA

I decided to have them on Calendar hours to test it properly.
For FRT, the results seems not impacted by the calendar hours but by the feedback I provided
For the NRT, I understand what is it showing but it does not help us measure the time between an inactive ticket is replied by a member and the time taken by an agent to take the ticket and reply back. Unfortunately, as the NRT measure the time taken for every reply, it does not properly respond to our needs.