Temporary IVR Handoff for authentication

[Sethuramalingam Balasubramanian]

Hello,

One of our APAC region banking customers has the following scenario:

1. Agent is speaking to customer

2. Agent identifies customer (and thus updates ECC variables with customer ID)

3. Agent conferences call to CVP

4. CVP sees customer ID - prompts customer to enter their TPIN

5. Customer enters TPIN (which in this case the IVR would need to mask by playing random DTMF tones over the top and the tones entered by caller and the random tones shouldn't be different)

6. CVP validates TPIN through proper back end host verification

7. CVP updates ECC variables (Validated) to say the customer is now authenticated

8. Agent drops the CVP conference leg of the call and continues the conversation with the customer.

There are two possible resolutions here:-

1. The agent transfers the call to the IVR, which interacts with the customer to collect the TPIN digits, validates them and then passes the call back to the same agent.

2. The Agent conferences the call to the IVR and whilst the customer enters their TPIN the Agent does not here the entered tones and the call recording system does not record them.

Option 1. The main issue is returning the call to the original agent (apparently can this be done?).

Option 2. The main issue is the IVR can update the ECC variables to show the validation status, however there is no call update event which is generated in CTIOS to retrieve the updated ECC variables as it comes through a different peripheral [CVP] (apparently this can't be done).

Tone Masking (used in Option 2) is not seen as ideal as the random DTMF tones generated by CVP IVR and the caller tones (generated from the handset) used.

When the call is getting conferenced from the Agent desktop to the CVP application, the call data set in the CVP IVR application is not notified to the agent (through the CALL_DATA_UPDATE event) which normally happens if the call is getting conferenced with another agent. Also the call data set is not getting reflected in the agent desktop even when using GetCallData from the agent desktop manually because the call data set in the CVP application is lost, when the call is disconnected in the IVR application post the TPIN validation

Could you please give advice as to how we can move forward to a resolution?

Thanks!

-Sethu

[david.macias]

1. Returning the call back to the same agent could prove difficult specially if you have a lot of calls waiting in queue.  This might prove to be the harder solution.

2. Since the agent, customer, and IVR are in a conference, how about playing an audible prompt to both the agent and customer saying "you've been verified", that way you don't have to pass any data back to the agent?

david

[Sherif Fahmy]

Hi all,

    I have this problem too but I can't find a solution to put the agent on hold during the conference with the IVR so the agent can't listen to the DTMF tones of the customers' authentication passwords.

Can you please help how to put the agent on hold or mute the DTMF tones during authentication or even unify the played tone?

[Chintan Gajjar]

There is solution from Paul tindall on temporary IVR hand off, that you can consider for your case.

but also check with Cisco if that is supported because that needs tcl applications to be updated.

I also built the similar thing, but i used different technique:

1. Agent does warm transfer to Authentication script.

2. in Authentication Script i capture the Calling line ID which will be nothing but Agents Extension.

3. hosted database which maps agents extension to Agent Peripheral Number and using Database, dblookup to get Agent Peripheral Number from the extension and store somewhere in PV

4. now in authentication script transfer call to CVP app, do authentication and send result back to ICM

5. Now in ICM to queue the call to same agent you can use Queue to agent node, Under Agent Expression Provide variable you stored agent ID in Above step. set some higher queue priority.

This will not work in Single step transfer because Agent Extension or calling line ID will not be preserved and you can get agent ID from external source.

Rate If you think solution was considerable..

[Sherif Fahmy]

What about the DTMF tone masking or putting the agent on hold? I couldn't find any solution to this part to keep the authentication code secured from agents.

[Chintan Gajjar]

well once your agent transfer the call is gone from there (consultative transfer). it will only come back after authentication as new call with Authentication result. you don't need any dtmf masking in that case.

[Sherif Fahmy]

We're supposed to make a conference call between agent, customer and IVR, so during the conference the customer requires authentication privacy and security. We need the DTMF tone masking or putting the agent on hold to prevent the agent from listening to the tones and having the probability of exposing the customers' authentication code.

I've been searching for how to make the agent on hold during the conference or masking the tones as if the agent transfers the call, it might be returned to a different agent, which is not preferred by the customer.

Thank you for your help.

[Chintan Gajjar]

In my case: the call always comes to same agent with the help of the scripting i have explained.

Chintan

[Abu Hadee]

Option 1 is not technically difficult. But it may not be practical. How can you ensure Agent will remain free while Customer is providing the PIN?

Option 2 is only practical option for you. Its true that the Agent will not get any data update from CVP leg as it is seen as external leg not an Agent leg. Agent must input the data manually.

What specific data you want to you want to set when the call is validated through CVP?

Thanks

Abu