How Can I make redirect caller from agent to any branch IVR?

[KrzysztofG]

I have IPCC Enterprise Edition (ICM 5.0, IVR 3.1)

How can I make redirect caller from agent to chosen branch IVR, and send with call any variable to IVR (e.g. account number).

Regards

Krzysztof

[geoff]

Krzysztof,

I imagine that English is not your first langauge, but could you please try to explain that again. I can't figure out exactly what you are trying to do, so what follows is guesswork.

ICM and IPIVR scripts inter-operate very nicely. You can set peripheral variables in your ICM routing script and get them in the CRS script; and vice versa, you can set peripheral variables in the CRS script and have the routing script examine these in order to know what to do with the call (if they reflect the caller's selection in the IVR menus).

You should try to make ICM do the routing in a routing script, and make the IVR gather data. I personally don't like the IVR script redirecting the call. The router is the right place for that.

[KrzysztofG]

Thanks for your answer. My question was very generally, and maybe not clear, that's why you probably didn't understand me.

I know, that I can set peripheral variables, and I can use conditional jump in CRA script.

But I want to make transfer caller from agent to main Post-Routing application.

This is problem because the script in Post-routing application can't contain step GET_ICM_DATA.

In my scenario, the caller rings to route points with ICM Post-Routing application and can use

interactive IVR system. If the caller has some problem in IVR tree, he is calling to the agent.

(The Agent uses CTI OS desktop )

After conversation with caller, the agent wants to transfer the caller to some branch main CRA script,

(not to the head script).

I don't know how to pass variables from ICM to ICM Post-Routing aplication.

Do you think, that when I will use ICM to make the routing, can I use VRU script to resolve my problem?

Regards.

Krzysztof

[adignan]

I would suggest using SQL to store these variables. In your post routing script, you can then reference these values in SQL.

[geoff]

I would suggest that post-routing should not be used. The way to go is to use translation routing applications. Although post-routing is easy to set up, almost all deployments require translation routing. I can't think of anything good to say about post routing, other than it's trivial to configure.

You want the main route point to be on the CM_PIM.RC for a number of reasons. You can check to see which of your IVRs are on line, and/or to do load balancing. If calls don't need to go to the IVR if agents are ready, you can have an LAA Select node immediately, and then translation route. Even if you just have one IVR, translation routing will enable you to do RONA more easily.

You need to bite the bullet and learn translation routing. If you do it that way, peripheral variables attached to the call remain unaffected whether the call is under the control of the CM_PIM.RC or the IVR_PIM.RC. This is exactly what you want.

There is no need, in my opinion, to go to an external database. In your IVR, decisions made by the caller (e.g. which "skill" they want) set peripheral variables. When the call comes out of this script you check the peripheral variable, and depending on the value do a queue to the appropriate skill group and run external script (BasicQ.aef).

Separate the intelligence gathering IVR script from the Queuing script. Allow ICM to make the routing decisions.

[KrzysztofG]

I tested translation routing, and I have great communication between ICM and IVR with peripherial variables but I have still problem with transfer information from agent desktop to IVR (or ICM).

When the agent wants to transfer the caller to some branch IVR script, hi changes

perpherial variables and hi does transfer call to route point with translation routing script. Unfortunately ICM don't get any peripherial var.

(Is this properly behaviour?).

When the agent does transfer the caller to another agent, second agent see all variables,

(even modified variables).

Someone know solution for this typical problem in Callcenter (except solution with database)?

[CSCO10619483]

it seems to be like a bug

CSCsz84926