UCCX 10.6 Priority lost in callback queue

[jferraz22]

We have two inbound numbers/triggers, support and VIP.  I've adjusted the script so incoming calls to the VIP number have a priority of 10 set so they're always answered first when any assigned CSQ agent becomes available.  This works as expected.

We also have a callback queue, accessible from either support or VIPs CSQs after a variable amount of time.   VIP calls that opt for the callback option are losing their priority.   I thought priority belonged to the call, not the CSQ, so it would follow the call/session, but it doesn't.

So a 'live' VIP callback holding for 7 minutes will be answered before a 5 minute holding support call, but a VIP callback queue call 'holding' for 7 minutes will be answered after a shorter support call.

The VIP and Callback queues are two different triggers/applications, so I'm wondering if I need to retrieve the previous priority when the caller is passed to the new trigger?  I couldn't find a session or caller value holding the value in the UCCX Editor if so.  Or, can I look at the assigned CSQ name and reset the priority again?

Would it be as straightforward as

If (CSQ = "csq_name")

 True

 ... set priority

False

... do nothing

?

Thank you!

[Aaron Harrison]

Hi

The priority, the CSQ variable, and all other elements of a call are part of the 'call context'. They are local to each call, so are not shared between calls.

That extends to separate calls from the same caller.

So if the original call, and the 'callback' call (by which I assume you mean a call that is made from the script dealing with the original call to a new instance of a script that ghost queues to an agent and then calls the caller back) are seen as two separate calls then they will not keep any info - that includes the CSQ var from the original script.

One way to deal with this would be to have two callback scripts, and send calls from VIPs to the CB script that sets Pri=10, leaving the normal support one at default.

Another way would be to signal between the original script and the CB script the priority by pushing accross some DTMF. 

If your callback implementation is not what I've imagined there may be more ways...

Aaron

[jferraz22]

Hi Aaron, thanks for the reply.

Once the caller selects the callback option, they are handed off to a call subflow script which collects their name and callback number, and are then placed into another script/trigger that holds their place in line until presented to an agent, then the agent is notified it's a callback and the outbound call is placed.   The callback request keeps the original place in line and CSQ as the initial 'live person', and when it's presented to the agent the CSQ is displayed in Finesse, so that's why I'm not clear on either why the priority is getting lost, or how to retrieve the original priority like it's gotten the original CSQ.  Since the CSQ is preserved, I should be able to do the same with the priority?

Is it in/could I get it from the Get Session Info?

I've attached the callback queue script.

Thank you

Jen

[Aaron Harrison · Accepted solution]

OK... so misconception #1 : Maintaining position in queue. This does not happen. In your callback script, you have a Select Resource step:

Select Resource (--Triggering Contact-- from csqID)

At that point, a new contact is queued in whichever CSQ is in csqID. The calling script probably dequeues the call from the same CSQ. They're two calls... so the callback starts at the rear. If it skips anyone it's due to priority.

These steps:

Get Contact Info (--Triggering Contact--)

previousSessionID = Get Session (mappingID)

Probably retrieve the CSQ from the session object, and that's how it 'remembers'. If that is the case you can probably do the same with priority (i.e. set it in the session on the 'main' script, and read it from the session in the 'callback' script).

Aaron

[jferraz22]

Thanks Aaron, I'll see if I can figure out how to do that :-)

The person who wrote the original scripts told us differently about how the position is handled in the queue when the callback is selected, but of course I see now that you are correct.

Jen