Resolve incorrect 'resolve till date'
complete
Nilesh Vagadia
At the moment, the resolve till countdown resets when a customer sends a new message, whereas should be the same, and should use the earliest unresolved message time. This means that the customers that message at a later time (even though they had messaged earlier), their tickets will be dealt with later.
Here are example scenarios.
.
Ticket 1:
Last unresolved messages:
15:15, 19:15
.
Ticket 2:
Last unresolved messages:
13:20
.
Ticket 3:
Last unresolved messages:
15:30, 15:45, 19:45
.
Ticket 4:
Last unresolved messages:
16:25
.
Ticket 5:
Last unresolved messages:
11:20, 20:00
.
.
At the moment, the order will be using the LATEST message time:
2 - 13:20 (latest message time) - [Earliest unresolved message was at 13:20]
4 - 16:25 (latest message time) - [Earliest unresolved message was at 16:25]
1 - 19:15 (latest message time) - [Earliest unresolved message was at 15:15]
3 - 19:45 (latest message time) - [Earliest unresolved message was at 15:30]
5 - 20:00 (latest message time) - [Earliest unresolved message was at 11:20]
.
.
What it should be:
5 - 11:20 (earliest message time)
2 - 13:20 (earliest message time)
1 - 15:15 (earliest message time)
3 - 15:30 (earliest message time)
4 - 16:25 (earliest message time)
H
Herman Nefedov
complete
This is currently rectified. The Respond Till column is now being counted from the last unanswered incoming message.
Recently we introduced our new SLA system which allows you to have different SLAs for responding to buyer's messages and for resolving the ticket itself.
For example, you declare that you always reply within 24 hours, and all the tickets are being closed within 96 hours maximum. Now you are able to adjust these SLAs and monitor the Respond Till & Resolve Till columns. You are also able to sort these columns as you wish.
Moreover, you may choose what hours to count - calendar hours or the working hours only.