Measuring programming progress by lines of code is like measuring aircraft building progress by weight.Bill Gates
When reviewing your success rates, or progress towards the goals you are trying to achieve, you should be looking at what you are actually reviewing to ensure it is relevant in the first place… or, in other words, does it really what matters?
My thoughts on this are more or less to the point of looking at how well a customer care person addressed the concern brought to their attention. This is the end result metric to be considered over most any other indicator.
This does not mean volumes should not be taken into consideration only that it is likely more relevant to look at the volume in the context of how it relates specifically to the concern at hand. The more concerns being brought forward for the same problem would point to something upstream that may need to be addressed in general such as a software bug or a process that is inefficient or poorly explained.
Also to be taken into consideration with the above is the length of the conversation. Providing a suggested solution and explaining it clearly in a language the customer can understand and take action with is ideally done with the first response although in some cases more details and context are needed to provide the most correct solution idea. A relevant benchmark for the number of back and forth responses should be set but does not need to be explicitly held to a specific number that cannot be exceeded.
Keeping the conversation on point and to an ideal minimum will ultimately provide the best customer care. Ensuring these two ideals will generally address any other metrics you may want to consider provided when you take those measurements you know exactly what you are looking at and why you need to know them.