<div dir="ltr">I agree with Brian that this is how it works. I also agree with Brian that if you're leveraging the Agent desktop properly, you would technically not even need a prompt, the data on the screen could say "This is a CallBack Call, Please Press 1 on Your Phone Now" or something like that.<div><br></div><div>If you want to get really fancy with it, you can achieve what you're looking for with the use of just one Enterprise Variable and a semi-tight loop. Below I'm delaying 3 seconds between polling intervals. You'll want to balance this with: max executed steps param, call volume, load, performance, user experience, etc. I find that between 3 and 7 is acceptable most of the time.</div><div><br></div><div>Pseudo code below</div><div><br></div><div><b><u>Calling Script</u></b></div><div><font face="monospace">...you already placed the callback call into the queue...</font></div><div><font face="monospace">Wait for Agent:</font></div><div><font face="monospace">agent_answered = Get Enterprise Call Info (callback_contact, agent_answered)</font></div><div><font face="monospace">If (agent_answered == false)</font></div><div><font face="monospace"> True</font></div><div><font face="monospace"> Delay 3 Sec</font></div><div><font face="monospace"> Goto Wait for Agent</font></div><div><font face="monospace"> False</font></div><div><font face="monospace">Menu (callback_contact, P[callback_choices.wav])</font></div><div><font face="monospace"> Option 1 - Listen to CallBack Message</font></div><div><font face="monospace"> Play Prompt (callback_contact, callback_message)</font></div><div><font face="monospace">...the rest of your callback routine here...</font></div><div><br></div><div><b><u>Queuing Script</u></b></div><div><font face="monospace"><span style="font-size:10.5625px">...answer the call and get ready to queue it...</span></font></div><div><font face="monospace"><span style="font-size:10.5625px">Select Resource (--Triggering Contact-- from callback_csq)</span></font></div><div><font face="monospace"><span style="font-size:10.5625px"> Connected</span></font></div><div><font face="monospace"><span style="font-size:10.5625px"> Set Enterprise Call Info (--Triggering Contact--) Variable Used: agent_answered = true</span></font></div><div><font face="monospace"><span style="font-size:10.5625px"> End</span></font></div><div><font face="monospace"><span style="font-size:10.5625px"> Queued</span></font></div><div><font face="monospace"><span style="font-size:10.5625px">...the rest of your queue logic and end of your script...</span></font></div><div><br></div><div>Note that the callback_contact object in the Calling script refers to the Triggering Contact in the queuing script. I don't know how this works under the hood, but it does, and I like it. Otherwise, you'd have to resort to some other mechanism, such as Sessions or Doc repository.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 9, 2017 at 9:58 AM Brian Meade <<a href="mailto:bmeade90@vt.edu">bmeade90@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I haven't seen a way around this before. There's not really a way the first script knows when an agent answers the call that I'm aware of.<div><br></div><div>I've just tried to make the prompts relatively short without much delay but then you can start using a lot of steps.</div><div><br></div><div>One thing you could do is just make sure Finesse is displaying that this is a callback call so the agent knows to handle these differently.</div><div><br></div><div>I've also seen people do callback by adding the call to an outbound dialer but I don't think there's any way to have the agent hear a pre-recorded message from the caller in that scenario.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 10:42 AM, Ray Maslanka <span dir="ltr"><<a href="mailto:ray.maslanka@gmail.com" target="_blank">ray.maslanka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Gentlemen,</div><div><br></div><div>Much like the BaseLineAdvQueueing.aef script in the script repository, I have scripts in production that allow callers the ability to leave a message if they choose and receive a call back. UCCX records the callers message, terminates the call, calls a trigger, waits for an agent to answer and prompts them to press a digit to confirm they want to hear the recorded message. The agent is then free to do what they want with that information.</div><div><br></div><div>It seems what really happens after the message is recorded and the call is made to the trigger to deliver it to an agent is that the script starts playing the prompt "Press a digit to hear a message", regardless of whether an agent has actually answered. That prompt plays and waits a given amount of seconds for the agent's digit input, and then loops, courtesy of the timeout function related to the initial digit timer. If no agents are available, the script will continue to play the prompt and wait for digits while listening to hold music, delay prompts or whatever may be presented while waiting for an agent. There is no real harm done here though.</div><div><br></div><div>The issue is when an agent does answer, depending on when they answer during the looping process, they may hear "Press a digit to hear a message" or "to hear a message" or silence as long as the initial timeout value in the Get Digit String step before "Press a digit to hear a message"<span><span>. In higher volume environments, that timer and the possible related silence after answering may be unacceptable. Three seconds of nothing may be enough to trigger an agent to assume it is an abandoned call and hang up.</span></span></div><div><br></div><div>I am hoping someone has a technique to have UCCX only start playing the "Press a digit to hear a message" when the agent actually answers the call that UCCX made into their queue. If what I am experiencing is expected, confirming that would be great too and I'll try to find an acceptable timer or different recordings, etc. If you believe what I am experiencing is not correct behavior, any suggestions on what is wrong with that sample would be appreciated.</div><div><br></div><div>Running into this on fully patched UCCX 11, CUCM 11 and 8800 series endpoints.</div><div><br></div><div>Thanks in advance for any feedback.</div><span class="m_-7951769058806357857HOEnZb"><font color="#888888"><div><br></div><div>Ray Maslanka</div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>