cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4730
Views
36
Helpful
17
Replies

UCCX - Post Call Survey - how to restrict during Call Consult

Hi,

 

We have used PostCallTreatment Scalar variable to hold the Post Call Survey application trigger number. While agent disconnects the call via Finesse, then the Post Call Survey application gets triggered using the value stored in PostCallTreatment variable. This approach is working fine.

 

However, if agent A does consult transfer/conference with another agent B for an query along with caller and after discussion, if agent B disconnects the call via Finesse, then Post Call Survey application gets invoked and prompts gets played to both caller and Agent A, which is wrong.

 

Is there anyway to restrict? Please suggest.

 

Regards,

Priya

17 Replies 17

Anthony Holloway
Cisco Employee
Cisco Employee

I have experienced this exact problem before too.  I would also like to know how others have solved this.

Hello guys,

 

Do you have any update on that?

 

I have a similar problem here using CCX 11.6.2.10000-38 with ciscouccx.1162.ES04.24.cop.

 

CallerA places a call to the queue and is answered by AgentA

AgentA makes a consult call to Extension 1000 (not a CCX Agent, just a regular extension)

Agent A ends the Consult Call via Finesse

Extension 1000 is directed to the Post Call Survey

Agent A retrieves the call from CallerA, which was on Hold, and ends it via Finesse

CallerA is NOT redirected to Post Call Survey

 

I guess this is a bug. If you don't have any update, I will raise a TAC case tomorrow.

 

Thanks,

 

Bruno 

Hello guys,

 

I have resolved my situation in the following way (I hope that applies to you as well):

 

In the Main Script:

- Set a variable callID = Get Contact Info (Implementation ID)

- Send the variable callID in the Set Enterprise Info step to the Post Call Treatment

 

In the Post Call Script:

- Receive callID from the Main Script

- Set a new variable callIDPostCall = Get Contact Info (Implementation ID)

- if callID != callIDPostCall then Go To TERMINATE

 

The idea of this implementation is that a consult call generates a new call ID in the CDRs. So, if the call that triggered the Post Call Survey has the same ID of the call arrived in the main script, it means it is the same call leg, so we can play the post call survey.

Otherwise, if the call ID received from the main script is different from the call ID in the moment the Post Call Survey was invoked, it means a different call leg (a consult call) triggered that script. In this case, we terminate the Post Call Script.

 

As per my initial tests in my lab, it worked like a charm. I will try in the production environment tomorrow and will let you know if I find any issues in this implementation.

 

HTH.

 

Bruno Nonogaki

 

Your solution reads like you're transferring the caller from one script to another. Is this what you are doing? Or are you landing the original leg on the Agent, and then the Agent is pressing the End Call button in Finesse, which triggers the transfer to the post call application Trigger number?

The agent is pressing the End Call button in Finesse, which transfers the user to a post call script. 

I implemented the solution in the production environment, and everything is working fine.

Can you elaborate on how you are doing these two:

- Enterprise Info step to the Post Call Treatment

- Receive callID from the Main Script

Yes, sure!

So I am assuming you already have the PostCallTreatment configured, and properly redirecting to a Trigger when the agent ends the call via Finesse. 

 

In the main script:

1. Create a String variable called callID

2. In the begining of the script, create a Get Contact Info step, and set the parameter Implementation ID to be callID

3. In the Set Enterprise Call Info step where you add the Post Call Treatment, add the callID as PeripheralVariable9 (for example) in the General tab - here you might be already passing other parameters to the Post Call Application, such as callingNumber, CSQ ID, Agent Name, etc. It depends on how you configured your post call treatment.

 

In the Post Application Script:

1. Create a String variable called callID

2. Create a String variable called callIDPostCall

3. Add a Get Enterprise Call Info step, adding the PeripheralVariable9 to the variable callID - here you might be already receiving other parameters from the main script, depending on how you configured your application. As this is mainly done for post call surveys, I usually send the CSQ Name, Agent ID, CallingNumber. So I just added one more parameter to be sent from the main application to the post call application

4. Create a Get Contact Info step, and set the parameter Implementation ID to be callIDPostCall

5. Create a IF step "if (callID != callIDPostCall)" - if true, Goto Terminate

 

And done! :)

 

Thanks,

 

Bruno

Wow! That's very clever if that works. Thanks for explaining it.

Ok, so two things:

1) You're not actually changing the behavior of Finesse, rather you're just dropping the call as quickly as you can. That's good, but affecting Finesse's behavior would be the ultimate goal here. Maybe Cisco can fix that.

2) Since you're pulling all of.those other variables in addition to the callID, couldn't you just check if say for example the CSQ name was empty, then drop the call? Since real calls from main would set this, and accidental transfer wouldn't? This way you don't have to use extra steps and pass one more value?

Still a very cool solution though. Nice work!

Hello Anthony,

 

I guess even if you make a consult call, and end that call, the CSQ Name arrives filled to the Post Call Script. If it comes blank, that would also work. As per my testing, the only thing I found to be different from the main call and a consult call is the Implementation ID, which is right, because a consult call generates a new Call ID in CUCM CDRs.

 

But if you find another value that can distinguish the calls, you could definitely use that too.

 

Thanks!

 

Bruno

Sweet! I really like the simplicity of your solution.

Hi,

 

Finally we developed an agent gadget and implemented in Finesse layout to address the issue.

 

Whenever agents receives the call in Finesse, based on the Type of the call the call variables are populated.

 

For example,

  • when call gets transferred from IVR to Agent A, then the type will be ACD_IN in Agent A finesse, during this the call variables are populated for this Agent.
  • When Agent A tries to Consult Agent B, then the type will be CONSULT in Agent B Finesse. During this, the PostCallTreatment variable is not populated (emptied) for this Agent. When Agent B ends the call in Finesse, then PCS application will not be triggered  by default, because PostCallTreatment variable is empty.

The gadget worked charm and customer tested and certified.

 

Thanks all for your support.

Regards,

Priya K.R.

can you shared this gadget, please

can you share the sample script

I tried the steps unfortunately once agents press the end button ,calling and called calls are disconnecting it is not going to the survey.