Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
MiCC Call Backs
- Thread starter AlphaMann
- Start date
I thought that was the entire purpose of Callbacks
For callbacks to work properly you need dedicated IVR ports per Callback to maintain the position in queue
**********************************************
What's most important is that you realise ... There is no spoon.
For callbacks to work properly you need dedicated IVR ports per Callback to maintain the position in queue
**********************************************
What's most important is that you realise ... There is no spoon.
@kwbMitel,
Have you done this?
When I've asked Mitel about the way a call back works it prompts the user to enter a preferred day/time for the call back.
Then there is a specific call back queue that has these callbacks which calls the agent when the preferred time is reached.
The callback port does not actually stay in queue and progress like other calls from what I've been told.
I would like to know if this is possible as well as I have a customer that would like this feature.
This is assuming MiCC Business (praifiefyre), not MiCC Enterprise (Solidus)
Have you done this?
When I've asked Mitel about the way a call back works it prompts the user to enter a preferred day/time for the call back.
Then there is a specific call back queue that has these callbacks which calls the agent when the preferred time is reached.
The callback port does not actually stay in queue and progress like other calls from what I've been told.
I would like to know if this is possible as well as I have a customer that would like this feature.
This is assuming MiCC Business (praifiefyre), not MiCC Enterprise (Solidus)
- Thread starter
- #4
- Thread starter
- #6
Kind of the direction I was thinking of. 1 of 2 options -
- get the upique place, determine the average call handle time, calculate the time the call should happen. Then give the call back that preferred time. Give the call back queue higher priority.
-second one is fancier and I would have to play but get position in queue, get the global call id of the call before it. Use a upique port to continue to monitor the call ahead, when call is upique 1 fire the call back routine.
I think the first option is safer and will more or less be around the right spot.
- get the upique place, determine the average call handle time, calculate the time the call should happen. Then give the call back that preferred time. Give the call back queue higher priority.
-second one is fancier and I would have to play but get position in queue, get the global call id of the call before it. Use a upique port to continue to monitor the call ahead, when call is upique 1 fire the call back routine.
I think the first option is safer and will more or less be around the right spot.
I had the engineering course, I have not implemented Callbacks.
There may be more than one type I suppose. I don't remember anything about entering a time for a callback. I do remember what I already stated. An IVR port is required per caller and maintains position in queue. When the port is answered the callback is initiated.
**********************************************
What's most important is that you realise ... There is no spoon.
There may be more than one type I suppose. I don't remember anything about entering a time for a callback. I do remember what I already stated. An IVR port is required per caller and maintains position in queue. When the port is answered the callback is initiated.
**********************************************
What's most important is that you realise ... There is no spoon.
There is 2 ways for callbacks to work neither maintains their original position in queue.
1. Ask the customer to enter a date and time for the callback pretty convoluted in giving those instructions to the caller. At that time the system will call into queue and when it reaches a live agent (and the agent accepts the callback) it will place the call to the customer and conference them together.
2. Choice #2 Once the caller leaves their info an outbound port will call into queue and do the waiting for you. Unless you do a second queue with a higher priority then the original the caller is at the back of the line. There are timers as to how long a call will wait in queue before cycling out for another caller(to keep ports from being stuck with certain calls)
Craig
1. Ask the customer to enter a date and time for the callback pretty convoluted in giving those instructions to the caller. At that time the system will call into queue and when it reaches a live agent (and the agent accepts the callback) it will place the call to the customer and conference them together.
2. Choice #2 Once the caller leaves their info an outbound port will call into queue and do the waiting for you. Unless you do a second queue with a higher priority then the original the caller is at the back of the line. There are timers as to how long a call will wait in queue before cycling out for another caller(to keep ports from being stuck with certain calls)
Craig
- Thread starter
- #9
caknfd you are correct out of the box there are the only 2 options. That is where we get creative.
The default out of the box call back template is missing so much information and some simple functions that you think would be built in like "how many callbacks are there?" are not there.
The default out of the box call back template is missing so much information and some simple functions that you think would be built in like "how many callbacks are there?" are not there.
- Status
Similar threads
- Solved