Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Call Routing from S8710 PBX to Conversant IVR 1

Status
Not open for further replies.

dipanjanc

Programmer
Jun 14, 2001
7
US
High-level flow. My question is how does IVR distinguish between step 2) and step 6) so that it knows to play custom messages? Do I need to configure two separate vectors with different vdns?

Steps-
1)Call answered by PBX at location
2)PBX sends call to IVR
3)IVR asks questions of caller to best route call
4)IVR routes the call to the best route point in the PBX
5)PBX queues the call
6)PBX routes call back to IVR if expected queue time is above a threshold
7)IVR plays a message that can be interrupted if agent becomes available
8)PBX routes call to agent


 
you can use a convers skill

6 converse-on skill WW pri X passing YYYY and ZZZZ

WW skill or Hunt group # for your IVR
X priority to queue call
YYYY and ZZZZ parameters you can pass to the IVR

So in the IVR you would have different caller applications

in the case of step 2 you could pass 1111
and step 6 pass 2222 etc.

 
Thanks a lot Zen216. I appreciate it.

A follow-up question.

If IVR script is asynchronous, i.e. it does not wait for PBX callback, could you think of an easy way to associate the info collected in step 3) with the PBX callback?

What needs to happen is the message that's going to be played in step 7) would have to be different for different departments of callers. If we store the department number in a variable within the script, that might be overwritten by a second call before the first call comes back from PBX, no? Is there support of multi-threaded script execution for Conversant IVR?
 
Maybe this is irrelevant to your situ, but with the info you provided...it's hard to understand why you'd send the call back to the IVR, or perhaps even use it in the first place if it's only prompting the caller for input, and not doing any db lookups, or passing of data. Why not use vector variables and on-board announcements instead? Understandably, you may not have the requisite features enabled, but it may be cost-effective to research the corresponding costs vs. IVR development and maintenance costs...just a thought.

Additionally, if you're tied to using the IVR, assuming you're using the "converse on" step...why not just pass the department back in a variable in step 6, since you can pass 2 variables, and you know which department you're routing the call from due to the vector that it's being processed in at the time of the route-back...

For info on the converse on step, check out page 555 of:

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top