Sending the call to IVR for Verification/PIN change.

[r.boloor.rao]

Hello Experts,

I have a need , where agents after getting the call delivered to them need to send the caller to IVR for verification. Once authenticated/verified ( either fail or pass) the call should be routed to same agent.

Any Idea how this will be implemented.

I am using UCCE 9 with CVP 9 with comprehensive call mode. The Agents are using custom built CTI OS application.(not CAD).

Thanks.

Raghu                  

[Jameson Gagnepain]

Here's what I'm seeing from this:

1. Agent initiates transfer to ICM number (use CTI Route Point in CUCM, ICM Dialed Number Plan)... probably a direct transfer.
2. ICM plays CVP IVR using "GS, Server, V" Network VRU Script.
3. ICM queues to agent.

There are some interesting questions though:

• How long do you expect the IVR to take?
• Will the agent be handling other calls while the caller is in IVR? If not, how will you keep them in a Not Ready state? You may need some extra development in your CTI app if you need the agent to not take other calls until the IVR returns.
• I'm not sure how you'll get the agent ID for step 3, as the  Call.CallingLineID may be assigned the original caller ANI if you're  doing a direct transfer... You may need to have the CVP script do a dip on the Router DB to find the agent ID in the RouterCallDetailRecord.

A potential alternative would be some custom development in CVP or the gateway, where you would instead have the agent conference into the IVR, and the agent would be put on hold while the caller finishes the IVR. I remember seeing something about that in a CVP tips & tricks Cisco Live presentation from a year or so ago.

-Jameson

[r.boloor.rao]

ivr may be only two prompts ; asking for a/c number and pin. I want the call to arrive at same agent who will be waiting for customer to change his pin. I was thinking;

1. create a custom button in CTI OS client; to transfer the call to IVR and put the agent in reserved state.

2. it should populate the agent ID in one of the PVs

3. Call goes to CVP and retruned with result.

4. use Agent node to send the call to same agent.

not sure what are the other things I may have to look into.

comments welcome.

[david.macias]

I've never seen this done, but I would change up your steps a bit and I doubt this would be supported by TAC.

- When call arrives attach the agent ID and RCK to call data.

- Have agent transfer the call into IVR.

- Desktop goes into a special state (waiting) where the desktop polls the TDC for that call to see when it will sit in the queue to agent node and to see if the call is still in the IVR.  Once the call is ready or if the call is gone, the agent will go back to ready.

- If the call was sitting in a queue to agent node, it should have the highest priority possible to ensure it is delivered to this agent.

david

[Jameson Gagnepain]

It sounds like you've got it figured out pretty well. The custom  button in CTI OS will be very useful. Just a few details I would watch:

• In this scenario, the Agent To Agent node may be  the best one to use to deliver back to the agent. You can use that do  deliver to an agent who is not in a Ready state.
• Reserved may be  the wrong state to use... I don't know if you can deliver any calls  while the agent is reserved. Not Ready, WorkNotReady, or WorkReady may  be better choices. I would recommend doing some testing with different  states.
• Make sure you're using the full recommended direct  transfer setup... ICM Dialed Number Plan and such... so that you ensure  the Peripheral Variables and original caller info come through
• This  will have an interesting impact on reporting. Agents will have an  additional delivered call for every time they send a call to IVR. That  second call will come through on their default Skill Group. The Handle  Times for the first and second leg will be counted as separate calls.  You will probably want to set a Call Type after the IVR as well.

The reporting side of this seems to be the biggest can of worms... If you're watching things like AHT, ASA, and so on, those will be potentially skewed by this.

-Jameson