The basic idea is that you separate the selection of the resource from the connection to the resource, which are both normally done in the same step, by default.
To achieve what you want, it takes two additional variables, and two additional steps, and the modification of one existing step.
Variables
Prompt youre_being_connected = P[youre_being_connected.wav]
User selected_resource = null
Script
...
/* Here you will need to set the Connect property to "No" and the Resource Selected property to "selected_resource" */
Select Resource (--Triggering Contact-- from "CustomerServiceCSQ")
Selected
Play Prompt (--Triggering Contact--, youre_being_connected)
Connect (--Triggering Contact-- to selected_resource)
Connected
End
Failed
...
Queued
...
Hope that helps.
EDIT: I need to add more to this, because there are somethings to note with the behavior of such a solution.
Something I was taught growing up in UCCX was to fake a ringback tone to the caller during the transfer to the Agent. You do this by changing the Network Music On Hold source on your CTI Port Group to that of one on CUCM which contains a wav file of ringback sounds.
The thing to watch out for, in either the original request, or this fake ringback one, is Ring No Answer. If the caller is immediately directed to an Agent then this is the experience, assuming you have the default sample MOH and a queue message:
- Caller hits the Select Resource Step and an Agent is selected
- Caller hits the Play Prompt Step and hears "Your call is being connected.."
- Caller hits the Connect Step and hears Network MOH while the Agent phone rings
- Agent Ring No Answers
- Caller hits the Select Resource Step and a different Agent is selected
- Caller hits the Play Prompt Step and hears "Your call is being connected.."
- Caller hits the Connect Step and hears Network MOH while the Agent phone rings
- Agent Ring No Answers
- There's no more Ready Agents in the CSQ, so the Queued branch is hit
- Caller hits the first queue message and hears "All of our Agents are current busy..."
Now the caller knows that the system tried two Agents, who didn;t help them, and is now stuck in queue. I would not like that, personally. I would think, "Jeez what just happened there? It like tried to connect my two times and failed." I may even hang up because I think it's broken and cannot connect me.
I think a much better experience is if the solution hides the attempted transfers from the caller and was as follows:
- Caller hits the Select Resource Step and an Agent is selected
- There's no Play Prompt to notify the caller of the pending transfer, so they hear nothing for the moment
- Caller hits the Connect Step and hears Network Music On Hold, so they get the impression that they're in queue
- Agent Ring No Answers
- Caller is taken off Network Hold and Music stops (but read on to see what the caller experience is like)
- Caller hits the Select Resource Step and a different Agent is selected
- There's still no Play Prompt to notify the caller of the pending transfer
- Caller hits the Connect Step and hears Network Music On Hold, but since these steps are executing in sub second fashion, the off hold to on hold happens so quickly, there's literally no break in the music. Therefore, they get the impression that they've been in queue the whole time
- Agent Ring No Answers
- There's no more Ready Agents in the CSQ, so the Queued branch is hit
- Caller hits the first queue message and hears "All of our Agents are currently busy..."
Now the caller thinks this is just a loop break, and is none the wiser that two Agents were attempted and failed to connect. Basically, they've just been waiting for the first one. If you make your queue messages (Play Prompt Steps) Uninterruptible, then you also ensure that they are not cutoff mid sentence, thus furthering this masking of the Ring No Answer failure scenarios.
I hope that's helpful, even though it's counter to what you requested.
Anthony Holloway
Please use the star ratings to help drive great content to the top of searches.
