Solved How can I track call back operation?

[greychain]

I'm trying to find out where my call back calls are going which log should I be looking at?

Does it only try once and if it fails it gives up? Can I increase the attempts?

Currently in my testing I have one agent that is logged into the queue but on a call to another extension, their discussing their holidays after Covid, it's a long call. I have another agent in the same queue but they have signed out for a few minutes.

I have an incoming call but as mentioned, my other agent is signed out of the queue, after the set timeout the customer is offered the call back option. The customer chooses the call back option and the system hangs up.

The agent that was logged out of the queue logs in, nothing happens - no call back occurs. Where did the call back go?

Queue is set for Prioritized hunting.

Update: It looks like it gets associated with the extension discussing their holidays. How can it be associated with the queue?

 

[ChrisC_3CX]

Callbacks are only tried once and there is no way of increasing the number of attempts. Regarding your scenario, if the callback was still in the Call Queue at the time the agent logged in, the callback call should have polled that agent, there is no way for it to associate with a specific extension, it is still a call waiting in the Call Queue.

To hopefully try and figure out what happened with the specific call, I'd recommend using a combination of the available reports.

 

[greychain]

Thanks for the prompt reply. How do I view the call Queue? In my testing I expected the call to be placed to any available, logged in and not busy extensions but it seem to have been assigned to the extension that was busy. As soon as that extension became available it started to try the call back.

I did notice that if, during the callback option is being offered to the customer, an agent logs back into the queue it goes straight to his extension. But it doesn't work after the call is queued.

I thought there was an option to determine if the call back would go to a specific extension or just become a call back

 

[ChrisC_3CX]

That is weird, the expected behavior is for the call to poll the next available agent, there is not mechanism that would cause a Queue call to "associate" itself with an extension. If you can reproduce this issue at will, I'd recommend making sure that there is misconfiguration contributing to the issue such as having the extensions explicitly logged out of certain call queues, etc. You could even go as far as creating a test queue and a few test extensions and check if you get the same behavior. If the issue persists, you would have to investigate further by perhaps reviewing the logs to determine what is happening exactly. For this I'd recommend contacting our Support Team.

 

[greychain]

Ok I have sorted it all out now. It was all about timeouts and call forwarding at extension and queue level.

One question regarding callback timeout.
Is this time from when the last extension was tried or from the start off the incoming call time.

Say I had set my timeout to 10 seconds and my agents all had a 5 second timeout, and say there was a fire drill so they all ran off without logging out (as they should do), would the call be in the queue for 50 seconds before the customer got the call back option? Or would it be 10 seconds?

Update: I set up another agent extension and set call back timeout to 2 seconds. The customer got the call back option 2 seconds after entering the queue, not the expected 5+5+2 seconds

 

[ChrisC_3CX]

You are correct, the callback timeout value defines the time from when the caller entered the queue to the time the caller will receive the option to submit a callback request.

 

[greychain]

Thanks @ChrisC_3CX you've been a great help today.

 

[ChrisC_3CX]

My pleasure! Please feel free to start a new thread should you require additional information or assistance!