Collect the CDN into a call variable

[monkeybarfan]

How can I do it?

I can store digitcollects in a variable and use them but I'm stumped with this CDN one.

 

[Techfalcon]

Hi

If i am correct you want to put the CDN value into Call variable well you can do the follow

CDN = 1234 Call Variable = gv_cdn_capture


ASSIGN 1234 TO gv_cdn_capture

If you are collecting the digits from the customer you can do the following


OPEN VOICE SESSION gv_access
PLAY PROMPT VOICE SEGMENT vs_intranet
COLLECT 1 DIGITS INTO cv_cdn_capture
INTER DIGIT TIMER 4
END VOICE SESSION

WHERE collection EQUALS
VALUE 1234: EXECUTE another_script
DEFAULT: EXECUTE Continue
END WHERE


I hope that this helps if not let me know

SCCSMAN

 

[Techfalcon]

sorry the above scripting was incorrect

the variable needs top be cv_cdn_capture not gv_cdn_capture


OPEN VOICE SESSION gv_access
PLAY PROMPT VOICE SEGMENT vs_intranet
COLLECT 1 DIGITS INTO cv_cdn_capture
INTER DIGIT TIMER 2
END VOICE SESSION

WHERE cv_sdn_capture EQUALS

VALUE 1: EXECUTE Mail
DEFAULT: EXECUTE Continue

END WHERE

 

[monkeybarfan]

But that means the CDN will always be 1234?

What I want to do is, have the call variable store whichever CDN the Master Script has passed it (based on the DDI dialled by the customer).

This is because we have a CDN that low skill agents can dial to perform warm transfer to higher skill agents. The problem we are having is when they do this and the call gets networked out and the higher skill agent subsequently becomes busy. If there are no further higher level agents available at that site, then because the call cannot travel back down across the network to another site, it has to revert to the default skillset, which can be answered by low level agents, rendering the warm transfer process useless.

 

[Techfalcon]

ok

I have never tryed this but you could use the following at the start of the primary script as this will pass the cdn info into the call variable

ASSIGN CDN TO cv_cdn_capture

let me know if this work

sccsman

 

[TexasCraig]

CDN is an Intrinsic so you can either use it like I do in a where select

WHERE CDN EQUALS
	/* Customer Service inbound calls */
	VALUE 3672,6549 : EXECUTE SCRIPT New_Equipment_script
	VALUE 3673 : EXECUTE SCRIPT Service_Parts_script

	/* Help Desk inbound calls */
	VALUE Tier1_CDN_List_gv         : EXECUTE Handle_Tier1_Call
	VALUE Tier2_Inbound_CDN_List_gv : EXECUTE SCRIPT Tier2_Preprocess_Call_script
	VALUE Tier2_Xfer_CDN_List_gv    : EXECUTE Handle_Tier2_Call
	VALUE 8100                      : EXECUTE SCRIPT HelpDesk_Dispatcher_script
	VALUE 8101                      : EXECUTE SCRIPT HelpDesk_OneShot_script
	VALUE 3678				  : EXECUTE Handle_XOM_Call
	VALUE 4015                      : EXECUTE Handle_Status_Call
	VALUE 4455				  : EXECUTE SCRIPT HelpDesk_3VPIN_script
	VALUE 6548				  : EXECUTE Handle_SamsClub_Call

or you could store it as sccsman noted previously. Hope this is helpful for you.

Craig

 

[monkeybarfan]

We already use a where clause in the master script.

I want to collect the CDN to use later, when calls that travel across the network are defaulting to a basic skillset. Because once a call has gone out over the network, it cannot come back to the main site, once an agent subsequently becomes busy, we want it to re-enter the master script at the previously dialled CDN.

Sccsman, I will try that command and report back here.

 

[Milesprower]

After re-reading this thread again, the network mention sticks out. You need to be clear - as I understand it you want to use the original CDN from the initial site at a remote network site.

Once the destination agent is found and the call is routed from the initial SCCS site to the remote destination SCCS site, it enters the remote destination SCCS site via the network CDN. This is the only CDN that the remote site sees.

If the reserved agent at the destination SCCS is not avaialbe when the call arrives, the Network script catches the call. The Network script is limited in the information it has and the commands that can be used.

There are some tricks you can use to try and "pass" originating site data to the remote site. They are not elegant, but may be useful.

I believe the originating DNIS can be passed untouched. So, if you use DNIS and it provides unique information that would be useful at the remote site, this is an easy way to do it.

Other ways involve indirect indicators. I have successfully used a unique network skillset name - but this can quickly get to be more trouble than it is worth. As a Non - Local Node Inclusion (LNI) example, name the local skillset green_sk. Instead of using the same name for the network skillset create a different skillset name, say blue_sk.

Your local script will be

IF NOT OUT OF SERVICE green_sk, THEN
QUEUE TO SKILLSET green_sk
WAIT 2
END IF

QUEUE TO NETWORK SKILLSET blue_sk
WAIT 2

At the far end system, you now know that calls queuing to skillset blue_sk came came by way of the originating site.
The overhead on setting up agents in multiple skillsets just to pass the skillset name as an indicator can quickly become onerous.