It is a well known fact that when you open a support ticket it enters into the ticket queue and a client update to a ticket pushes it back to the end of the queue and an admin response takes it out of the queue altogether until there is another client response.
I believe however that should definitely be looked at. The ticket opening, or the first client response after the last admin response should be used to calculate the ticket position, this way tickets will get seen in their correct turn even when they have a subsequent client update. It is a better practice to make sure a queue flows properly. No subsequent client update should affect the queue position no matter how many times they update the ticket before support respond to a ticket.
Another matter that might come up is the email responses the client/support receive, Only one per rotation should occur to prevent email flooding.
IE: Client response, Support response and again no matter how many times an update is made, only the first update has any affect.
It might also be useful to have a position counter displayed on the ticket so that as the ticket progresses it can be seen by the client, it might make them less frustrated when it comes to waiting on a response from support.You could also use the ticket position to decide whether an admin should respond immediately, So lets say when a ticket reaches position 2 or 3 if the ticket is being updated (user is typing) the staff are notified and can hold off responding while the update comes through. the same could be done client side so a user knows when the staff are responding.Obviously this requires some ajax to live update but its got to be better than the way its working now and i have no doubt it will restore some faith in the support systems.
Featured Comment
Relevant documentation: http://docs.whmcs.com/Support_Tab#Update_Last_Reply_Timestamp