Tip: calculating Next Reply Time (non-messaging/chat channels)

3 コメント

  • Jennifer Rowe
    Zendesk Documentation Team

    Excellent, Pedro Rodrigues! Thanks for sharing this.

  • Erin Willis

    Hey Pedro Rodrigues 

    I'm trying to create NRT Brackets using the SLA dataset. I'm wondering how accurate it might be if the NRT policy is applied to the same ticket more than once. If the first reopen the NRT is 6 hours but on the second reply its 12, how would this be accounted for? Any suggestions? 

    IF (VALUE(SLA metric completion time (min))<360) THEN "0-6 hours" ELSE
    IF (VALUE(SLA metric completion time (min))<480) THEN "6-8 hours" ELSE
    IF (VALUE(SLA metric completion time (min))<900) THEN "8-15 hours" ELSE "Over 15 hours"
  • Pedro Rodrigues
    Community Moderator

    Hi Erin Willis, it would depend on how you choose to build and visualize your report, but in this case there would be two instances of the metric being counted: one for the first "0-6" bracket, another one for the third "8-15" bracket.

    Here's your standard attribute applied to a real example. The following SLA ticket had multiple reopens and agent replies, therefore we can expect several instances of the metric:

    We can see that there are sixteen first bracket completions VS one third bracket completion. Three of these completions have really long durations which will certainly impact the average. 

    So if we try to build a report showing only these brackets, we will see one average calculated for each bracket:

    As you can see, the first bracket shows only the average completion time for all the metric instances where the NRT for that agent reply matched 0-6 hours. If not for those three specific longer replies, this average would be under 10 minutes.

    Let's modify your metric for a second look at this:

    The result:

    As you can see, because there is one instance of the NRT metric that is 260 minutes, there is now a new bracket being shown for that completion.

    To conclude, this kind of reporting can be a bit "foggy" in terms of a more granular analysis, especially if you have many reopens per ticket and agent replies with very different completions.


    If we're monitoring these brackets, then I'd say it's always a good idea to build additional reporting to try and identify the specific events just to make sure no outlier situation is left unattended.

    For example, let's try to track the global individual instances of a metric without having to filter per ticket ID.

    We can use the SLA policy unique ID (a string combo of ticket ID + SLA policy ID) and join it with the SLA event ID. We'll obtain a unique string for "SLA event unique ID"):

    We can now check all our tickets, filter for the NRT metric and obtain a list of the "worst offenders" in terms of events:

    That first row shows a ticket with a reply time of 19 days. Imagine that ticket has another reply whose NRT is 30 minutes... the ticket ID's average NRT would be 9.2k minutes (6 days), which is a lot different from reality... but if we have this table with the unique event IDs for NRT, we can identify the specific event an NRT reached unexpected values.

    So just as food for thought, of course, you can build your brackets chart that would consider all the events to calculate the average completions, and complement it with this kind of table where you'd see the "Top N offending events", for example.

    Hope this helps!



Powered by Zendesk