UCCE - passing AgentPeripheralID from CAD for an Outbound call

[paulafdx]

Is there a way to pass the Agent Peripheral ID (Agent ID) from an agent logged into CAD, making an outbound call without using a Dialer?`

[Shalid Kurunnan Chalil]

What's the purpose ?

If it any kind of post call survey, then definitely yes.

I think it may possible if you use DNP and followed by a script to send
call to dynamic label. I haven't checked this yet but worth trying.

[paulafdx]

Yes, actually it is for a PCS situation. Here is the call flow:



Agent calls customer X at number (901)XXX-XXXX

Connects to customer

Asks customer if they would be willing to take survey after the call

Customer agrees

Agent dials TFN 800.123.4568

(not sure if they would conference then drop the line when the system answers OR blind transfer via CAD)



Since the Agent peripheral and the skill target ID are in CAD, on the outbound leg of the call this data is captured in TCD.



What were are trying to do is pass the above info with the PCS leg of the call (via the TFN), so this data is captured and we can tie the survey back to the agent.



Does this make sense?



So given, "I think it may possible if you use DNP and followed by a script to send
call to dynamic label. I haven't checked this yet but worth trying."



So if you see the two attached WORD. docx, the one entitled "To Cisco Community", which includes some of our initial testing and the steps we took

The other document entitled "CVP" I pulled off the Cisco community. It is back from a few years ago, so our UCCE, ICM, etc...is a more upgraded version than is relayed in the initial request.

[geoff]

I had a customer a couple of years back request that the agent who handled the call be available in the Post Call Survey. This was on 10.5. I could not see how to do this with a native method, and I worked around it with a somewhat convoluted technique. I created a Finesse workflow to write the agent ID and RouterCallKey to an out of band database table. The PCS script did a DB Lookup on the RCK to retrieve the agent ID. As you know, the RCK of the PCS call is the same as the original call.

You could do something similar with CAD - although you should be thinking of upgrading to Finesse.

The table was truncated each night at midnight (because the RCK usage is reset at midnight and ICM DB Lookup can only use a table with a single primary key).

This worked well and is still working.

If there is a native method, I would like to know it. My impression was that the PCS is meant to be anonymous with respect to the agent handling the call.

Regards,

Geoff

[paulafdx]

Tried to send this once prior. Not sure it if was actually delivered or not. So resending)

We can do this if the initial call was an inbound call. But with an outbound call from CAD (Agent Desktop), we are not going thru an ICM script.

Agent calls customer
Customer agrees to survey
Agent "transfers" customer to TFN which is pointed to a PCS script.

We want to capture the Agent ID in CAD or Finesse, and associate it with the PCS call leg.

We are holding the agents accountable for their own survey results. So we have to be able to make the distinction between surveys on these outbound calls.

So getting the Agent Peripheral ID associated with the "transfer" call is what we are looking for to do.

Paula

[geoff · Accepted solution]

Paula,

One trivial (but possibly unwieldy) way would be to give each outbound agent their own DNP to do the transfer to. If you used the agent ID as a guide and prefixed a digit to make that agent's route point it would be easy for the agent to remember.  For example: agent Fred Nurk with agent ID 7001234 does the transfer to DNP "92001234". In the PCS script that is attached to this DNP (as the Dialed Number) you simply strip off the leading "9" and save the result in a PV (so this is the agent's ID). You are using DNPs and not real UCM Route Points so only an agent can use it (from CAD or Finesse). You would have hundreds of dialed numbers mapped to the same entry Call Type to trigger the scheduled PCS script. This just depends on the number of outbounders you have who do this. If under a couple of hundred it would work.

Another possibility is if there is a unique ANI for each agent. This would be likely under Mobile Agent conditions (the RCP) or under Extension Mobility conditions. You could do a database dip in the ICM script, passing the CLID and getting back the agent which again you save in a PV. This will not work if there is Hot Desking but if agents always use the same extension you could build a table.

You should get away from using a TFN anyway - no point in the agent doing a transfer out to the PSTN and back in.

Regards,
Geoff

[paulafdx]

This helped very much. TY. We worked it out this way, and it works for us at this time. :)



We only have one other issue. We did get the data passed and we can identify the originating agent.



However, once we get the call routed to the PCS script in CVP, we did add the "input" node with the DTMF reference, but the system is still NOT accepting the CED from the customer.



We are not sure why, other than the fact that these calls are coming in to our IPCC(UCCE) platform differently, that the DTMF is not being accepted.

But, these calls are being routed to the exact same script, and flowing down the same path that our US English callers are receiving.



IF there are any questions, concerns or suggestions, please let us know.



paulafdx

[david.macias]

If you get the agents to transfer them to an internal extension, then you can pick up their extension. That should uniquely identify them by device. If your agents move around, you would be able to easily figure out with agent is logged to what extension at any point in your life as long as they take a single ICM call.

david