i have seen this many times. it is not usually a QM problem. i have found a number of different reasons usually rooted in a combination of member behavior and queue configuration.
For example: ring strategy is "least recent"... but least recent member is not answering and queue not set up with auto logoff...so queue simply keeps trying to route call to the one member who does not answer while others sit there idly. the corollary to this is that if a second call comes in and the queue is set to autofill, the second call will glide right by to an available agent [second lest recent] while the first call is still stuck on the first non answering agent.
another example: a least recent agent who has previously taken a call and performed an attended transfer, effectively locking up their extension so that it shows available to the queue (and QM). However, the phone is actually tied up until the transferred call ends and so when the calls are routed there, they will show in the log as RINGNOANSWER [and have the same result as previous example].
Generally I can find logical explanations for apparent anomalies like that described by simply watching QM, figuring out where the next call should be routed to and then going to see what is going on at that endpoint.
